More Things I Wish I’d Known About Bash | Hacker News Reader

More Things I Wish I’d Known About Bash

zwischenzugs.com

150 pointsjesperht49 comments

This is a somewhat dangerous pattern for picking temporary files (from #8):

    $ NEWFILE=/tmp/newfile_${RANDOM}
    $ touch $NEWFILE

The problem is that any user on the box can create files under /tmp. An attacker can set up a bunch of symlinks like /tmp/newfile_1, ..., /tmp/newfile_99999 pointing to a file owned by your user. When your script then writes into this temporary file, you'll write through the symlink and clobber one of your own files. Especially dangerous if root :)

This has been a historic source of software vulnerabilities (often with the PID used instead as the guessable component instead of random, though). One recommended alternative is to use the `mktemp` command instead.

this is from a guy writing abook on Docker, so I hope this is for a single purpose cointainer with now other users of THAT /tmp

Nitpick: $RANDOM gives you an integer between 0 and 32767 (inclusive).

it's a very dangerous pattern. Use mktemp(1) instead!

Portuguese speakers have counted for a long time with this gem, simply the best Bash doc/cheat sheet I've ever seen on the web. This is probably my oldest bookmark still relevant after 15 years.

It's in portuguese and I'm not sure if there's an official translation, yet it's easy enough to decipher if you know bash, and Google Translate will do a pretty decent job.

I gift you "Aurelio's Swiss Army Knife of the Bash Shell" - http://aurelio.net/shell/canivete/

Ah, curious. Despite being a native Portuguese speaker, ever since I learned English well enough (which was before I started using Linux), I always search for stuff in English, so I never came across that guide.

That said, that guide doesn't seem to have the tricks from the top article, at least 1-4.

Thanks for the heads up - it does work via translate.

I'll drop this: http://tldp.org/LDP/abs/html/ If anyone, who has to do anything BASH related, has not seen it then they should!

I'd recommend against the Advanced Bash-Scripting Guide -- it uses a lot of bad practices (like unquoted variable references!) that you're better off not learning. Instead, check out http://mywiki.wooledge.org/BashGuide and http://mywiki.wooledge.org/BashFAQ. Also, http://www.shellcheck.net is a good automated tool for sanity-checking syntax errors and common mistakes.

Aurelio is the madman/genius behind Arkanoid in sed[1], Sokoban in sed[2] and sedsed, a sed debugger[3]. I have no trouble believing that he has a few shell tricks up his sleeve.

[1]: http://aurelio.net/projects/sedarkanoid/

[2]: http://aurelio.net/projects/sedsokoban/

[3]: http://aurelio.net/projects/sedsed/

As I mentioned in my comment on the article, setting $TMOUT if you want a timeout on a 'read' command is unnecessary and unclear. Just use "read -t":

    read -t 5 foo || foo='No reply'

Setting $TMOUT affects all following 'read' commands. Also, setting $TMOUT in an interactive shell sets a timeout for a response to the primary prompt, terminating the shell if the user doesn't respond in time.

Fiy, heredocs also have a variant that strips all leading tab characters. Quoting from `man 1 bash`:

  If the redirection operator is <<-, then all leading   
  tab characters are stripped  from  input  lines  and  
  the line containing delimiter.  This allows here-
  documents within shell scripts to be indented in a  
  natural fashion.

There’s also a variant, where you single quote the marker, that won’t expand variables:

    cat <<‘EOF’
    This will not be ${expanded}
    EOF

I imagine most uses of random in Bash don't need to be that robust, but it might be worth mentioning that ${RANDOM}${RANDOM} has a lot of bias as a random number generator.

Fair point - have updated accordingly.

If you want 30 rather than 15 bits of randomness:

    echo $(((RANDOM << 15) + RANDOM))

If you want random numbers in bash then use dd if=/dev/urandom ...

$RANDOM is not cryptographically secure.

"Sigh. Hit ‘up’, ‘left’ until at the ‘p’ and type ‘e’ and return.". My solution for this one would be :

UP CTRL-A RIGHT RIGHT e

Which needs less thinking and 6 keystrokes instead of 8.

Even better: https://github.com/nvbn/thefuck

I don't like to use arrow keys, and on my system the following works: CTRL-P CTRL-A CTRL-F CTRL-F e I also prefer this to the solution in the article.

Potentially of interest: https://github.com/Fakerr/goto sort of like the easymotion vim plugin.

But that requires modifiers. Insert modal vs. not flame war.

I'm so happy that Bash is getting the love it deserves.

Me too!

Just another plug for Zsh: it has all of these features and then some.

- Safe-by-default parameter expansion: no word splitting unless you ask for it, even if you don't quote the expansion.

- Ability to use histoy expansions (like !!:gs/foo/bar) on parameter expansions, meaning "${foo:A:h}" is equivalent to "$(dirname $(realpath $foo))"

- Much better array support, including both integer-indexed and associative arrays

- A built-in CLI option parser that's pretty robust ("zparseopts")

- Lazy-loaded functions

- Floating-point arithmetic

People keep mentioning zsh to me in response to this article - I think I'll have to go and read up on it more.

I still stick with bash - but if you're willing to move to a "friendlier" shell - my recommendation would be fish. Better out-of-the-box box experience than zsh - but still has the issue that most servers will have bash as the default interactive shell for root etc.

https://fishshell.com/

Production servers don't generally have zsh available, while most have bash. That means that ssh sessions will use a different shell, and scripts I write will use a different shell. And so, the upside for using some funky shell locally is greatly reduced.

Whereas if I stick with bash, I can run my scripts almost everywhere and almost every server I ssh into has a familiar environment. Thus my knowledge of edge cases and scripting idioms from bash pay dividends.

For situations where I need better arrays, associative arrays, floating point arithmetic, I'm probably better off writing it in an actual scripting language.

Fair enough! One tends to get spoiled with Zsh, trying to go back to Bash.

In the past I've actually downloaded Zsh, compiled it from source, and ran it out of ~/.local/bin with absolutely no issues. But that's not something I'd advise.

Sigh. Hit ‘up’, ‘left’ until at the ‘p’ and type ‘e’ and return.

One could also use <c-p>,<c-a> and <c-f> to achieve the same result much quicker.

True, I use that too, but gets trickier in the middle of the line.

As a for-your-consideration, C-r leaves the cursor at the matched string when doing reverse search; so "echo helol world", enter, mutter "rats", C-r, o-l-sp, right (just to break the search), and voila you are now positioned on the offending substring

Yup. The moment you need editing capabilities more sophisticated than those three keys, though, I recommend switching to vi input mode (set -o vi) if you are familiar with vim keybindings. Although tapping Esc is not as quick as Ctrl (or, my chosen alternative, Ctrl-[), you have an entire library of editing commands already at your beck and call. I find that using 'f' or 'F' and '.' more quickly triangulates the problem area of the text in most cases.

Of course, if you are an emacs user, more power to you with the emacs bindings.

IMO you might as well run "fc" (if you have vim set as your editor) in that case, rather than changing mode.

I've grown fond of the new :term command in vim (inspired by neovim).

Or, if you already started editing a line, and decided that you'd rather finish it in a proper editor, you can press Ctrl+X Ctrl+E.

Didn't know that one, thanks.

I prefer "grep !*", which will be replaced by all arguments to the previous command

Interesting, most of these are from korn shell and well documented in "The korn shell command and programming language" by Bolsky and Korn.

Well that first example with the mistyped grep command just blew my mind.

I agree with most of it except for:

    ${RANDOM}${RANDOM}

A preferred way would be

    od -vAn -N4 -tu4 < /dev/urandom

/dev/urandom gives you random bytes, od dumps them in different formats (e.g: hex, octal, decimal and such).

This takes 4 random bytes and outputs them as a 4 byte unsigned int.

Explanation of options:

-v: Don't suppress duplicate lines. (It doesn't make a difference here, because there's always only one line.)

-An: Don't write input offsets.

-N4: Read at most 4 bytes.

-tu4: Print 4-byte unsigned integers.

https://explainshell.com/explain?cmd=od+-vAn+-N4+-tu4

I use pushd and popd every day. If you forget what's in the stack you can see what's in it by using the "dirs" command.

You can also use pushd -n (where n is a number, although I usually end up needing trial and error to get the right one) to rotate the list of dirs without removing any from the stack - useful if the list has more than 2 directories, or 2+ directories you need to switch between repeatedly.

pushd and popd also work out of the box in Windows command prompt, although you don't get "dirs" or any fancier options like in bash, just push and pop on a plain old stack.

Previous post discussion: https://news.ycombinator.com/item?id=16084763

    ^x^y^

Is that third caret necessary? I've never had to include it. Although that may be zsh taking a shortcut on bash syntax.

It's optional, also in Bash, even though I can't find it explicitly mentioned in the manual.

Things I Wish I’d Known About Bash: don't use it for script

But you really should know that set -e is broken.

So... why the downvotes? Is it not the case that set -e is broken? Or is it that I provided too little detail? Or is it that it's broken in the same way in all shells?

FWIW, the bug (yes, it's a bug that the Open Group has decided is not a bug, but it really cannot be anything other than a bug!) is this: non-zero exits by commands/functions are ignored when invoked by functions invoked in a conditional expression context.

Reply on news.ycombinator.com