Re: /bin/sh portability question

"Peter Eriksen" [off-list ref] 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 $().