11 ms·
Use long flags when scripting
- shizcakes 14y agoThis is a practice I use; in my opinion it is akin to descriptive variable names.
- 6ren 14y agoIronically, tab-completion works on the command-line for long options, but not in a script (I'm sure vim can do it though).
- bazzargh 14y agoC-x C-e opens an editor for the command-line, so after you've tab completed it it's easy to save.
- uxp 14y agoWhich is entirely dependent on how the shell is configured (not all shells have tab-completion for option flags, let alone path or command completion). I'm sure Vim or Emacs could do tab-completion for script flags, but you'd be in the same boat in the beginning: Someone has to script it first.
- blktiger 14y agoAmen!
- taylorfausak 14y agoAgreed! It saves a trip to the man page. 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: echo thing | grep thing
- pmattos 14y agoI have seen this working, but didn't understand why... thanks!
- mooism2 14y agoAlso works with the && and || operators.
- ygra 14y agoI'd probably indent the grep in that case, though, to make things clearer. My own PowerShell scripts often take the form of Get-Foo | Where-Object { $_.blah } | ForEach-Object { ... } etc., especially with longer pipelines.
- captn3m0 14y agoTime to update some of my scripts.
- pmattos 14y agoI too have been using this practice for years now, unfortunately most coworkers don't seem to appreciate the genius of it.
- kps 14y agoNo. Use standard POSIX flags to invoke standard POSIX functionality, so your scripts don't break when run on a different system.
- mauvehaus 14y agoI think, like most things, this would depend on who your audience is. For internal use only where you're running under a consistent environment at all times and aren't worried about portability, it probably makes sense to go with the more explicit long options. For something you're planning to deploy to customers, it probably makes sense to play it pretty strict with POSIX. Likewise, I usually script straight sh for portability if it's going to a customer unless there's a compelling reason to use bash. I'll mix in bash in stuff I write for myself where it makes my life simpler.
- jerf 14y agoIt's always a cost/benefits analysis. I think for a lot of us, the cost/benefit goes something like this: "Will I ever have to read and modify this script again? Effectively-100% likely. Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely." It's a no-brainer at that point. If you can't say that second part honestly, reconsider, but a lot of us can.
- lamby 14y ago> Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely. Not really. A lot of stuff broke when /bin/sh moved to a POSIX-compatibile shell rather than Bash.
- joshbaptiste 14y agoheh.. 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.
- xutopia 14y agoI 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.
- jstanley 14y agoI accept --silent, but almost everybody knows what -E to grep means. Normally I would just use egrep rather than grep -E however.
- shurcooL 14y agoOr, there should be an automated tool that takes scripts with short flags and displays them with automatically replaced equivalent long flags for readability. Not everything has to be static text, one format does not fit all situations.
- dclowd9901 14y agoAs 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. 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.
- ajross 14y agoLike everything else it depends. "rm -rf" is a lot easier to read than "--recursive --force" simply because every likely maintainer will (1) already know the short form and (2) will have no idea the long form options even exist. Likewise arguments to tar are probably best left in traditional form, etc... Don't rock the boat just to adhere to silly style rules. The goal is readability. You're probably already the best judge of what is most readable, so trust your intuition. If you had to look it up, then spell it out. If not, relax and do it the sane way.
- ojbyrne 14y agoI think the correct answer is do both.
- deleted 14y ago[deleted]
- niggler 14y agoMany utilities have long-form names in GNU flavors but not in BSD flavors, so it would seem that using short form is best. However, there are some tools that are not the same (where the bsd flag differs) ...
- hnolable 14y agoDisagree. There isn't and shouldn't be any hard fast rule for this. Same as most things in programming. Do what makes sense. Also, [0-9.] not [0-9\.]
- eli 14y agoIMHO, if your intent is to capture a literal dot then you should escape it even if, based on the context, you don't have to.
- StavrosK 14y agoI agree with this. Regexps in general encourage a bit of "if unsure, escape".
- ralph 14y agoThen you could be introducing errors into your regexps. \x doesn't mean a plain x instead of the metacharacter x in all cases. Don't ship code you don't at least think you understand.
- ralph 14y agoNo, that's wrong, a reader that knows his onions, e.g. me, will be puzzled as to what the writer's intent was and spend time investigating if there is an error before deciding the writer needs to spend more time studying his onions.
- logn 14y agoAgreed. Regexes are already confusing. Adding unnecessary escaping just makes them worse. And if you have [\.] was the intent to escape the dot or match a slash? It's confusing.
- eli 14y agoI think the goal should be clarity, not conservation of characters. And I think the escaped dot is clearer (the author's intent is obviously to include a dot in the range). I do think it's funny that you said "There isn't and shouldn't be any hard fast rule for this" and then one comment later said my approach is "wrong" :) (EDIT: oops, that wasn't you -- Sorry!)
- opk 14y agoFor 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.
- nathanstitt 14y agoA secondary benefit not mentioned in the article is immutability. Long flags on a command line utility should never change. Short flags may be modified between major versions of a utility, which would break scripts. 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.
- Flimm 14y agoNeither long flags or short flags should change meaning. I'm not sure where you got the idea that short flags do.
- nathanstitt 14y agoYou now, I'm really not sure where I picked that up. It's always been my understanding that it was acceptable to change the short flags on a utility as part of a new major version. Not that you should change 'em capriciously, but that it wasn't the end of the world if you did. Of course, I can't find any references to back me up on that, so you may very well be correct.
- zxtang 14y ago"GNU grep 2.12 changes behavior of recursion options, breaks existing scripts": http://news.ycombinator.com/item?id=4295681 http://news.ycombinator.com/item?id=4295681
- pacala 14y agoAdd 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.
- npsimons 14y agoFirst and foremost, the article talks about flags in files, where your IDE of choice can probably autocomplete them (see http://emacswiki.org/emacs/DynamicAbbreviations http://emacswiki.org/emacs/DynamicAbbreviations for an example). Second, even on the commandline, bash_completion (http://www.gnu.org/software/bash/manual/html_node/Programmable-Completion.html http://www.gnu.org/software/bash/manual/html_node/Programmab...) has been available for a while now.
- ralph 14y agoThis is silly. I can type grep's "-iv" before your auto-complete has enough info entered to complete the first option alone; "--i<Tab>" would beep, needing a "g" to continue.
- webreac 14y agoI 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. 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.
- npsimons 14y agoWhile 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. This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short): http://news.ycombinator.com/item?id=5165058 http://news.ycombinator.com/item?id=5165058 But these are not universally supported: http://unixhelp.ed.ac.uk/CGI/man-cgi?ps http://unixhelp.ed.ac.uk/CGI/man-cgi?ps 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. 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.
- webreac 14y agoI think you fail on two software engineering principles: * http://en.wikipedia.org/wiki/KISS_principle http://en.wikipedia.org/wiki/KISS_principle * you should adapt the way you think about programming to the language you are using. This is shell, not Ada.
- jcurbo 14y agoSure, but what's wrong with his approach? POSIX sh supports all the things you need to do 'if GNU grep run this, else if BSD grep run that' - functions, case statements, conditionals. He's not talking about building up major libraries in shell, just wrapping the invocations in functions based on the environment you're in.
- npsimons 14y agoUnfortunately, taken as a whole (eg, not just blithely ignoring POSIX, or systems that don't support it, or systems that don't support long options), portable shell is a big mess. Keeping it simple would be nice, but may not be possible, depending on your goals ("make everything as simple as possible, but no simpler"). So you want to write some script that will only ever run on systems with GNU utilities installed, and you never ever plan on porting it? Fine. Just do the world (and yourself) a favor and be aware of and admit that fact upfront. And if you're going to break POSIX compatibility anyway, it would be nice if you use the long options for better readability.
- ralph 14y agoThis 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. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n
- skrebbel 14y agoThe difference is that with long flags, even someone without 10 years of POSIX experience knows what's going on. The long example on the OP's article makes a lot of sense to me, even though I'm primarily a Windows user. At the same time, for instance, I've no idea what the -tr flag to ls does, even though I use ls often enough.
- ralph 14y agoYou are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success. BTW, a month of using Unix should have a Unix user knowing what ls's -t and -r flags do, along with -a and -l they're some of its most commonly used.
- saint-loup 14y agoI'm sorry, but this is terribly pedantic. The world isn't divided between deep experts of a technology and everyone else. Case in point: me, a moderately tech-savvy person. My main computer is a Mac and I'm a casual user of bash. I struggle to get things done every time I have to do something more complicated than "show me the files of this folder, even the hidden ones, even in the subfolders, then dump them in a .txt". The obscurity of flags don't help.
- 14y ago
- natefinch 14y agoThis 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. And god forbid you think 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). 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).
- rohit6223 14y agoI 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 & readable code by using short flags for most of the command functionalities. Consider something like this: $ rsync -qaogtHr example.com:/opt/data/ /home/backup/ 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. 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. Long options may help beginners, but once they get comfortable, Short flags may seem more readable!!
- james-manning 14y agoAt 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. 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. :)
- evandrix 14y agoif you can't read the short flags, you shouldn't be reading my code.
- evandrix 14y agothere's always a "man" page (and Google) to look it up, stupid.
- darrikmazey 14y agoMy 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.