Re: bashisms

[Ralf Wildenhues]

Hello Ian,

* Ian Beckwith wrote on Wed, May 19, 2010 at 03:54:52AM CEST:
> * trap with signal numbers
> 
> According to http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
> (btw, am I right in saying "The Open Group Base Specifications Issue 6
> IEEE Std 1003.1, 2004 Edition" is POSIX, or at least a part of
> it?),

Not technically, no, but practically, yes.  IIRC.

> POSIX requires signals specified as names (HUP, INT, etc),
> although XSI allows numbers for certain signals (the ones used by
> gnulib all fall into this category).

We've had a similar discussion about this on an Autoconf list a while
ago (with a Debian maintainer).  The Autoconf manual, Shell Portability
chapter, lists 1 2 13 15 as signals which are safe to trap.  I'm not
aware of any shell which does not accept these signal numbers in
practice, except for maybe one that was written specifically to inflict
extra pain upon shell script authors by explicitly disallowing them.

> * type
> 
> All uses of 'type' are along the lines of:
> 
> > possible bashism in gnulib-tool line 552 (type):
> > if (type -p readlink) > /dev/null 2>&1; then
> 
> which won't cause a syntax error but could lead to fallback options
> being chosen unnecessarily. Could these all be replaced by use of
> which(1)?

which is not Posix, unlike type.  Only the -p argument is not Posix,
nor portable.  But you already mentioned that this merely causes a
fallback to be used, so this is not a problem.

> Most uses of shopt are fine, but there is one I'm not sure about:
> 
> > possible bashism in tests/init.sh line 112 (shopt):
> > test -n "$EXEEXT" && shopt -s expand_aliases
> 
> Are there situations where $EXEEXT is set and bash is not running?

That could be the case in cross-compiling situations, or if MinGW revive
their dash package.  However, note the code before this line which will
ensure that a powerful-enough shell is used for executing the following
code.

Cheers,
Ralf