Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

I write lots of scripts that need to work on both Linux and MacOS. Although both are POSIX, filenames in MacOS are case-insensitive and often contain spaces. This stuff plays havoc with bash scripts written by naive Linux programmers. Following TFA's recommendations ensures that your scripts will work on both.*

* well, except for the fact that MacOS defaults to zsh now.

View on HN

To be clear: I agree with every recommendation in this article. I just find that writing POSIX-compliant shell is rarely needed. I've clarified my comment.

> well, except for the fact that MacOS defaults to zsh now.

But Zsh is also POSIX sh compatible, is it not?

No.

Afaik it can be thou

Zsh is not POSIX compatible. You need to enable many flags to make it POSIX compatible.

Zsh:

  $ A="foo bar baz"; for X in $A; do echo $X; done 
  foo bar baz

Dash:

  $ A="foo bar baz"; for X in $A; do echo $X; done 
  foo
  bar
  baz

> You need to enable many flags to make it POSIX compatible.

or use 'emulate sh' to enable many flags at once.

(and I personally would prefer if other shells would behave like Zsh and not word split unquoted variables by default)

This is true for the Bourne Again, Watanabe, and Korn shells too. The default mode is not the POSIX-conformant mode, but is the shell's native mode. This does not, however, make these shells "not POSIX compatible" any more than it makes the Z shell "not POSIX compatible". In all of them, one has to do non-default stuff, from setting particular environment variables through invoking the shell with a particular name to adding extra command-line options, to pick the POSIX-conformant mode.

The Z, Korn, Debian Almquist, Watanabe, and Bourne Again shells are all capable of running POSIX-conformant scripts. So if one has a POSIX-conformant shell script, one can use the Z shell to run it, yes.

The major factors when it comes to portability are, for all of them, that (a) the POSIX-conformant mode has to be specially invoked, and (b) even if invoked in conformance mode the non-POSIX parts are not always turned off. It's not that the shells won't handle POSIX-conformant scripts. They even mostly will in their (default) non-conformant modes. It's rather that it's difficult to discipline onesself to keep within the bounds of POSIX conformance when writing, even if one tests with conformance mode switched on.

The Debian Almquist and Watanabe shells are the best at preventing non-POSIX stuff creeping in by accident, because the former doesn't have much of it in the first place and the latter actually does things like turn off non-POSIX option arguments and builtins so that they generate errors in conformance mode and one can detect accidental "Yashisms" in testing. With the others, it's easier to accidentally use some of their various extensions and not spot it without explicitly testing with something in addition to the shell in its POSIX-conformant mode.

Sorry to be so naive.. who is TFA?

The fine[1] article.

1. Originally from RTFM -> RTFA -> TFA, so feel free to use your own substitution for F, but in this case it's a fine article.

I've always thought of it as "the full article", having not made the connection :p

I think it's more broadly applicable

The foregoing article

Reply on news.ycombinator.com