Re: /bin/sh portability question

From: Junio C Hamano <junkio@cox.net>
Date: Sep 23, 2005, 08:24 UTC
Message-ID: <7vzmq4faz6.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050923075058.GA25473@bohr.gbar.dtu.dk>

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> 1) Maybe I didn't notice some new configuration option,
>    but strcasestr is still not found with a simple "gmake".

Perhaps "gmake NO_STRCASESTR=YesPlease"?

Do people use glibc or other alternative C libraries on Solaris these days? If nobody does, and everybody on SunOS lack strcasestr, we could make SunOS imply NO_STRCASESTR in the Makefile.

> 2) In many of the shell scripts there is the idiom:

>    I think it's because (on my Solaris at least), sh is really 
>    sh and is not symlinked to bash, and sh doesn't like that 
>    syntax.

Writing $(command) instead of `command` is not a bashism; Korn supports it and even ash seems to. But saying that would not reduce the pain from non-sysadmins.

In many places we could just rewrite them to old-timer back-tick form, unless we nest, in which case you would end up doing something like this for readability:

	foo=$(command $(command to compute arg to it))

	arg=`command to compute arg to it`
        foo=`command "$arg"`

I haven't assessed the extent of damage if we tried to use `` for portability lately (I did once, and it did not look too bad back then). If somebody comes up with a readable patch, I might be persuaded to take it [*1*].

Another thing that will bite you is the use of shell arrays -- I was trying to stay away from it but at least git-grep uses it now (and hopefully nobody else). It may not be a bad idea to rewrite that one script in Perl or Python.

[Footnotes]

*1* Personally I feel that the only bug in Bourne was that it did not spell command substitution as $().