From: Junio C Hamano Date: Fri, 23 Sep 2005 08:24:13 GMT Subject: Re: /bin/sh portability question Message-ID: <7vzmq4faz6.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20050923075058.GA25473@bohr.gbar.dtu.dk> "Peter Eriksen" 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 $().