Use long flags when scripting

While it is generally a good idea to write readable code, it is also true that long flags are not universally supported, and the short flags don't always have the same meanings (or even exist!) across different systems.<p>This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short):<p><a href="http://news.ycombinator.com/item?id=5165058" rel="nofollow">http://news.ycombinator.com/item?id=5165058</a><p>But these are not universally supported:<p><a href="http://unixhelp.ed.ac.uk/CGI/man-cgi?ps" rel="nofollow">http://unixhelp.ed.ac.uk/CGI/man-cgi?ps</a><p>What to do? My proposal: do what we do in the C/C++ world when presented with portability problems: abstract it away. POSIX sh supports functions, which can be named appropriately for readability, while calling the proper arguments and commands for different platforms. To avoid unnecessary duplication of platform/argument detection, setup could be done in a function called before anything else to create variables with the appropriate command names and arguments.<p>This may all seem too involved, but realize that we are talking about creating robust software that is to be maintained, so applying proper software engineering principles seems appropriate.

This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent.<p>Short options should be used where they're the more typically known and standardised. Long options are for the unusual.<p><pre><code> grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n</code></pre>

Agreed! It saves a trip to the man page.<p>Something else I figured out recently is that if you put the pipe at the end of a line, you don't need a backslash:<p><pre><code> echo thing | grep thing</code></pre>

No. Use standard POSIX flags to invoke standard POSIX functionality, so your scripts don't break when run on a different system.

As a part-time scripter (is there any other kind?) I'm ashamed to say that I often use shortcut flags because I looked up the functionality I needed and copy pasted without taking the time to even understand what all of the flags mean.<p>This advice is good not only for others but setting a standard for yourself where you take a moment to learn what exactly is going on.

Disagree. There isn't and shouldn't be any hard fast rule for this. Same as most things in programming. Do what makes sense.<p>Also, [0-9.] not [0-9\.]

This is a practice I use; in my opinion it is akin to descriptive variable names.

I write a lot of shell scripts as part of my daily Sys Admin work. In my opinion, the author gave us choice to write less codes &#38; readable code by using short flags for most of the command functionalities.<p>Consider something like this: $ rsync -qaogtHr example.com:/opt/data/ /home/backup/<p>1. Elaborating all the short flags into long ones will increase readability by explaining this statement but at the cost of more lines of code.<p>2. All UNIX commands have options to combine short flags. For eg: ls -l -t -r ./ can be written as: ls -ltr ./ This also helps in reducing code. Writing less code helps in managing it more easily.<p>Long options may help beginners, but once they get comfortable, Short flags may seem more readable!!

For well known flags like grep's -E, this makes it less obvious what the script is doing. Not everyone speaks English as their first language and most of the long options are GNU specific so won't be portable.

A secondary benefit not mentioned in the article is immutability.<p>Long flags on a command line utility <i>should</i> never change. Short flags may be modified between major versions of a utility, which would break scripts.<p>Of course this is just a convention, and I'm sure it's not followed 100%. I'll take whatever protection I can get though.

Ironically, tab-completion works on the command-line for long options, but not in a script (I'm sure vim can do it though).

I recently found myself going back and changing a script I had done to use the long form flags because I had forgotten what the short ones meant.

This is very good advice. You may not be maintaining your script later on, maybe someone who is new to unix will be asked to go change it. Having the intention much more obvious will save them some hassle. Hell, even someone who uses unix a lot may not know every flag of every command you use. With no other context, it's pretty hard to know if -r is recursive or reverse sort, or something else entirely.<p>And god forbid you <i>think</i> you know which one it is and end up being wrong... you might not realize until it hits production (scripts not always being the best tested things in the world).<p>Yes, they might not be supported on BSD.. they're also not supported on Windows, what's your point? It's a lot more likely you'll have to read and/or change the script 6 months down the line when you've forgotten everything about what's in it, then you'll all of a sudden need to run your script on BSD when you've never had to in the past (obviously if portability is a requirement from te beginning, then that changes how you write the script from the start).

Add auto-complete to the command line and everyone will start using long form without the need to beg. Imperfectly remembering the flag spelling is a rather large annoyance, short flags avoid this problem at the cost of crypticism, autocomplete actually solves it.

Or, there should be an automated tool that takes scripts with short flags and displays them with automatically replaced equivalent long flags for readability.<p>Not everything has to be static text, one format does not fit all situations.

At least for scripts that are on github, it seems like this could be potentially tackled by creating a robot that submits pull requests for such scripts, changing the options passed from short to long. For people fine with the change, they could just merge the PR, and for those that don't like it, people still have a long-option version of the script they can check out in the PR.<p>I've not written a github robot, though, this is just based on my vague understanding from the robots already out there (whitespace, .gitignore, etc), so please correct me if this isn't actually feasible. :)

I think the short flags are more useful when using directly the command (outside of a script). It is faster to type man grep in a window and to type grep -Eo than to type grep --extended-regexp --only-matching. At first, I even didn't realize that --extended-regexp was the same as the usual -E flag. I had to check with man.<p>Theoretically, I would like to agree that long flags are better than short ones in scripts. In practice, I prefer grep -E. And I can not imagine a tar cvfhz with long flags.

I too have been using this practice for years now, unfortunately most coworkers don't seem to appreciate the genius of it.

Time to update some of my scripts.

My age probably shows in this statement, but it seems odd to me to suggest that someone else change their behaviour so the poster does not have to rtfm. We're coders. When we don't understand something, we read the manual, then the source.

I accept --silent, but almost everybody knows what -E to grep means. Normally I would just use egrep rather than grep -E however.

heh.. I have never thought of that. I basically script exactly how I construct commands in the cmd line, but the author is correct looking at my past bash scripts it would be better to use long options, good stuff.

Amen!

if you can't read the short flags, you shouldn't be reading my code.

there's always a "man" page (and Google) to look it up, stupid.