Use long flags when scripting (2013)
changelog.com
Use long flags when scripting (2013)
1–10 of 197 posts
Re: Use long flags when scripting (2013)
#2If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
Re: Use long flags when scripting (2013)
#3In scripts, I usually do stuff like this
command \
--longopt1 \
--longopt2 arg \
argument
command | \
command 2 | \
command 3 \
--opt1 \
--opt2 \
argRe: Use long flags when scripting (2013)
#4In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg
Wow. I just realized I'm terrible for this. I usually format my programming pretty verbosely to make it future-readable but I'm terrible for not doing that in my scripts.
I'll add a comment or something explaining it but now I feel guilty and should probably go back and rewrite a few lines...
I mean—for long scripts I'll break them up but I haven't paid much mind to arguments/flags.
Re: Use long flags when scripting (2013)
#5If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
I've given up trying to be as pure and standard as possible. I could write all my scripts to use `sh`, but `bash` can make things far easier, and in my docker containers is often required by some other package anyway, so may as well just own it.
Re: Use long flags when scripting (2013)
#6If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.
Re: Use long flags when scripting (2013)
#7In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg
If you have a very long command you can run ctrl x e (hold control press x, than e) and edit it in your $EDITOR.
Re: Use long flags when scripting (2013)
#8In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg
Wow. I just realized I'm terrible for this. I usually format my programming pretty verbosely to make it future-readable but I'm terrible for not doing that in my scripts. I'll add a comment or something explaining it but now I feel guilty and should probably go back and rewrite a few lines... I mean—for long scripts I'll break them up but I haven't paid much mind to arguments/flags.
I do this if I have to look up the right flag to use. If it's something commonly seen like "grep -o" or "tar -xvzf" I assume whoever is maintaining the script (probably future me) will be more familiar with the abbreviations than the long versions.
Re: Use long flags when scripting (2013)
#9When writing scripts (CI especially) you'll rarely use, please always use long-flags. It'll save so much headache for the next dev who isn't as up to date with the latest short-hand for az-cli or whatever.
When live scripting, feel free to use short.
Re: Use long flags when scripting (2013)
#10If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.
Yes most of the time the respecting POSIX to the letter is not needed, but it is of course satisfying knowing that your script can run fine on BSDs and other less common distributions :)
Though sometimes you don't need to go that far to break stuff, for instance switching from Fedora to Ubuntu. I've seen many scripts fail on debian derivatives because people think using #!/bin/sh as a shebang is fine since it works on their computer where sh was in fact a symlink to bash.
But on debian based distributions /bin/sh is often dash, not bash, and dash is basically the strict POSIX subset + local, all fancy stuff like [[ ]], &>, arrays, ... will fail.
Though this is less about long options here and more about general shell scripting.