From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from uucp-gw-1.pa.dec.com ([16.1.0.18]) by archone.tamu.edu with SMTP id <45339>; Thu, 13 Feb 1992 16:20:04 -0600 Received: by uucp-gw-1.pa.dec.com; id AA05130; Thu, 13 Feb 92 13:25:22 -0800 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1) id AA10381; Thu, 13 Feb 92 13:20:26 PST Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA06551; Thu, 13 Feb 92 13:20:23 PST Date: Thu, 13 Feb 1992 15:20:23 -0600 From: haahr@adobe.com Message-Id: <9202132120.AA06551@utopia.adobe.com> Received: by NeXT Mailer (1.63) To: rc mailing list Subject: why i liked rc1.2's echo... [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.