Hi Noah, Peter, others, * Noah Misch wrote on Thu, Mar 24, 2005 at 04:04:51AM CET: > On Sun, Mar 20, 2005 at 08:18:48AM +0100, Ralf Wildenhues wrote: > > > Ralf Wildenhues wrote: > > > > This is not ok: $ECHO may only take one argument, so you must > > What systems have that problem? What do they do with the latter arguments? > > > > > double-quote. Furthermore, the argument may not start with a hyphen > > > > in general, for it might be misinterpreted as option to the $ECHO > > > > command. The solution is to use the slower > > > > $ECHO "X$what $ever" | $Xsed > > > > > > I see this bug is in several places here. :-/ > > Do there exist `echo' commands that interpret something other than `-n', `-e', > `-E', `--version', or `--help' as options? If it is only specific leading > arguments that cause trouble and not arbitrary `-STRING', we need not use > $Xsed > in too many places.
Well, this is kind of Libtool-specific, as we use one of echo print -r printf %s\n $CONFIG_SHELL $0 --fallback-echo for $ECHO, and the third one at least does the wrong thing with more than one argument, and the first and second mind leading dashes. Unfortunately, ksh's `print -r' complains about options it doesn't know (tested with pdksh), unlike all echos I know: $ print -r -lfoo ksh: print: -l: unknown option When going through these, I would like to replace most of the bad cases with either echo ... # when totally safe (i.e., no backslash either), or $ECHO ".." # when no leading hyphen, or $ECHO "X.." | $Xsed # if all else fails The problem with the first is that if we ever decide to allow library or object names containing a backslash, we'd need to go through the list again.. Of course, I'd take a well-formed patch as well. :-) Thinking out loud: one _could_ add 'echo -e' as a candidate. The problem with changing the initialization code is that it is quite fragile, and tends to break on just the platform you did not test it on. Regards, Ralf
