Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use long flags when scripting

thechangelog.com

Post reply on HN
Print view View original

31–40 of 133 posts

Re: Use long flags when scripting

#31

Post by webreac »

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.

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.

Re: Use long flags when scripting

#32

Post by [deleted] »

ajross wrote: post #22
dclowd9901 wrote: post #17

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

Like 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…

[deleted]

Re: Use long flags when scripting

#33

Post by npsimons »

kps wrote: post #9

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

Okay. Care to point us all to the official standard POSIX flags documentation? Even then, you are probably going to find that there are just as many systems that your script needs to run on that are POSIX incompatible as there are systems that don't recognize the long flags.

My ultimate rule: write the code that is the most readable, because in 10, 15, 30 years, someone can easily update a script to working arguments from arguments with long words, whereas single letter arguments may have multiple different meanings on different systems. It's the same with naming conventions and code constructs: the how and the what should be obvious from the code.

Re: Use long flags when scripting

#34

Post by kps »

npsimons wrote: post #33
kps wrote: post #9

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

Okay. Care to point us all to the official standard POSIX flags documentation? Even then, you are probably going to find that there are just as many systems that your script needs to run on that are POSIX incompatible as there are systems that don't recognize the long flags. My ultimate rule: write the code that is the most readable, because in 10, 15, 30 years, someone can easily update a script to working arguments…

For documentation, this will do: http://pubs.opengroup.org/onlinepubs/009695399/utilities/con...

What current systems have arguments that conflict with those?

Re: Use long flags when scripting

#35

Post by ralph »

eli wrote: post #19
hnolable wrote: post #18

Disagree. 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\.]

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

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

Re: Use long flags when scripting

#36

Post by npsimons »

pacala wrote: post #25

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.

First and foremost, the article talks about flags in files, where your IDE of choice can probably autocomplete them (see http://emacswiki.org/emacs/DynamicAbbreviations for an example). Second, even on the commandline, bash_completion (http://www.gnu.org/software/bash/manual/html_node/Programmab...) has been available for a while now.

Re: Use long flags when scripting

#37

Post by npsimons »

kps wrote: post #34
npsimons wrote: post #33

Earlier quoted context omitted.

Okay. Care to point us all to the official standard POSIX flags documentation? Even then, you are probably going to find that there are just as many systems that your script needs to run on that are POSIX incompatible as there are systems that don't recognize the long flags. My ultimate rule: write the code that is the most readable, because in 10, 15, 30 years, someone can easily update a script to working arguments…

For documentation, this will do: http://pubs.opengroup.org/onlinepubs/009695399/utilities/con... What current systems have arguments that conflict with those?

For documentation, this will do: http://pubs.opengroup.org/onlinepubs/009695399/utilities/con....

Thank you for that. I was aware of the POSIX docs for C/system level programming, but I wasn't sure if command arguments were standardized.

What current systems have arguments that conflict with those?

Ah, but "current" is not always what we get. It's been a while, but I can vaguely remember conflicting single character arguments for basic commands (eg, ls, ps) on OSF/1, SunOS and Linux.

Re: Use long flags when scripting

#38

Post by logn »

ralph wrote: post #35
eli wrote: post #19

Earlier quoted context omitted.

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

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

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

Re: Use long flags when scripting

#39

Post by njharman »

lamby wrote: post #27
jerf wrote: post #23

Earlier quoted context omitted.

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

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

No a lot of stuff broke because people depended on implicit rather than being explicit.

    #!/bin/bash

Re: Use long flags when scripting

#40

Post by eli »

ralph wrote: post #35
eli wrote: post #19

Earlier quoted context omitted.

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

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

I 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!)

Post reply on HN