Re: ./configure vs. user-defined bash function "print"

[Mike Frysinger]

On Tue 08 Jul 2014 06:51:46 Greg Minshall wrote:
> hi.  the following fragment from a ./configure
> ----
> # Prefer a ksh shell builtin over an external printf program on Solaris,
> # but without wasting forks for bash or zsh.
> if test -z "$BASH_VERSION$ZSH_VERSION" \
>     && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
>   as_echo='print -r --'
>   as_echo_n='print -rn --'
> elif
> ----
> plays poorly with a user-defined bash function named "print" (basically,
> a front end to pr(1)).

how would a user-defined bash function be a problem ?  unless you're sourcing 
the configure script, a new shell instance is launched to process configure.  
in non-interactive mode, bash doesn't load any files (except via BASH_ENV, but 
that's a really bad idea to use).

> ./configure hangs, waiting for print to end
> (which, in turn, is waiting on a end-of-file on stdin).
> 
> i've seen an idiom like "`echo | print -r -- $as_echo` used before, and
> maybe that's to avoid this sort of situation?

i don't think so.  if you're busting the shell env, i think you get the 
pieces.  what if you defined an echo() function that did `sudo reboot` ?  why 
should autoconf protect against that ?
-mike

signature.asc
Description: This is a digitally signed message part.