This is a somewhat dangerous pattern for picking temporary files (from #8):<p><pre><code> $ NEWFILE=/tmp/newfile_${RANDOM}
$ touch $NEWFILE
</code></pre>
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 :)<p>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.
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.<p>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.<p>I gift you "Aurelio's Swiss Army Knife of the Bash Shell" - <a href="http://aurelio.net/shell/canivete/" rel="nofollow">http://aurelio.net/shell/canivete/</a>
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":<p><pre><code> read -t 5 foo || foo='No reply'
</code></pre>
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`:<p><pre><code> 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.</code></pre>
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.
"Sigh. Hit ‘up’, ‘left’ until at the ‘p’ and type ‘e’ and return.". My solution for this one would be :<p>UP
CTRL-A
RIGHT RIGHT e<p>Which needs less thinking and 6 keystrokes instead of 8.
Just another plug for Zsh: it has all of these features and then some.<p>- Safe-by-default parameter expansion: no word splitting unless you ask for it, even if you don't quote the expansion.<p>- Ability to use histoy expansions (like !!:gs/foo/bar) on parameter expansions, meaning "${foo:A:h}" is equivalent to "$(dirname $(realpath $foo))"<p>- Much better array support, including both integer-indexed and associative arrays<p>- A built-in CLI option parser that's pretty robust ("zparseopts")<p>- Lazy-loaded functions<p>- Floating-point arithmetic
<i>Sigh. Hit ‘up’, ‘left’ until at the ‘p’ and type ‘e’ and return.</i><p>One could also use <c-p>,<c-a> and <c-f> to achieve the same result much quicker.
I agree with most of it except for:<p><pre><code> ${RANDOM}${RANDOM}
</code></pre>
A preferred way would be<p><pre><code> od -vAn -N4 -tu4 < /dev/urandom
</code></pre>
/dev/urandom gives you random bytes, od dumps them in different formats (e.g: hex, octal, decimal and such).<p>This takes 4 random bytes and outputs them as a 4 byte unsigned int.
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.<p>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.<p>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.
<p><pre><code> ^x^y^
</code></pre>
Is that third caret necessary? I've never had to include it. Although that may be zsh taking a shortcut on bash syntax.