Use long flags when scripting
21–30 of 133 posts
Re: Use long flags when scripting
#22As 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.
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
#23No. Use standard POSIX flags to invoke standard POSIX functionality, so your scripts don't break when run on a different system.
"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
#24Long 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
#25Re: Use long flags when scripting
#26As 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.
Re: Use long flags when scripting
#27No. 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.
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
#28No. 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
#29As 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…
Re: Use long flags when scripting
#30Disagree. 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.