Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

21–30 of 197 posts

Re: Use long flags when scripting (2013)

#21

Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…

Long flags aren’t just for readability, they also add entropy which contributes defensiveness against typos.

Re: Use long flags when scripting (2013)

#22
post #2

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

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…

Yes, if you care about portability. Anything that's not Linux likely won't have GNU grep installed by default. This includes macOS and the BSDs.

If this is your own dotfiles or utilities, sure, but if I'm working on something collaborative, yes, I care about the standard.

Re: Use long flags when scripting (2013)

#23
post #2

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

Portable shell scripts probably run on your system all the time, e.g. when installing development tools or packages, especially for cross-platform languages like Node.js, Ruby, Python, etc... If a hunk of software wants a shell script, it's gonna be portable.

Homebrew comes to mind, and any other piece of software that does the installation via a shell script.

Re: Use long flags when scripting (2013)

#24
post #2

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

If you've ever run a ./configure script before building a program, you have encountered a script intended for use on multiple Unix flavors.

Re: Use long flags when scripting (2013)

#25
post #3

In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg

It's nice but you cannot comment individual lines. For that you can go one step further and use arrays: cmd=( command -x -y --bar OPTARG ARG ARG ) $cmd This works in Zsh. In Bash that would be ${cmd[@]} I think. I use this with long qemu command lines where I often modify and comment out arguments during testing.

For bash, add quotes: "${cmd[@]}"

Otherwise, you'll get word splitting. E.g.,

  cmd=(
   test
   "!= !="
   !=
   ""
  )
  "${cmd[@]}" && echo Success
  ${cmd[@]} || echo Failure

Re: Use long flags when scripting (2013)

#27

Earlier quoted context omitted.

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

You don't know that your script will run fine anywhere, if you've not actually run it there.

But, still, that's no reason to adopt a mindset of actively wrecking the chances of such success.

(Which is what passive ignorance amounts to, effectively).

Re: Use long flags when scripting (2013)

#28
post #3

In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg

Downside: forgetting a \ will truncate the flags list, leading to unexpected behaviour followed by an error.

Re: Use long flags when scripting (2013)

#29
It’s not just “easier for a human” but more stable over time as commands evolve, and less likely to do weird things across Unix variants.

Some command-line parsers will auto-complete partial options so you’re less likely to see ambiguity errors in future versions if you picked long-form options. (This isn’t completely foolproof, e.g. a command could have "--foo" and later add "--foobar" but it does help in most cases.)

And unfortunately, some tools with the same name will use the same letter to mean different things across Unix variants. You are asking for trouble if you aren’t being clear about what you want.

Post reply on HN