Hello, Alan wrote me about the following issue. I don't know anything about bash/sh issues (except that sh is indeed more likely to be present and that I had to change many occurencies of /bin/sh to /bin/bash on garden because /bin/sh was a symlink to dash which didn't work). Does anyone object the change from bash to sh? Mojca On Wed, Apr 13, 2011 at 21:16, Alan BRASLAU wrote:
Mojca,
Back at home and following the mailing list after a gruesome hunt for the Apple Store in Paris?
One request (not just for me :)) in first-setup.sh, please change #!/bin/bash to #!/bin/sh
This is more general. 1. Not everyone has bash installed on their machine (but *everyone* always has /bin/sh, [sometimes as a link to bash]) 2. Bash is not always to be found as /bin/bash (it could be /usr/local/bin/bash, for example).
Of course, I cannot speak for MacOS, known to be weird.
Alan
On Sun, Apr 17, 2011 at 00:21, Mojca Miklavec wrote:
Hello,
Alan wrote me about the following issue. I don't know anything about bash/sh issues (except that sh is indeed more likely to be present and that I had to change many occurencies of /bin/sh to /bin/bash on garden because /bin/sh was a symlink to dash which didn't work). Does anyone object the change from bash to sh?
Dear Alan, at the same time a question for you: do you also experience any issues with ./do-all.sh and other scripts in "build the latest binaries"? I just checked and they start with #!/usr/bin/env bash How does that compare? (I agree that it probably makes sense to do the change, I just wanted to hear from others and maybe I need to find a good reference to what is not allowed in sh that works in bash.) On mac it is:
sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Mojca
On Sun, 17 Apr 2011, Mojca Miklavec wrote:
change, I just wanted to hear from others and maybe I need to find a good reference to what is not allowed in sh that works in bash.)
The bash user manual: http://www.faqs.org/docs/bashman/bashref_122.htmlhttp://www.faqs.org/docs/ba...
On mac it is:
sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
On linux, sh either links to bash or dash. Aditya
On 04/17/2011 12:47 AM, Aditya Mahajan wrote:
On Sun, 17 Apr 2011, Mojca Miklavec wrote:
change, I just wanted to hear from others and maybe I need to find a good reference to what is not allowed in sh that works in bash.)
The bash user manual:
http://www.faqs.org/docs/bashman/bashref_122.htmlhttp://www.faqs.org/docs/ba...
Alan is right that not everyone has bash, but on the other hand, *nobody at all* has the actual /bin/sh from the Unix manual, so finding documentation on what it could and could not do is hard and a little pointless, but the autoconf manual has a rather good chapter on "portable shell scripting": http://www.gnu.org/s/hello/manual/autoconf/Portable-Shell.html Also, since almost all people that have trouble with bash these days seem to be running dash, I would guess this man page is useful: http://linux.die.net/man/1/dash and perhaps you could install a /bin/dash for testing. Best wishes, Taco
On Sunday 17 April 2011 00:26:20 Mojca Miklavec wrote:
On Sun, Apr 17, 2011 at 00:21, Mojca Miklavec wrote:
Hello,
Alan wrote me about the following issue. I don't know anything about bash/sh issues (except that sh is indeed more likely to be present and that I had to change many occurencies of /bin/sh to /bin/bash on garden because /bin/sh was a symlink to dash which didn't work). Does anyone object the change from bash to sh?
Dear Alan,
at the same time a question for you: do you also experience any issues with ./do-all.sh and other scripts in "build the latest binaries"? I just checked and they start with #!/usr/bin/env bash How does that compare? (I agree that it probably makes sense to do the change, I just wanted to hear from others and maybe I need to find a good reference to what is not allowed in sh that works in bash.)
On mac it is:
sh --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Mojca
This is one solution that would probably work (if bash is present, but, again, it is not by default on many systems). Another would be to write clean shell scripts, whenever possible, that do not rely on bash-isms, and would work everywhere, even with dash: "DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks." This should not be much of a constraint. Alan -- Alan Braslau CEA DSM-IRAMIS-SPEC CNRS URA 2464 Orme des Merisiers 91191 Gif-sur-Yvette cedex FRANCE tel: +33 1 69 08 73 15 fax: +33 1 69 08 87 86 mailto:alan.braslau@cea.fr .''`. : :' : `. `'` `-
Hi, just try it on an ubuntu machine and see if it works. I think that dash (on ubunutu /bin/sh) is the "most incompatible" sh you will be able to get. If it runs on ubuntu with /bin/sh then it will work everywhere with /bin/sh, I'd assume. Patrick
Sundag 17. april 2011 skreiv Mojca Miklavec:
Alan wrote me about the following issue. I don't know anything about bash/sh issues (except that sh is indeed more likely to be present and that I had to change many occurencies of /bin/sh to /bin/bash on garden because /bin/sh was a symlink to dash which didn't work). Does anyone object the change from bash to sh?
What you would want to do is change bash to sh, and ensure that all the scripts follows the POSIX standard 100%. Then it will work in both bash, dash, ksh and *any other* POSIX-compatible shells. You can read the POSIX standard in HTML format at http://pubs.opengroup.org/onlinepubs/9699919799/ (You may have to register to view it, but it’s completely free.) If you have the POSIX man pages installed (you may already have them without knowing), you can read the POSIX version documentation of various commands. For example, instead of writing man mkdir or man 1 mkdir type man 1p mkdir As you see, the POSIX man pages are *much* more precise (and verbose!), using the word ‘shall’ often, leaving no doubt of exactly what each command and options should do, in all edge cases. That may make them harder to read, but some times they’re actually more clear than the normal man pages. bash is POSIX compatible (all POSIX commands should work 100%), but you may have to set export POSIXLY_CORRECT=1 to ensure that bash follows the spec in some rare special cases. (This also has an effect on other utilities, like (g)awk.) bash will still support non-POSIX constructs, though (like using two equals sign in tests), so you really should test the scripts in dash, which *doesn’t* allow non-POSIX constructs (AFAIK), and is faster too. This Web page may be useful: http://mywiki.wooledge.org/Bashism There also is a ‘checkbashisms’ scripts, which I haven’t tried. -- Karl Ove Hufthammer http://huftis.org/ Jabber: karl@huftis.org
On 04/17/2011 09:45 AM, Karl Ove Hufthammer wrote:
Sundag 17. april 2011 skreiv Mojca Miklavec:
Alan wrote me about the following issue. I don't know anything about bash/sh issues (except that sh is indeed more likely to be present and that I had to change many occurencies of /bin/sh to /bin/bash on garden because /bin/sh was a symlink to dash which didn't work). Does anyone object the change from bash to sh?
What you would want to do is change bash to sh, and ensure that all the scripts follows the POSIX standard 100%. Then it will work in both bash, dash, ksh and *any other* POSIX-compatible shells.
Everything except 'sh', then ? ;)
Sundag 17. april 2011 skreiv Taco Hoekwater:
What you would want to do is change bash to sh, and ensure that all the scripts follows the POSIX standard 100%. Then it will work in both bash, dash, ksh and any other POSIX-compatible shells.
Everything except 'sh', then ? ;)
Well, I doubt the orginal Bourne shell from 1977 is POSIX compatible. ;-) But the POSIX standard actually defines the name of the shell utility ‘sh’, so all POSIX-compatible must have a ‘sh’. It may not be placed in /usr/bin, of course, though on most sane platforms it is. :) If you *really* want to be general, you can use the POSIX command command -v sh to find it. (No, don’t use ‘which’; it is not POSIX, and will only work if the command is an application, not a built-in.) -- Karl Ove Hufthammer http://huftis.org/ Jabber: karl@huftis.org
participants (6)
-
Aditya Mahajan -
Alan Braslau -
Karl Ove Hufthammer -
Mojca Miklavec -
Patrick Gundlach -
Taco Hoekwater