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