Re: [PATCH 6/6] use print or printf or cat as $ECHO

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

Hi Ralf, and thanks for the thoughts,

> > Your filter based on TMOUT is different 
> > than my filter on {BASH,ZSH}_VERSION; I could go either way (I tested that 
> > pdksh also supplies both $TMOUT and print).
> 
> Who guarantees you that ksh supplies TMOUT?

On Solaris, 'man ksh' states:

 The shell gives default values to  PATH,    PS1,  PS2,  PS3,
     PS4,  MAILCHECK,  FCEDIT, TMOUT, and IFS, while HOME, SHELL,
     ENV, and MAIL are not set at all by the shell (although HOME
     is set by login(1)).

I read that as a guarantee that if we are running Solaris ksh, that TMOUT 
starts life set.

But 'man pdksh' does not state anything about TMOUT being predefined; I only 
have emperical evidence that it is, along with pdksh's claim that it tries to 
clone ksh behavior:
$ bash -c 'echo ${TMOUT+set}'

$ pdksh -c 'echo ${TMOUT+set}'
set

>  OTOH, TMOUT is not in any
> way restricted, so a user (more likely: a sysadmin) could set and export
> it, and reasonably so: every Posix shell understands it, bash included.

POSIX does not mention TMOUT, but bash does indeed honor it as an extension to 
POSIX.  Therefore, using TMOUT as the filter means that users who actually 
export it in order to affect bash will be penalized by two forks, while bash 
users that avoid TMOUT are not penalized.

> Where did you get the idea that TMOUT is a reliable way to detect ksh?

You're right - the existence of TMOUT is not a reliable way to detect ksh, and 
I had better not document it as such.  However, the non-existence of TMOUT is 
(so far) a reliable way to detect a non-ksh shell, and since (so far) only 
ksh/pdksh provide print(1), as well as always providing a default for TMOUT, a 
failed TMOUT test is a way to shave off two forks on a shell that is not likely 
to have print(1).

> And since when are 2 forks a suitable tradeoff for portability?

The question at hand boils down to whether there is a way to avoid spurious 
forks up front in testing for the existence of the non-POSIX print(1), vs. the 
desire to avoid later forks by using a builtin in preference to an external 
printf(1).  Since type(1) is not portable, we are reduced to trying a program 
to see if it works, and we must test print(1) prior to printf(1).

If we guess wrong based on the presence TMOUT, we've added two forks on all non-
ksh shells.  But if we guess wrong on a shell that provides a print(1) builtin 
but an external printf(1), we've added many more forks on all printf uses.  
Both incorrect guesses will still execute correctly; so this is just an 
optimization question, and not a portability question.

On the other hand, users are much less likely to export {BASH,ZSH}_VERSION, as 
those don't have documented effects across multiple shells.  And since print(1) 
is not standardized, any test we can do to reliably filter shells that are 
unlikely to have print(1), yet likely to have a working builtin printf(1), 
saves two forks for those shells while still acheiving the desired results of 
using a shell builtin.  This is particularly true for the platforms where forks 
are horrible (cygwin, mingw, ...), where bash rather than pdksh tends to be the 
default shell.

Therefore, I've made up my mind - I like my approach of BASH_VERSION better 
than Paolo's approach of TMOUT as the filter.

-- 
Eric Blake