Re: why i liked rc1.2's echo...

Re: why i liked rc1.2's echo...

[Scott Merrilees]

> [or ``why i'm not letting the great echo controversy just die'']

Or you could do something I first heard espoused by Robert Elz
(kre@munnari), that echo should just echo its arguments, kind of like
a permanent -n.

So to get -n behavoiur, do

	echo string

and to get normal echo behavoiur, use

	echo 'string
'

This has that advantage that it is extremely simple & consistant.

Sm

why i liked rc1.2's echo...

[haahr]

[or ``why i'm not letting the great echo controversy just die'']

i'm pushing Byron to leave echo as it was in rc-1.3beta and before, and  
he suggested bringing the issue up with the list because there were many  
opinions on what echo should do, with everyone arguing for completely  
different things.

here are the possibilities, as i see them for echo:
	(1) not builtin
	(2) v7 behavior (-n is recognized if first argument)
	(3) getopt (accepting only -n and the -- end of options sequence)
	(4) rc-1.2 and earlier behavior (-n and -- recognized if first)
one could also consider system v ism \ sequences but that seems way wrong  
to me, or the v8/v9/v10 -e flag to give system v behavior.

(1) has the advantage that it removes debates on the behavior of echo  
from this list, and let's everyone pick for themselves.  on the other  
hand, it makes rc scripts that ever invoke echo less portable, and the  
performance consquences are noticable.  (before people start shouting at  
me that i shouldn't be able to notice the difference between builtin echo  
and /bin/echo, my machine is rated ~12 specmarks, i'm almost always the  
only user logged in, and i can feel a difference between rc scripts that  
exec and those that don't, in a big way.)

moreover, i'd argue, and this is more controversial, that a builtin echo  
makes sense, because it is the complementary operation to backquoting.

(2) well, this has the advantage of history, and it's relatively easy to  
understand.  the problem with it is that there is no easy way to echo  
arbitrary text that might start with the word "-n"; you have to do  
something on the order of
	echo -n $^*^$nl
or
	echo -n $*; echo
neither of which is very pretty.

(3) normally i'm a getopt booster, but i find that adding getopt for echo  
is just plain unpleasant, because i do use echo without -- occaisonally  
and don't want to get annoying error messages along the way.  at one  
point when i was using the v8 shell on a system v machine i wrote my own  
v8/v9/v10 style echo and used getopt for it.  within a day or two  
(probably after the second time i wrote
	echo --- foo ---
or a relative) i threw out the getopt parsing and explicitly looked for  
option sequences.

i'm all for consistency, but echo with getopt seems like a hobgoblin for  
little minds to me.

(4) this is my favorite, for the simple reason that it solves the problem  
mentioned in (2) without much overhead.  for getopt fans, think of it as  
getopt that's lenient in accepting the end of options.  for v7 fans,  
think of it as one extra option, which says: quote the following string.

[alright, it's not really getopt, since normal getopt would imply that
	echo -n foo
	echo -n -- foo
	echo -n -n -n -n foo
would all be the same whereas rc-1.2 echo just looked at the first  
argument.]

-----

if we were starting all over again, and wanted to really invent something  
completely new, i'd just have two echo-like builtins
	echo $*		# behaves like echo -- $*
	echo-n $*	# behaves like echo -n $*
because i don't think echo should parse its arguments at all.  i really  
do think of echo as a primitive operation, at the same level as  
backquoting or variable assignment, and very few people would accept  
things like
	foo=(noexport a b c)
where assignment parsed its first argument.

on the other hand, even i wouldn't want to be that incompatible, i'd say  
(4) above is really pretty clean and gives the necessary functionality.

and, heck, even posix.2 doesn't specify getopt for echo.  what posix does  
say is
	``string	A string to be written to standard output.  If
			the first operand is "-n" or if any operands
			contain a backslash (\) character, the results
			are implementation defined.''
which is a major punt, but of the behaviors i've considered, only (2)  
would be acceptable.  they say "use printf(1)"

sorry if i've been long winded, but it seems a shame to me to change rc  
from doing THE right thing to anything else.  imho, of course.