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

[Paul Eggert]

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.  Backslashes in file names are really unlikely though.

True, but we should handle them correctly if they come up.

>> $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.

> Do you know a use case that needs the newlines-at-end differences?

I haven't run into a practical case where it's important, but I assume
someone else will at some point.  In the meantime it has been lower
priority.

> 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?

> 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])'.

> 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.

> 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.

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.

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.

> 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.

I installed your patch; thanks for testing it on Solaris 7.