Ralf Wildenhues <[EMAIL PROTECTED]> 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.
