[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralf Wildenhues
Subject: Re: patch for problems with echo '-...' and echo '...\...'
Date: Sat, 02 Dec 2006 11:36:56 +0100

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

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

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

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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]