Hacker News Reader

Comment by kps | Hacker News Reader

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

View on HN

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

  wilya@home $ /bin/bash
  zsh: no such file or directory: /bin/bash
  wilya@home $ which bash
  /usr/local/bin/bash

(Yes, I'm annoyed when I see #!/bin/bash, especially on scripts which are otherwise basic enough to be portable everywhere)

It is still better to write #!/bin/bash for bashism using scripts than #!/bin/sh. I recently had to run sed -i (well, another GNUism) 1s%/sh%/bash% on bunch of customer's scripts to make them work on debian. At least when script wants /bin/bash it is going to fail cleanly (and not in the middle after modifying random things) and with mostly meaningful error.

It's probably safer to use:

    #!/usr/bin/env bash

Assuming env is installed (I believe I had to install a package on OpenBSD to use it) this will find the first instance of bash in the PATH.

How do you know env is in /usr/bin rather than in /bin or /usr/local/bin? I'm just curious...

You don't, but I've run into more problems with bash being in unexpected places than env.

Right on, thanks.

Good question. I've used systems, e.g. AIX, where env(1) was in /bin.

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.

When I mentioned "GNU", I think it sort of implied that I am aware of the existence of non-GNU toolchains.

I really am not worried about that in my world. The dependencies on Linux go a great deal deeper than the GNU toolchain. YMMV.

>Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely.

That's not the case for most people though. I can't even remember the last time I saw even a tiny project assume the world is all "whatever gnu/linux distro I happen to use". Tons of people use linux distros that aren't ubuntu, tons of people use OSX, tons of people use a BSD.

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.

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.

I think, like most things, this would depend on who your audience is. For internal use only where you're running under a consistent environment at all times and aren't worried about portability, it probably makes sense to go with the more explicit long options.

For something you're planning to deploy to customers, it probably makes sense to play it pretty strict with POSIX.

Likewise, I usually script straight sh for portability if it's going to a customer unless there's a compelling reason to use bash. I'll mix in bash in stuff I write for myself where it makes my life simpler.

Reply on news.ycombinator.com