tvf@cci632.UUCP (Tom Frauenhofer) (04/09/90)
In article <12545@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >... deleted stuff relating to the imcompatability of System V versus >Berkeley echo >variants. Some time ago I proposed a transition plan, whereby the >Berkeley variant of "echo" would accept -e for System V-style escape >interpretation (as in 9th Ed. UNIX), the System V variant would accept >"-e" but do nothing new, System V shell scripts would be searched for >... some more arguments deleted I have a better idea - why not just build an echo that understands all the Berkeley and System V stuff? I don't like the idea of adding another switch to a widely used program that puts you into "System V mode" or some such. It becomes too tempting to do the same thing to all the other incompatible commands. -- Thomas V. Frauenhofer ...!rutgers!rochester!kodak!swamps!!frau!tvf *or* ...!uunet!atexnet!kodak!swamps!frau!tvf (tvf@frau, tvf@cci632) "What's a gourmand? I'll tell you, he's a P-I-G pig!" - Justin Wilson
martin@mwtech.UUCP (Martin Weitzel) (04/09/90)
In article <12545@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <4852@helios.TAMU.EDU> greg@eemips.tamu.edu (Greg Economides) writes: >>Has anyone noticed a strange problem using the 'echo -n' command in >>SunOS 4.0.2? Using the SystemV echo (/usr/5bin/echo) the -n switch >>(which causes NO newline to be output after the echoed text) doesn't >>work. If I give a command like: >>echo -n Hello world >>I get: >>-n Hello world <CR> > >That's exactly what you should get using System V "echo". > >This is one of those annoying gratuitous incompatibilities among UNIX >variants. [more deleted] I did wait some days to see if somebody else would mention ... now it seems to be my turn: Note also, that SysV Rel 3 introduces the -n option again to mean "no linefeed". The \c-convention lives on, the programmer has the choice. It seems, that AT&T just waited long enough to cause many programmers headaches how to convert existing scripts and to invent `portable' solutions, and - with the `XENIX compatibility' - the "-n"-option slipped back into SysV. BTW: Everyone who wants to read more about how to supress echo's newline should take a look to "The UNIX Programming Environment" by Kernighan&Pike, page 79 -- you'll find a nice little tale there .... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
davy@sparkyfs.istc.sri.com (David Curry) (04/10/90)
In article <35818@cci632.UUCP> tvf@cci632.UUCP (Tom Frauenhofer) writes: > >I have a better idea - why not just build an echo that understands all the >Berkeley and System V stuff? I don't like the idea of adding another switch >to a widely used program that puts you into "System V mode" or some such. >It becomes too tempting to do the same thing to all the other incompatible >commands. It's been done. See PD2:<UNIX-C.UTILS>ECHO.TAR-Z in the UNIX-SW archives on WSMR-SIMTEL20.ARMY.MIL (do the FTP in "tenex" mode, not "image" or "binary" mode). It's written by David MacKenzie <edf@rocky2.rockefeller.edu>. It's also in the comp.sources archives somewhere; check your copy of the index. Dave Curry UNIX-SW Moderator DCURRY@WSMR-SIMTEL20.ARMY.MIL
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/12/90)
In article <35818@cci632.UUCP> tvf@cci632.UUCP (Tom Frauenhofer) writes: >I have a better idea - why not just build an echo that understands all the >Berkeley and System V stuff? Because the behaviors are incompatible! How should echo 'foo\n' work? You get different answers from BSD and SysV variants of "echo".
tvf@cci632.UUCP (Tom Frauenhofer) (04/13/90)
In article <12561@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <35818@cci632.UUCP> tvf@cci632.UUCP (Tom Frauenhofer) writes: >>I have a better idea - why not just build an echo that understands all the >>Berkeley and System V stuff? > >Because the behaviors are incompatible! How should > echo 'foo\n' >work? You get different answers from BSD and SysV variants of "echo". I'll give you that point, but I still feel that a transition "echo" will add to the confusion. I'll refine my point - Why not just build an echo that supports as many of both the System V and Berkeley features as possible? Where there are conflicts (such as noted above), let's get some "Smart Group of People" (a UNIX standards committee? :-) ) choose one (going into real dangerous ground here: strikes me that the biggest pain with the two echos is the '-n' versus '\c' problem, and as other people have noted, echos have been implemented that support both). -- Thomas V. Frauenhofer ...!rutgers!rochester!kodak!swamps!!frau!tvf *or* ...!uunet!atexnet!kodak!swamps!frau!tvf (tvf@frau, tvf@cci632) "What's a gourmand? I'll tell you, he's a P-I-G pig!" - Justin Wilson
emv@math.lsa.umich.edu (Edward Vielmetti) (04/13/90)
why not improve echo? why bother? when I want to echo 'foo\n' I do printf "foo\n" and get exactly what I want. printf is Chris Torek's work, comp.sources.unix volume 9 I think. --Ed
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/02/90)
In article <14020094@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:
-> One would think that 1003.2 would get this
-> straightened out, but as a practical matter we need more than just a
-> final standard spec for "echo", we also need a viable transition plan.
-A viable transition plan has been decided and published in POSIX.2 Draft 9.
-Of course, the uses of echo that were always portable remain so:
- echo Hello world!
-However, in the POSIX environment, thou shalt not depend on non-portable
-behavior. Thou shalt not use "echo" with an -n option, and thou shalt
-not use any sequences such as "\c", "\n", or "\b" in its arguments. Use
-of either causes unspecified output.
-If thou requirest special processing beyond simply echoing printing
-characters followed by a newline, thou shalt use the "printf" utility:
- printf "Hi there!\n\nEnter your name: "
Well, that's dumb. Now I have to support TWO commands, where one would do.
What sort of standardization is this?peter@ficc.uu.net (Peter da Silva) (05/02/90)
Here's another solution to the problem. Put this in your scripts:
echo() {
cat << !
$*
!
}
Not too efficient, but guaranteed not to interpret backslash-cokebottle.
This is the way god intended echo to work.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com>
\_.--._/ Disclaimer: commercial solicitation by email to this address
v is acceptable.kre@cs.mu.oz.au (Robert Elz) (05/02/90)
In article <14020094@hpisod2.HP.COM>, decot@hpisod2.HP.COM (Dave Decot) writes: > Of course, the uses of echo that were always portable remain so: > echo Hello world! > echo "This is a variable value: $myvar" > echo "" The 1st and 3rd I agree with, the second one is not portable in general, it depends on the possible range of values for "$myvar". If you know that "myvar" is "yes" or "no", or "1", "2", ... then its fine, but if myvar is random user input, a filename (for myvar in *.c do ...) or anything else that isn't under total control of the script, then you can't rely on the second form. As best as I can tell, there's no easy way to reliably print the value of an unknown variable using the Sys V echo. Try myvar='\n' before the 2nd of the above with the V7 (BSD) and Sys V echos. kre
maart@cs.vu.nl (Maarten Litmaath) (05/03/90)
In article <12762@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: )In article <14020094@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: )-... )-If thou requirest special processing beyond simply echoing printing )-characters followed by a newline, thou shalt use the "printf" utility: )- printf "Hi there!\n\nEnter your name: " ) )Well, that's dumb. Now I have to support TWO commands, where one would do. )What sort of standardization is this? Followups to comp.unix.funny. -- Antique fairy tale: Little Red Riding Hood. |Maarten Litmaath @ VU Amsterdam: Modern fairy tale: Oswald shot Kennedy. |maart@cs.vu.nl, uunet!cs.vu.nl!maart
maart@cs.vu.nl (Maarten Litmaath) (05/03/90)
In article <-863CBCxds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: )Here's another solution to the problem. Put this in your scripts: ) )echo() { )cat << ! )$* )! )} echo() { expr "xxx$*" : 'xxx\(.*\)' } -- Antique fairy tale: Little Red Riding Hood. |Maarten Litmaath @ VU Amsterdam: Modern fairy tale: Oswald shot Kennedy. |maart@cs.vu.nl, uunet!cs.vu.nl!maart
idall@augean.OZ (Ian Dall) (05/03/90)
In article <12762@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <14020094@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >-If thou requirest special processing beyond simply echoing printing >-characters followed by a newline, thou shalt use the "printf" utility: >- printf "Hi there!\n\nEnter your name: " > >Well, that's dumb. Now I have to support TWO commands, where one would do. >What sort of standardization is this? Hmm. Well it might be dumb that we got into the two echo mess, but how else would we get out? If *I* was writing the standard, I would define echo to do exactly that with *no* interpretation of options or escape sequences. If you want a new line do echo "foo bar$NL" where NL is defined appropriatly, and let the shell put it in for you. I actually keep a little program like that around (I call it echo_args) which I find very useful for debugging programs which exec other programs. If that were the case, printf would still be required. The problem is that there is know way of changing echo's default behaviour without breaking it: echo -c foo should output -c foo and echo foo\c should output foo\c
levy@cbnewsc.ATT.COM (Daniel R. Levy) (05/04/90)
In article <3851@munnari.oz.au>, kre@cs.mu.oz.au (Robert Elz) writes: > > echo "This is a variable value: $myvar" > As best as I can tell, there's no easy way to reliably print the value > of an unknown variable using the Sys V echo. > > Try > > myvar='\n' > before the 2nd of the above with the V7 (BSD) and Sys V echos. True. There IS a portable-but-ugly way to implement a non-interpreting echo under sh (csh too?): cat << ! This is a variable value: $myvar ! In the example given, this would print This is a variable value: \n under both System V and BSD. -- Daniel R. Levy >>> God: just say "yes" <<< AT&T Bell Laboratories UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!levy 1000 East Warrenville Rd. Any opinions expressed in the message above are Naperville, Illinois 60566 mine, and not necessarily AT&T's.