Live data from Hacker News

Bash-oneliner: A collection of handy Bash one-liners and terminal tricks

github.com

21–30 of 114 posts

Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks

#21
post #16

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

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.)

Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks

#22
post #2

That'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.

Thank you so much for the navigation shortcut link! I love these and picked them up from mentors at jobs but never found a definitive guide to all of the ones I could learn.

Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks

#23
post #21
post #16

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

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.)

`socat` is netcat but for serial. [0]

[0] https://serverfault.com/questions/246347/whats-the-differenc...

Re: Bash-oneliner: A collection of handy Bash one-liners and terminal tricks

#25
New users on my systems commonly ask me "what implements your pps process search?"

When 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

#26
post #13

sed -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 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

#27
post #3

Learnt 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 `#`

This is useful when saving command lines to files (scripts) using the POSIX-required fc builtin. Command line histories are relatively cumbersome to save with Ash, Bash saves them but truncates them to 500 entries, whereas scripts can easily be saved indefinitely. Amongst Bash and other feature-heavy shell users, there are Rube Goldberg-like workarounds for command line history saving. OTOH, all shells aiming for POSIX compliance, including the fastest, lightest weight ones I prefer, will implement fc. It's already there; I make use of it.

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

#28
post #13

sed -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…

> Watch out, that's a Linux-ism and macOS's sed

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

#29
post #13

sed -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's an interesting trick, I'll bear it in mind.

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

#30
post #4

Earlier 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

And `ignoreboth` to combine the two.
Post reply on HN