Re: Implement dash as bootstrap shell

[Richard PALO <richard%netbsd.org@localhost>]

Le 05/12/15 16:48, Jonathan Perkin a écrit :
> FWIW, $LINENO is now supported.
> 

Okay, great. BTW LINENO is clearly POSIX.  And libtool, for one uses it.

Guess the local/typeset issue is more us/them and not POSIX....

If dash is the configure shell, then it is typically the shell used in REPLACE_SH isn't it?

Is it worth looking to see with portability checking whether typeset/local is used at runtime in updated scripts?

Also, http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins
talks about traps:
> trap
>     It is safe to trap at least the signals 1, 2, 13, and 15. You can also trap 0, i.e., have the trap run when the script ends (either via an explicit exit, or the end of the script). The trap for 0 should be installed outside of a shell function, or AIX 5.3 /bin/sh will invoke the trap at the end of this function.
> 
>     Posix says that ‘trap - 1 2 13 15’ resets the traps for the specified signals to their default values, but many common shells (e.g., Solaris /bin/sh) misinterpret this and attempt to execute a “command” named - when the specified conditions arise. Posix 2008 also added a requirement to support ‘trap 1 2 13 15’ to reset traps, as this is supported by a larger set of shells, but there are still shells like dash that mistakenly try to execute 1 instead of resetting the traps. Therefore, there is no portable workaround, except for ‘trap - 0’, for which ‘trap '' 0’ is a portable substitute. 

For example I noticed a number of scripts installed use 'trap' so I'm curious about potential runtime fallout if this happens
to still be an issue with dash.

That is, I'm running with pdksh now with bulk-medium + numerous other packages without pdksh issues (that haven't been 
fixed or already replaced with something else).

I'm not opposed to dash, don't get me wrong, I am simply unfamiliar with it and don't treasure having
to deal with yet more unexpected fallout.

-- 
Richard PALO