I love these one-liners. It's also about knowing your tools better. I hadn't known about `look` [0], which is great. The writer looks to be a bioinformatician, so it might be a bit out of scope, but I also found `socat` [1] quite a good serial communication helper tool. [0] https://man7.org/linux/man-pages/man1/look.1.html [1] https://linux.die.net/man/1/socat
Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
21–30 of 114 posts
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#22That's a nice and very extensive collection. As a follow-up, I can also recommend Effective Shell series. I used to have navigation shortcut diagram from Part 1 ( https://dwmkerr.com/effective-shell-part-1-navigating-the-co... ) printed out.
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#23I love these one-liners. It's also about knowing your tools better. I hadn't known about `look` [0], which is great. The writer looks to be a bioinformatician, so it might be a bit out of scope, but I also found `socat` [1] quite a good serial communication helper tool. [0] https://man7.org/linux/man-pages/man1/look.1.html [1] https://linux.die.net/man/1/socat
I don't recall where I heard it, but my understanding is that socat is the sort of successor to good ol' netcat. (Of course, don't ask me to compare each, nor know what socat brings that netcat lacks, etc.)
[0] https://serverfault.com/questions/246347/whats-the-differenc...
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#24required reading for the bash newbie and mage alike. 10/10 will reference again and again.
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#25When the shell itself filters the output of ps, then removing a grep is unnecessary. Note this uses POSIX shell patterns, not regular expressions.
On a truly POSIX shell that does not support "local," remove the keyword, and change the braces to parentheses to force the function into a subshell.
pps () { local a= b= c= IFS='\0'; ps ax | while read a
do [ "$b" ] || c=1; for b; do case "$a" in *"$b"*) c=1;;
esac; done; [ "$c" ] && printf '%s\n' "$a" && c=; done; }
$ pps systemd
PID TTY STAT TIME COMMAND
1 ? Ss 5:11 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
557 ? Ss 0:19 /usr/lib/systemd/systemd-journald
...Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#26sed -i Watch out, that's a Linux-ism and macOS's sed will cheerfully use the thing after it as the backup expression; as far as I know, the absolute safest choice is to always specify a backup extension "sed -i~" or "sed -i.bak" to make it portable, although there are plenty of work-arounds trying to detect which is which and "${SED_I} -e whatever" type silliness My contribution (and yeah, I know, PR it ...) is that…
Basic usage looks like this:
printf '%s\n' '" some commands...' 'wq' | ex -s file
Or: ex -s file
By the way, these commands are the ones that you use in your vimrc or after a colon in vim — at least, the POSIX subset of that — so any ex commands you learn translate naturally to your normal editor.Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#27Learnt a neat trick from an old sysadmin colleague. If you’ve written a command but realize you don’t want to run it right now but want to save it in your history you can just put a `#` in front of it (ctrl-a #) making it a comment and allowing you to save it in your history without running it. When you’re ready to run it you find it and remove the preceding `#`
I will type fc, save to a file (script) and then delete all lines before exiting the default EDITOR, e.g., %d in vi. This prevents the commands from being re-executed when I exit vi.
Also I sometimes use # combined with a semicolon to disable portions of command lines, e.g., early commands ;# late commands. I might cut and paste from one entry in the history into another one. Or I might fc -l 1 > file and edit the file down the the entries that form the starting point for a new script. By far, the shell is the most useful REPL for me.
There is no shortage of comments online praising the utility of the REPL concept but the only comment I have ever seen about fc was from a shell implementor/maintainer; it was negative. I use fc all the time. It has become essential for me to use the shell effectively as a REPL.
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#28sed -i Watch out, that's a Linux-ism and macOS's sed will cheerfully use the thing after it as the backup expression; as far as I know, the absolute safest choice is to always specify a backup extension "sed -i~" or "sed -i.bak" to make it portable, although there are plenty of work-arounds trying to detect which is which and "${SED_I} -e whatever" type silliness My contribution (and yeah, I know, PR it ...) is that…
It's GNU sed vs (Free)BSD sed, which are different enhancements of the POSIX standards for sed that went in different design directions. One could Homebrew/macports install gnu-sed on macOS to get a GNU version to write Linux-portable scripts as-needed.
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#29sed -i Watch out, that's a Linux-ism and macOS's sed will cheerfully use the thing after it as the backup expression; as far as I know, the absolute safest choice is to always specify a backup extension "sed -i~" or "sed -i.bak" to make it portable, although there are plenty of work-arounds trying to detect which is which and "${SED_I} -e whatever" type silliness My contribution (and yeah, I know, PR it ...) is that…
Even better, use a real text editor like ed or ex. (Nowadays ex is more portable because many distros — against POSIX — omit all 55 kilobytes of GNU ed. Of course, smaller systems might not have ex/vi.) Basic usage looks like this: printf '%s\n' '" some commands...' 'wq' | ex -s file Or: ex -s file By the way, these commands are the ones that you use in your vimrc or after a colon in vim — at least, the POSIX subset…
That said, the "lottery factor" is often a bigger contributor to the things that land in codebases than "optimality". Plus, I've actually seen somewhere that perl is the most common binary across every system, and it's likely a larger population who know perl than ed would be my guess
Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks
#30Earlier quoted context omitted.
The opposite is adding space before the command. The command will run but it will not be saved in history. EDIT: This apparently needs to be configured - setting HISTCONTROL=ignorespace
Thanks to your comment, I learnt about ignoredups as well