Live data from Hacker News

Use long flags when scripting

thechangelog.com

21–30 of 133 posts

Re: Use long flags when scripting

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

Re: Use long flags when scripting

#22

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

Re: Use long flags when scripting

#23
post #9

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

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.

Re: Use long flags when scripting

#24
A 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.

Re: Use long flags when scripting

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

Re: Use long flags when scripting

#26

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.

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

Re: Use long flags when scripting

#27
post #23
post #9

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

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.

Re: Use long flags when scripting

#28
post #23
post #9

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

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.

And now porting your script to non GNU such as BSD becomes a pain in the behind ... whereas before maybe only one or two commands would have had to change, now it will be most if not all.

Re: Use long flags when scripting

#29
post #22

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…

I think the correct answer is do both.

Re: Use long flags when scripting

#30
post #19

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.

I agree with this. Regexps in general encourage a bit of "if unsure, escape".
Post reply on HN