When I’m in a trolling mood, I show that to people while omitting the space after the # comment and tell them shells support Twitter-style hashtags. :D
I’m mostly enjoying fish’s completion today. I like the fact that it takes the directory into account. It has its annoyances, but it has never driven me mad to the point that I would start looking for other mechanisms, so far.
Regarding your public .bash_history, what do you do to prevent sensitive information from accidentally ending up there?
It seems like it is not a real history file. For example, it is alphabetically sorted. I assume that they use it as a place to store common commands, searchable by ^R.
Yeah, otherwise it would murder my productivity if I had to stop after typing an alias- and shortcut-ladden sausage of a line to add a comment. I spam that enter like crazy, the commenting would never work.2
And that text box says “do not use this […] summarize the story or explain why you posted it”. ;)
This isn’t the first situation when following submission guidelines seems counter-productive, and “editorializing” the title, e.g., by adding “[using fzf for bash history search]” would be helpful. Myself, I believe a requirement to keep the original title in the story title field should be the only hard requirement, especially considering that most people here comply with the spirit of that rule at all times anyway.
Fun fact: confusion between “edit” and “editorialize” is part of how we ended up here.
‘Edit’ merely means to alter
‘Editorialize’ means to inject an opinion, as in a newspaper’s editorial opinion column.
The original submission guidelines asked submitters not to editorialize their submission titles
This got misinterpreted as a ban on any edits, the community started reminding each other of this rule-as-they-understood-it, and eventually the old intent was forgotten to the point that the guidelines were reworded.
And yes, I agree that brief title clarifications, summaries, and ‘this is why I think this is interesting’ introductions would make the forum a nicer place, and help keep us from ever becoming a linkdump.
Yeah I wasn’t sure whether to add that or not, it would probably have been a good idea since we’re missing a shell tag. ‘programming’ and ‘unix’ are rather vague. I erred on the side of caution here.
I’ve been doing something similar for quite a while, except that instead of having dedicated commands to tag/save and recall items I want to remember, I have a myriad of small scripts in ~/bin, or git aliases in ~/.gitconfig, or (lately) eshell commands. Whatever is the most convenient to get the job done.
Want git commit --no-verify --amend? That’s ~/bin/git-amend, a small shell script that - by default - will add --no-verify to a git commit --amend call, but if I give it a -V/--verify argument, then it won’t. Could be a git alias, too.
This way I don’t have to remember the command to recall a tagged item. Nor do I need to add comments at the end (which can be annoying when you want to edit the command before running it again). I do have to come up with script names that make sense, but I don’t find that harder than coming up with tags, and I have shell completion for them too, basically free.
Yeah, the most common stuff I have aliases too. Some git specific are in gitconfig, others are just bash aliases and functions. I have a .bash-aliases in my dotfiles, but I also source local aliases if [ -f ~/.local-aliases ]. Similar to functions, and to env files. Dotfile version, which at the end sources (if exists) a local version.
Sharing history would never work for me instead of this.
I wrote a command line utility that interactively and incrementally searches through a library of anotated commands and, once you pick one, puts it in your prompt.
The commands are stored in a text file with a simple format and can be easily shared.
I tried if something like this already existed, but I couldn’t find anything. That’s weird, this can’t be a truly original idea, can it? I think there are graphical tools for this purpose, but this is about 20 lines of bash, so it’s relatively straightforward.
I started writing a little tool a few years ago to database my shell history (and also save repl histories) in a ~project-oriented way. I intend to eventually layer on support for things like retroactively annotating commands and entire sequences, identifying oft-repeated sequences to suggest making an alias or shell function, etc. (Alas, this project initiated a yak shave that generated several interesting projects…)
I looked around before I started (maybe late 2018? early 2019?) and I also failed to find anything that obviously addressed this. There were a number of history-databasing projects at the time, and several new ones since–but I don’t recall seeing anything addressing ~annotation (aside from the simple user-controlled append-a-comment approach).
A useful shorthand I find for this kind of thing is to tag shell commands with comments.
Now the command is searchable with Ctrl-R >
frob...When I’m in a trolling mood, I show that to people while omitting the space after the
#comment and tell them shells support Twitter-style hashtags. :DBeen there, done that ;) My .bash_history
I’m mostly enjoying fish’s completion today. I like the fact that it takes the directory into account. It has its annoyances, but it has never driven me mad to the point that I would start looking for other mechanisms, so far.
Regarding your public
.bash_history, what do you do to prevent sensitive information from accidentally ending up there?Crazy you keep yours public. I have mine in a separate private repo from my dotfiles. Too easy to leak a secret.
It seems like it is not a real history file. For example, it is alphabetically sorted. I assume that they use it as a place to store common commands, searchable by ^R.
Yeah, otherwise it would murder my productivity if I had to stop after typing an alias- and shortcut-ladden sausage of a line to add a comment. I spam that enter like crazy, the commenting would never work.2
Could we stop using 0-informatiom titles like this please? There is no way for me to have any idea what this is about without following the link.
There’s a text box after ‘tags’ section that can used to add more information while submitting.
And that text box says “do not use this […] summarize the story or explain why you posted it”. ;)
This isn’t the first situation when following submission guidelines seems counter-productive, and “editorializing” the title, e.g., by adding “[using
fzffor bash history search]” would be helpful. Myself, I believe a requirement to keep the original title in the story title field should be the only hard requirement, especially considering that most people here comply with the spirit of that rule at all times anyway.Fun fact: confusion between “edit” and “editorialize” is part of how we ended up here.
And yes, I agree that brief title clarifications, summaries, and ‘this is why I think this is interesting’ introductions would make the forum a nicer place, and help keep us from ever becoming a linkdump.
I didn’t know any of that. And I am not sure I’d touch stuff, because I’m afraid to get it wrong.
Yeah I wasn’t sure whether to add that or not, it would probably have been a good idea since we’re missing a
shelltag. ‘programming’ and ‘unix’ are rather vague. I erred on the side of caution here.flag as off topic
I’ve been doing something similar for quite a while, except that instead of having dedicated commands to tag/save and recall items I want to remember, I have a myriad of small scripts in
~/bin, or git aliases in~/.gitconfig, or (lately) eshell commands. Whatever is the most convenient to get the job done.Want
git commit --no-verify --amend? That’s ~/bin/git-amend, a small shell script that - by default - will add--no-verifyto agit commit --amendcall, but if I give it a-V/--verifyargument, then it won’t. Could be a git alias, too.This way I don’t have to remember the command to recall a tagged item. Nor do I need to add comments at the end (which can be annoying when you want to edit the command before running it again). I do have to come up with script names that make sense, but I don’t find that harder than coming up with tags, and I have shell completion for them too, basically free.
Yeah, the most common stuff I have aliases too. Some git specific are in gitconfig, others are just bash aliases and functions. I have a
.bash-aliasesin my dotfiles, but I also source local aliasesif [ -f ~/.local-aliases ]. Similar to functions, and to env files. Dotfile version, which at the end sources (if exists) a local version. Sharing history would never work for me instead of this.I wrote a command line utility that interactively and incrementally searches through a library of anotated commands and, once you pick one, puts it in your prompt.
The commands are stored in a text file with a simple format and can be easily shared.
https://github.com/plainas/icl
I started writing a little tool a few years ago to database my shell history (and also save repl histories) in a ~project-oriented way. I intend to eventually layer on support for things like retroactively annotating commands and entire sequences, identifying oft-repeated sequences to suggest making an alias or shell function, etc. (Alas, this project initiated a yak shave that generated several interesting projects…)
I looked around before I started (maybe late 2018? early 2019?) and I also failed to find anything that obviously addressed this. There were a number of history-databasing projects at the time, and several new ones since–but I don’t recall seeing anything addressing ~annotation (aside from the simple user-controlled append-a-comment approach).