4 ms·

For writing portable scritps, I strongly advise against using anything not in the POSIX spec. No matter how many shells you've tested it in, there will always

by mansr 16y ago

For writing portable scritps, I strongly advise against using anything not in the POSIX spec. No matter how many shells you've tested it in, there will always be one somewhere that doesn't implement it. Conversely, if a POSIX feature is found to be broken in at least one moderately common shell, it should be avoided or worked around if at all practical.

asb 16y ago
I like the ability to have local variables though, which isn't in the POSIX standard. However, the Debian Policy Manual does state that any /bin/sh shell should be posix-compliant and support local variables (along with a couple of other minor extensions). This means I'm fairly comfortable using them despite their absence from the standard. http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts http://www.debian.org/doc/debian-policy/ch-files.html#s-scri...
apenwarr 16y ago
This is generally good advice, but redo tries to do something else: it actually tests all your shells, and picks the one that supports the features we're expecting. That way we can set a minimum baseline. All the features in the article are tested by redo, so at least in your redo scripts, you can assume those features are available. Maybe someone can generalize the "redo-sh" feature somehow.
Create 16y ago
I would just like to mention, that in order to really take the pain out of portable scripting, the easiest way to go is python scripts - and forget about the differences between win32, bash, csh and the rest.
- bch 16y ago
  That's what I do (s/Python/Tcl/). I feel pretty comfortable doing it, but a -little- uneasy. I feel like I'm cheating; I usually prescribe (and follow) "as dumb as possible (but no dumber)" rule, and use /bin/sh as my interactive shell to keep from relying on non-portable "creature-features". Using /bin/sh satisfies the "as dumb as possible..." rule because it's basic, standard, and everywhere. However, as soon as a shell script starts getting moderately complicated, I feel more comfortable moving to something (Tcl) that's (to my mind) less obtuse and less surprising. edit: and then I read http://news.ycombinator.com/item?id=2271004 http://news.ycombinator.com/item?id=2271004 further below, which makes Tcl (or python, or ...) look even better.
  - zem 16y ago
    > I usually prescribe (and follow) "as dumb as possible (but no dumber)" rule to what end?
    - bch 16y ago
      To my mind, the "dumb" tools are the simple ones that often ship w/ Unix, and using them forces understanding of principles, rather than rote memorization of meta-commands. From that (the hope is that) one can _understand_ what a problem is, and now to fix it.
- georgecmu 16y ago
  This works great as long as your definition of portability extend only to systems with python (or perl, or tcl, or php, or ruby) installed. Shell is the least common denominator.
bryanlarsen 16y ago
As the converse, if you don't know what's in the POSIX spec, or haven't tested widely, please put "#!/usr/bin/env bash" at the top of your script. Most people who don't have bash as the default shell at least have it somewhere. And those who don't would rather have your script fail with an obvious error than a subtle one.
- mansr 16y ago
  If you don't know what's in the POSIX spec, you should go and read it. If you do this, you will learn not only what the shell must do, but also that /usr/bin/env might not exist at all. The env utility is required, but it isn't always in /usr/bin.

by mansr 16y ago

asb 16y ago

I like the ability to have local variables though, which isn't in the POSIX standard. However, the Debian Policy Manual does state that any /bin/sh shell should be posix-compliant and support local variables (along with a couple of other minor extensions). This means I'm fairly comfortable using them despite their absence from the standard. http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts http://www.debian.org/doc/debian-policy/ch-files.html#s-scri...

apenwarr 16y ago

This is generally good advice, but redo tries to do something else: it actually tests all your shells, and picks the one that supports the features we're expecting. That way we can set a minimum baseline. All the features in the article are tested by redo, so at least in your redo scripts, you can assume those features are available. Maybe someone can generalize the "redo-sh" feature somehow.

Create 16y ago

I would just like to mention, that in order to really take the pain out of portable scripting, the easiest way to go is python scripts - and forget about the differences between win32, bash, csh and the rest.

bch 16y ago
That's what I do (s/Python/Tcl/). I feel pretty comfortable doing it, but a -little- uneasy. I feel like I'm cheating; I usually prescribe (and follow) "as dumb as possible (but no dumber)" rule, and use /bin/sh as my interactive shell to keep from relying on non-portable "creature-features". Using /bin/sh satisfies the "as dumb as possible..." rule because it's basic, standard, and everywhere. However, as soon as a shell script starts getting moderately complicated, I feel more comfortable moving to something (Tcl) that's (to my mind) less obtuse and less surprising. edit: and then I read http://news.ycombinator.com/item?id=2271004 http://news.ycombinator.com/item?id=2271004 further below, which makes Tcl (or python, or ...) look even better.
- zem 16y ago
  > I usually prescribe (and follow) "as dumb as possible (but no dumber)" rule to what end?
  - bch 16y ago
    To my mind, the "dumb" tools are the simple ones that often ship w/ Unix, and using them forces understanding of principles, rather than rote memorization of meta-commands. From that (the hope is that) one can _understand_ what a problem is, and now to fix it.
georgecmu 16y ago
This works great as long as your definition of portability extend only to systems with python (or perl, or tcl, or php, or ruby) installed. Shell is the least common denominator.

bryanlarsen 16y ago

As the converse, if you don't know what's in the POSIX spec, or haven't tested widely, please put "#!/usr/bin/env bash" at the top of your script. Most people who don't have bash as the default shell at least have it somewhere. And those who don't would rather have your script fail with an obvious error than a subtle one.

mansr 16y ago
If you don't know what's in the POSIX spec, you should go and read it. If you do this, you will learn not only what the shell must do, but also that /usr/bin/env might not exist at all. The env utility is required, but it isn't always in /usr/bin.