Re: patch for problems with echo '-...' and echo '...\...'

[Ralf Wildenhues]

Hello Paul, 

Paul Eggert writes:
> Ralf Wildenhues <address@hidden> writes: 
>
> > I thought file names beginning with a hyphen were explicitly discouraged
> > in POSIX, but I can't find a statement to this extent in SUSv3 now.
>
> They are/were discouraged, but almost all systems support them anyway,
> and we should also support them too, if we can.

Hmm.  This support may be well-intended, but certainly there are cases left
in Autoconf that will break if you actually try to use that.  Just as we
don't _really_ support white space in arbitrary file names (thinking of
AC_CHECK_PROG), I think we'd be off good enough stating that a beginning
hyphen is plainly stupid.  I've never seen real-world usage for this. 

> > Hmm.  Backslashes in file names are really unlikely though.
>
> True, but we should handle them correctly if they come up.

But with that argument, we'd have to fix white space first.  Backslashes 
IMVHO come far after white space as far as importance in real-world
systems' file names. 

> > > $usage might contain backslashes.
> >
> > Not really.  I've yet to see a 'program --help' output that contained
> > backslashes.
>
> It can contain backslashes if Autoconf is installed into a directory
> whose name contains a backslash.  '/foo/bar\naz/bin/autoconf --help'
> should output a backslash, not a newline.

Erm, it should use the basename of the program name. 

> > Now to the patch.  Besides all the technicalities (see inline comments)
> > this change causes quite some slowdown on script execution.
>
> When you say "this change", do you mean just the patch you enclosed,
> or the overall idea of using printf rather than echo?  Also, are you
> talking about the typical case where printf and echo are both builtin,
> or about the unusual case on old-fashioned shells where printf is not
> builtin, or printf is buggy, or both?

Good questions.  With "this change", I was speaking about the overall
changes done in this thread.  The slowdown is typically only large if
an external program is used, rather than a builtin.  So using a builtin
printf is fine with me.  On a GNU/Linux system with bash, there is hardly
any slowdown (except for the initial test, but that is ok IMHO). 

> > Can we at least do some optimization, say, by using plain echo if
> > AS_IF_LITERAL matches and no backslashes and no hyphen at the
> > beginning?
>
> That's what I did in the patch where I started using AS_ECHO.  If I
> could prove to myself that the argument could not contain backslashes
> and could not start with '-', I left it alone: it's still using plain
> 'echo'.  At least, that's what I tried to do.  I did this partly for
> the performance reasons you mention, partly to minimize changes to the
> code, and partly because 'echo foo' is easier to read than
> 'AS_ECHO([foo])'.

But there is possibility for more: if the user issues
AC_CACHE_CHECK([whether foo works], ...) 

then we can know that this is a constant string (lest m4 macro expansion
of the text). 

> > The other possibility for optimization would be to take this test into
> > account in our search for a better shell: prefer a shell with an echo
> > that does what we want.
>
> I don't know of any echo that does what I want, which is to output an
> argument without any interpretation.  POSIX allows such an echo, but
> all the echo implementations I know of either interpret -n (and
> perhaps some other -xxx), or (as POSIX+XSI requires) interpret
> backslashes.

I was thinking of preferring a shell with a builtin functioning printf,
if we can find this out portably.  Any idea how we can reliably detect
a command being builtin? 

> Something like that sounds good to me, though I'd rather have
> 'configure' prefer a shell with a printf that does what we want.
> I think 'echo' is a lost cause.

Yes, that is fine. 

> Does the existing _AS_DETECT_BETTER_SHELL already detect a shell with
> a working printf on Solaris 7?  If so, then as a practical matter we
> may be done.

On the systems I tested, it chooses /bin/ksh and /usr/ucb/echo (with my
previous patch).  But I take measures to omit $PATH entries that point
to an externally supplied bash and other GNU software, for testing purposes. 

> > I see that there are
> > a couple of AS_ECHO invocations (in error paths) before the expansion of
> > _AS_DETECT_BETTER_SHELL, but sacrificing them would not bother me.
>
> Me neither; we could reword them to avoid the troublesome characters.

OK.  Let's see if we can move that way. 

Thanks, and cheers,
Ralf