# put interesting lines from history into a file, open an editor
function h2e() {
echo "#! /bin/bash" > "$3"
history | tail -n"$1" | egrep "$2" | sed -re 's/\s*[0-9]+\s+//' >> "$3"
"${EDITOR:-emacs}" "$3"
}
# prompt for h2e's arguments
function h2ei() {
read -p 'num. lines [1]: ' lines
read -p 'pattern [.]: ' pattern
read -p 'file [foo.sh]: ' fn
h2e "${lines:-1}" "${pattern:-.}" "${fn:-foo.sh}"
}
# fix the terminal settings for the duration of a command, revert afterward
function insane() {
save=$(stty -g)
stty sane
"$@"
stty $save
}
# bind F12 to our history grabber
bind -x '"\e[24~":insane h2ei'
It's been quite handy of late.Become Shell Literate
221–230 of 341 posts
Re: Become Shell Literate
#222Earlier quoted context omitted.
You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…
>The Linux man pages are upside down. Examples don't come till the very end, if at all. You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?
Re: Become Shell Literate
#223Earlier quoted context omitted.
(nit) > `grep --extended-regexp` but `sed --regexp-extended` Why not use `grep -E` and `sed -E`?
Hint: if you're still using grep to search files rather than a file , install and start using the "newer generation" of greps (ag, ripgrep etc). You likely won't believe the speed. I use ag many times a day to search 10,400 files comprising about 800k lines of code, and it is in every meaningful way completely instantaneous. It also understands repository structures, and so won't waste your time there. It seriously c…
Re: Become Shell Literate
#224That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.
You can fix it by replacing the awk with "cut -d ' ' -f 2-" Haven't tested it, but you may also need to throw a "tr '\n' '\0'" in there and call xargs with "-0" to make it happy. This will still break on files with a CR in the filename. (CRs are allowed in unix filenames but, imho, they should not be.)
Re: Become Shell Literate
#225That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.
Yeah, it's annoying that unix filenames and shell quoting are both fundamentally broken and that (as above) people would generally (knowingly) write a a broken-for-spaces-in-filenames version by default because it's easier (and the author no doubt knew he'd not encounter spaces in his repo). Having said that, it's not very hard to fix, I'd probably write something like: git status -s | awk -vORS="\0" 'gsub(/^ D /,"")…
Re: Become Shell Literate
#226Earlier quoted context omitted.
tldr [0] is great for easy to understand example commands. It is community driven and there are many cli based programs you can install[1][2]. [0] https://tldr.sh/ [1] https://www.npmjs.com/package/tldr [2] https://github.com/tldr-pages/tldr-python-client
That python client seems very lack of maintenance. It doesn't have proper color code for Windows at all.
Re: Become Shell Literate
#227I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
Re: Become Shell Literate
#228I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
Re: Become Shell Literate
#229Re: Become Shell Literate
#230Earlier quoted context omitted.
You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…
> The Linux man pages are upside down. Examples don't come till the very end, if at all. man pages are meant to be a full reference, not a quick tutorial. To get the quick tutorial others have already mentioned cheat.sh [1] and tldr pages [2] is another good resource. [1]: https://cheat.sh/ [2]: https://tldr.sh/
And it's fun to read. It's how man pages should be written, at least have a tl;dr before boring you to death.