If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.
Use long flags when scripting (2013)
101–110 of 197 posts
Re: Use long flags when scripting (2013)
#102Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…
I agree. To me, "sed -e" is an expression as a whole, and replacing -e with --expression is on the same level as aliasing "sed" to "stream-editor". Though I would make the list of "allowed" short flags very short. I can't think of many more than the ones you listed: mkdir -p sh -c cp -r tar -xaf tar -caf
Re: Use long flags when scripting (2013)
#103Some may disagree, but unexpected flags passing through seems dangerous to me.
Re: Use long flags when scripting (2013)
#104Don't use long flags when scripting, if they have short equivalents, and POSIX only specifies the short equivalents. Even if the stuff will only ever run on one system, the POSIX flags (1) come from a smaller set of options, since POSIX is fairly conservative in its content this area and (2) are generally well known (often three decades old or older). Don't make me read a man page to confirm that "grep --fixed-string…
Re: Use long flags when scripting (2013)
#105Earlier quoted context omitted.
tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/
I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…
Re: Use long flags when scripting (2013)
#106Earlier quoted context omitted.
I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…
Recent (as in, within the last ~3-5 years) versions of GNU tar automatically detect the type of compression and apply the appropriate tool, so you can often get away with `tar xvf`.
Another "recent" (much more recent IIRC) change is that you don't need the dot anymore in find to search in the current directory.
Re: Use long flags when scripting (2013)
#107Earlier quoted context omitted.
The short flags are really there for when you're doing things interactively. For scripts that are read and executed more often than they're written or changed, the long flags really help ensure you don't fat-finger. I'm accustomed to typing `rm -rf` when really I just need `rm -r` in a lot of cases, and in PRs it's very easy for your eyes to glaze over when there's more than a single short flag.
Why are you more likely to typo something in a script you can read, review, and test than an interactive command prompt that executes immediately?
Re: Use long flags when scripting (2013)
#108Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…
What about other people who might read the script?
Re: Use long flags when scripting (2013)
#109Earlier quoted context omitted.
Related to this, they're less likely to do something unexpected. Many programs use -v as a short flag for --version , but some (such as curl) use it as short for --verbose Probably something you'd catch pretty quickly, but still.
As does Python, which drives me crazy. -V is version on Python.
Re: Use long flags when scripting (2013)
#110Earlier quoted context omitted.
tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/
These two commands should fit most of your use cases: tar cf dir.tar dir # mnemonic: 'create file' tar xf dir.tar(.gz|bz2|...) # mnemonic: 'eXtract file' On systems with "modern" versions of tar `-x` is capable of recognizing which compression format is used and doesn't require the explicit `-j/z` flags you usually see.