ka@june.cs.washington.edu (Kenneth Almquist) (11/30/88)
I've been implementing a public domain shell and I'm wondering what to
do about the echo builtin. The System V echo command interprets a number
of escape sequences (e.g. \n for newline) which the BSD echo does not,
so I can...
1. Implement the System V echo on the grounds that it will make it easier
to run System V shell scripts.
2. Implement the BSD echo on the grounds that it's the "right" approach
(since the System V echo is useless if you want to echo an arbitrary
string unchanged).
3. Don't provide an echo builtin, so users get whatever echo command is
installed in /bin. This follows the principle of least surprise, but
it makes shell scripts run slowly and does nothing for portability.
Any suggestions? In particular I would like to know if any standards
organizations have addressed the semantics of echo. Does anyone know
what the merged AT&T/SUN UNIX is going to do about echo?
Kenneth Almquistlogan@vsedev.VSE.COM (James Logan III) (12/01/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes:
# I've been implementing a public domain shell and I'm wondering what to
# do about the echo builtin. The System V echo command interprets a number
# of escape sequences (e.g. \n for newline) which the BSD echo does not,
# so I can...
#
# 3. Don't provide an echo builtin, so users get whatever echo command is
# installed in /bin. This follows the principle of least surprise, but
# it makes shell scripts run slowly and does nothing for portability.
#
You should write a shell-script that is called by your makefile
to test the echo in /bin and see which version is already
installed.
When you know which one is installed, just set an environment
variable, like ECHOTYPE, to either "BSD_ECHO" or "SYSV_ECHO" and
call "make echo.o". (Make calls the script "makemyshell4me"
which calls "make echo.o" and returns to the first make. Get it? :-)
In the makefile, just do something like this:
# Uncomment ECHOTYPE and set it to BSD_ECHO or SYSV_ECHO
# below to override the automatic configuration in the
# "makemyshell4me" shell script.
# ECHOTYPE =
all: echo myshell
echo: echo.c
./makemyshell4me
echo.o:
cc $(CCFLAGS) -D $(ECHOTYPE) echo.c
myshell: echo.o other_modules.o
cc $(LDFLAGS) echo.o other_modules.o
This way the person who compiles your shell can either just type
"make" and let your program automatically configure itself to use
the echo like the one in that person's /bin, or he can explicitly
specify the other version in the makefile by setting "ECHOTYPE"
appropriately.
-Jim
--
Jim Logan logan@vsedev.vse.com
(703) 892-0002 uucp: ..!uunet!vsedev!logan
inet: logan%vsedev.vse.com@uunet.uu.netgwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >Any suggestions? In particular I would like to know if any standards >organizations have addressed the semantics of echo. Does anyone know >what the merged AT&T/SUN UNIX is going to do about echo? I don't know what SVR4.0 plans to do about it, but I know what I recommended some time ago in this newsgroup, as implemented in our System V emulation on 4BSD systems: echo -e stuff # interprets \-escapes in "stuff" echo -n stuff # omits the trailing newline echo stuff # your choice of System V or 7th Edition behavior The idea is to transition to an eventual version of "echo" that follows the 9th Edition rules. But first we have to get everybody's version to handle the -e option so all those System V shell scripts can be edited to use it instead of assuming that \ interpretation is on by default. Once everyone has had a chance to use -e when they want \ interpretation, then "echo" can be changed so that echo stuff # 7th Edition behavior I am REALLY pissed off at whoever it was in AT&T that decided to change the existing behavior of a utility as important as "echo"! They should have introduced the -e option in the first place.
henry@utzoo.uucp (Henry Spencer) (12/02/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >I've been implementing a public domain shell and I'm wondering what to >do about the echo builtin. The System V echo command interprets a number >of escape sequences (e.g. \n for newline) which the BSD echo does not... Arguably the best approach is that taken by the V8 echo, in which the escape are interpreted only if the -e option is given. No matter what you do, you'll have compatibility problems with at least part of your user community, so the best thing to do is to accept compatibility problems with all of them and *fix* the problem. We did. (We run a variant of the V8/V9 shell which has echo builtin.) >1. Implement the System V echo on the grounds that it will make it easier > to run System V shell scripts. Having the escapes available actually turns out to be surprisingly handy, or at least that's been our experience. >2. Implement the BSD echo on the grounds that it's the "right" approach > (since the System V echo is useless if you want to echo an arbitrary > string unchanged). Actually you can't echo an *arbitrary* string with any of the current echos, since strings like "-n" tend to have surprising effects even in otherwise-innocuous versions, but that's a lesser problem. >3. Don't provide an echo builtin, so users get whatever echo command is > installed in /bin. This follows the principle of least surprise, but > it makes shell scripts run slowly and does nothing for portability. The original V8 shell actually did this. We put echo back into ours because the performance impact just wasn't acceptable. With a fast echo, the shell makes a superb programming language for applications work. Without, forget it. The pragmatic issues outweigh the cleanliness ones for us on this one. Mind you, you need to put some non-trivial effort into making the semantics match those of a separate command *exactly*. >Any suggestions? In particular I would like to know if any standards >organizations have addressed the semantics of echo. Does anyone know >what the merged AT&T/SUN UNIX is going to do about echo? They will presumably go with the SVID approach, although I could be wrong. The standard to watch is the POSIX command-level bunch, 1003.2. I don't know what they've done about echo in particular. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
vsh@etnibsd.UUCP (Steve Harris) (12/02/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >I've been implementing a public domain shell and I'm wondering what to >do about the echo builtin. The System V echo command interprets a number >of escape sequences (e.g. \n for newline) which the BSD echo does not, FYI -- SunOS 3.x has done this brain damaged thing of looking to see which is first in your PATH variable: /usr/ucb or /usr/5bin. The builtin echo (and, I believe, /bin/echo) will operate in either BSD or ATT mode depending on which directory comes first. The problem is, what if I want /usr/ucb before /usr/5bin in my PATH, but also want my echo to recoginze sysV escapes? I have to do, e.g.: OPATH=$PATH $PATH=/usr/5bin:$PATH echo "\tthis is a test\n" PATH=$OPATH Sun had the right idea, but poor implementation. Make your echo work either way, but settible according to the value of some environment variable (e.g., ECHO=BSD vs. ECHO=ATT). As for choice of default, I don't know. Perhaps there should be a system-wide defaults file (e.g., /etc/defaults) where things like this could be specified. Otherwise, those of us without source are out in the code (oops, cold :-), and those with source will have to recompile. -- Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh
avr@mtgzz.att.com (a.v.reed) (12/02/88)
In article <6557@june.cs.washington.edu>, ka@june.cs.washington.edu (Kenneth Almquist) writes:
< I've been implementing a public domain shell and I'm wondering what to
< do about the echo builtin. The System V echo command interprets a number
< of escape sequences (e.g. \n for newline) which the BSD echo does not,
< so I can...
<
< 1. Implement the System V echo on the grounds that it will make it easier
< to run System V shell scripts.
<
< 2. Implement the BSD echo on the grounds that it's the "right" approach
< (since the System V echo is useless if you want to echo an arbitrary
< string unchanged).
<
< 3. Don't provide an echo builtin, so users get whatever echo command is
< installed in /bin. This follows the principle of least surprise, but
< it makes shell scripts run slowly and does nothing for portability.
<
< Any suggestions? In particular I would like to know if any standards
< organizations have addressed the semantics of echo. Does anyone know
< what the merged AT&T/SUN UNIX is going to do about echo?
< Kenneth Almquist
Dave Korn's approach was to do a new builtin, print, with options to
emulate either "echo". "Echo" is initially aliased to work like the local
/bin/echo, whichever one that happens to be, but with the user having
the option to change it to his/her preference. I recommend Bolsky and
Korn's "KORNSHELL" book for details.
Adam Reed (avr@mtgzz.att.com)chris@mimsy.UUCP (Chris Torek) (12/02/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >... The System V echo command interprets a number of escape sequences >(e.g. \n for newline) which the BSD echo does not, so I can... [various approaches deleted] >Any suggestions? Have echo work as in BSD; use printf(1) to produce escapes. I tried to post printf to comp.sources.unix, but it seems it never made it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ok@quintus.uucp (Richard A. O'Keefe) (12/03/88)
In article <1988Dec1.214552.18211@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: [about "echo"] >Having the escapes available actually turns out to be surprisingly handy, >or at least that's been our experience. >Actually you can't echo an *arbitrary* string with any of the current >echos, since strings like "-n" tend to have surprising effects even in >otherwise-innocuous versions, but that's a lesser problem. These are some of the reasons why I wrote "lit" and posted it to the net. lit [-n] [-d{clist}] [-e{char}] arg ... (The -dxyz stuff lets you specify something other than blanks between the arguments, e.g. "lit -d: foo baz ugh" => "foo:baz:ugh".) And of course it supports "--" as end-of-options, so "lit -- -n" works. Not the least of the reasons for the -e option is that when you are going through several layers of string interpretation (e.g. the shell script is written by a C program) it is just too painful when all of the layers use the same escape character.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (12/03/88)
In article <1264@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes: | You should write a shell-script that is called by your makefile | to test the echo in /bin and see which version is already | installed. ksh seems to check for the first echo on the PATH rather than the one in /bin. On SunOS if you are running a SysV interface the echo builtin works like SysV, while in the BSD mode it looks like V7. That seems like a better way to me, although using an environment variable would be acceptable. Not all users on a given machine want the same behavior. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
guy@auspex.UUCP (Guy Harris) (12/04/88)
>The builtin echo (and, I believe, /bin/echo) will operate in either BSD or >ATT mode depending on which directory comes first. No, "/bin/echo" doesn't look at PATH. The model used was that "echo" was a builtin solely for performance reasons, so the system should act "as if" it were searching PATH for it. If it were not built in, "echo" would operate in either V7 or S5 mode (there is no "ATT mode"; there have been releases from AT&T that exhibit each of the behaviors - BSD's "echo" just happens to be derived from the V7 one, not the PWB/S3/S5 one), because it would refer to "/bin/echo" if "/bin" were first in your path and "/usr/5bin/echo" if "/usr/5bin" were first in your path. (The idea was suggested by a comment by Dave Korn, who put something similar into the Korn shell.) >The problem is, what if I want /usr/ucb before /usr/5bin in my PATH, >but also want my echo to recoginze sysV escapes? I have to do, e.g.: The same would apply if "echo" weren't built in; you'd have to fix it by explicitly doing /usr/5bin/echo "\tthis is a test\n" >Sun had the right idea, but poor implementation. Make your echo work >either way, but settible according to the value of some environment >variable (e.g., ECHO=BSD vs. ECHO=ATT). The same could apply to other non-built-in commands that behave differently in different environments. If you want some particular behavior for compatibility reasons, setting PATH is the answer. If you want some particular behavior for *functionality* reasons, this suggests that the command in your preferred environment should either have the additional functionality added to it, if that doesn't break compatibility, or that a new command be provided in that environment if augmenting the existing command breaks compatibility. Unfortunately, modifying "echo" would break compatibility. The approach taken by Dave Korn, namely adding a "print" command that provides additional functionality, would be the ideal in this case. (Chris Torek's idea of a "printf" command is another example of that approach.)
gwc@root.co.uk (Geoff Clare) (12/05/88)
In article <14799@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >Have echo work as in BSD; use printf(1) to produce escapes. I tried >to post printf to comp.sources.unix, but it seems it never made it. - but then you lose the advantage of echo being a shell builtin. This will have a very noticable effect on speed for scripts which print a lot of escapes. Personally, I think fewest existing scripts would break if the SysV behaviour were adopted, but with the '-n' option added. There can't be that many BSD scripts which contain '\' in an echo string, whereas use of '\c' in SysV scripts is extremely common. X/Open specifies SysV behaviour for echo. What does POSIX say? -- Geoff Clare UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH gwc@root.co.uk ...!mcvax!ukc!root44!gwc +44-1-606-7799 FAX: +44-1-726-2750
tim@attdso.att.com (Tim J Ihde) (12/06/88)
In article <14799@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu >(Kenneth Almquist) writes: >>... The System V echo command interprets a number of escape sequences >>(e.g. \n for newline) which the BSD echo does not, so I can... >>Any suggestions? > >Have echo work as in BSD; use printf(1) to produce escapes. I tried >to post printf to comp.sources.unix, but it seems it never made it. Printf(1) made it this far; I've been using it for a while now. _Very_ handy to have around (imagine! the same formating statements work in more than command - more than one language even!) I can mail the shar file to anyone who needs it. tim -- Tim J Ihde UUCP: att!attdso!tim (201) 898-6687 INTERNET: tim@attdso.att.com "Blimey - this redistribution of wealth is more complicated than I'd thought!" - Dennis Moore and various Presidents
friedl@vsi.COM (Stephen J. Friedl) (12/06/88)
In article <4712@mtgzz.att.com>, avr@mtgzz.att.com (a.v.reed) writes: > [...] Dave Korn's approach was to do a new builtin, print, with > options to emulate either "echo". How many people had to rename their `print' programs when they got ksh? Why in the world was such a commonly-used command name taken by ksh? Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on my new '89 Mustang GT Convertible: "Just say WOW!"
domo@riddle.UUCP (Dominic Dunlop) (12/06/88)
In article <6557@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >I've been implementing a public domain shell and I'm wondering what to >do about the echo builtin... > >Any suggestions? In particular I would like to know if any standards >organizations have addressed the semantics of echo. Does anyone know >what the merged AT&T/SUN UNIX is going to do about echo? Nobody in the large traffic I've seen seems to have given an explicit answer, so I'll quote from the _UNIX System V Release 4.0 Migration Reference Guide, UNIX System V_ distributed at the recent developer conferences. It's a preliminary document, and doesn't have an AT&T select code, which means you'll almost certainly be out of luck if you try to order yourself a copy. But, if you want to try, AT&T's numbers are (800) 432-6600 (USA), (800) 255-1242 (Canada) and (317) 352-8557 (elsewhere). You may at least learn when the final version will be published. Corresponding migration guides for BSD, Sun OS, and Xenix were also distributed at the conferences. Anyway echo(1) In release 4.0, the echo command has been enhanced to support both the SunOS and UNIX System V version of the command. echo automatically selects between the two definitions according to the value of the PATH variable. The UNIX System V definition is the default definition. However, if the PATH contains the entry /usr/ucb, and that entry comes before /usr/bin, then the SunOS version of echo is selected. This enhancement was made to support the transition of BSD applications, and may be withdrawn in UNIX System V releases beyond 4.0. So now you know. -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
egisin@mks.UUCP (Eric Gisin) (12/08/88)
In article <656@root44.co.uk>, gwc@root.co.uk (Geoff Clare) writes: > Personally, I think fewest existing scripts would break if the SysV > behaviour were adopted, but with the '-n' option added. There can't > be that many BSD scripts which contain '\' in an echo string, whereas > use of '\c' in SysV scripts is extremely common. The System V behaviour will break things like echo "$1" when the variable contains a '\'. > > X/Open specifies SysV behaviour for echo. What does POSIX say? System V with no enhancments (Draft 7). There are already some enhancements from ksh in P1003.2 (job control, aliases, expressions, new test, fixed function execution), I think a fix for echo is more important.
ka@june.cs.washington.edu (Kenneth Almquist) (12/08/88)
> How many people had to rename their `print' programs when > they got ksh? Why in the world was such a commonly-used > command name taken by ksh? > Steve The name `test' hasn't worked out so well either. The basic problem is that the set of valid command names in UNIX is a flat name space which lots of people change without much in the way of central coordination. The problem seems to be worse with shell builtins, though, because the shell builtins are checked for before PATH is searched. I've been thinking of adding a `rename' command to allow shell builtins to be moved around. This would allow people to say `rename test sdlkjfsdlfk' in their .profile files to get rid of the test command in their login shells, but test would still be around in subshells. Another possibility is to allow the PATH variable to include an entry for shell builtins. Then a user's private bin directory could appear in PATH before the shell builtins... Kenneth Almquist P.S. Thanks to everyone who responded to my question about echo.
merlyn@intelob.biin.com (Randal L. Schwartz @ Stonehenge) (12/08/88)
In article <6646@june.cs.washington.edu>, ka@june (Kenneth Almquist) writes: | I've been thinking | of adding a `rename' command to allow shell builtins to be moved around. | This would allow people to say `rename test sdlkjfsdlfk' in their .profile | files to get rid of the test command in their login shells, but test would | still be around in subshells. Arrggh. But then what about my 'rename' shell script? :-) :-) :-) I think you should call your command 'xyzzy'. Or 'plugh'. Or '*'. Come to think of it, I had a shell script named '*' once. Nevermind. :-) -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA. <merlyn@intelob.biin.com> or ...!tektronix!inteloa[!intelob]!merlyn SOME MAILERS REQUIRE <merlyn@intelob.intel.com> GRRRRR! Standard disclaimer: I *am* my employer!
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/09/88)
In article <6646@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >The problem seems to be worse with shell builtins, though, because the >shell builtins are checked for before PATH is searched. I've been thinking >of adding a `rename' command to allow shell builtins to be moved around. I don't think "rename" is a wise idea, because of its interaction with definitions used in shell functions. The BRL version of the SVR2 shell (unlike the original SVR2 shell) allows shell function names to override builtin names. We also added the 9th Edition UNIX "builtin" builtin to provide a way to access the builtin name instead of a possible function name. This allows, for example, the user to define a "cd" function that does other things (like updating PS1) along with using the "builtin cd" command to do the real chdir. Presumably you could define "test" to be "./test" if you have problems with "test" being built-in. (Functions would normally be written to use "[ ... ]" instead of "test ...".)
domo@riddle.UUCP (Dominic Dunlop) (12/09/88)
In article <656@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes: >X/Open specifies SysV behaviour for echo. What does POSIX say? Draft 7 of IEEE 1003.2, ``Shell and Application Utility Interface'', specifies System V-style behaviour only for the echo command. A note in the rationale (all rationale wil be omited from the final standard) points out that the BSD version of echo does not conform to the proposed definition. No unresolved objections to the definition are listed. -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/10/88)
In article <949@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes: > In release 4.0, the echo command has been enhanced to support both the > SunOS and UNIX System V version of the command. echo automatically > selects between the two definitions according to the value of the PATH > variable. The UNIX System V definition is the default definition. > However, if the PATH contains the entry /usr/ucb, and that entry comes > before /usr/bin, then the SunOS version of echo is selected. What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin even on native BSD systems. I wouldn't risk that in shell scripts, either, so in effect they have added a mechanism that will be of no practical use. And, there is STILL no way to disable \-escape mapping in the System V environment.
brian@ucsd.EDU (Brian Kantor) (12/10/88)
GNUecho(1) UNIX Programmer's Manual GNUecho(1)
NAME
echo - echo arguments
SYNOPSIS
echo [ options ] ...
DESCRIPTION
Echo writes its arguments separated by blanks and terminated
by a newline on the standard output. Options to filter and
redirect the output are as follows:
-2 generate rhyming couplets from keywords
-3 generate Haiku verse from keywords
-5 generate limerick from keywords
-a convert ASCII to ASCII
-A disambiguate sentence structure
-b generate bureaucratese equivalent (see -x)
-B issue equivalent C code with bugs fixed
-c simplify/calculate arithmetic expression(s)
-C remove copyright notice(s)
-d define new echo switch map
-D delete all ownership information from system files
-e evaluate lisp expression(s)
-E convert ASCII to Navajo
-f read input from file
-F transliterate to french
-g generate pseudo-revolutionary marxist catch-phrases
-G prepend GNU manifesto
-h halt system (reboot suppressed on Suns, Apollos, and
VAXen, not supported on NOS-2)
-i emulate IBM OS/VU (recursive universes not supported)
-I emulate IBM VTOS 3.7.6 (chronosynclastic infundibulae
supported with restrictions documented in IBM VTOS
Printed 10/28/85 18 January 1983 1
GNUecho(1) UNIX Programmer's Manual GNUecho(1)
Reference Manual rev 3.2.6)
-J generate junk mail
-j justify text (see -b option)
-k output "echo" software tools
-K delete privileged accounts
-l generate legalese equivalent
-L load echo modules
-M generate mail
-N send output to all reachable networks (usable with -J,
-K, -h options)
-n do not add newline to the output
-o generate obscene text
-O clean up dirty language
-p decrypt and print /etc/passwd
-P port echo to all reachable networks
-P1 oolcay itay
-q query standard input for arguments
-r read alternate ".echo" file on start up
-R change root password to "RMS"
-s suspend operating system during output (Sun and VAX BSD
4.2 only)
-S translate to swahili
-T emulate TCP/IP handler
-t issue troff output
-u issue unix philosophy essay
-v generate reverberating echo
-V print debugging information
Printed 10/28/85 18 January 1983 2
GNUecho(1) UNIX Programmer's Manual GNUecho(1)
-x decrypt DES format messages (NSA secret algorithm CX
3.8, not distributed outside continental US)
Echo is useful for producing diagnostics in shell programs
and for writing constant data on pipes. To send diagnostics
to the standard error file, do `echo ... 1>&2'.
AUTHOR
Richard M. Stallman (maybe)
Printed 10/28/85 18 January 1983 3
/* Written 12:22 pm Oct 28, 1985 by umn-cs!herndon in umn-cs:net.jokes */david@sun.uucp (David DiGiacomo) (12/10/88)
In article <9128@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin >even on native BSD systems. Gee, everyone I know puts /usr/ucb ahead of /usr/bin (formerly /bin), if for no other reason than to pick up UCB mail/Mail/mailx instead of binmail. Wasn't there a /bin/grep vs. /usr/ucb/grep conflict too?
guy@auspex.UUCP (Guy Harris) (12/11/88)
> In release 4.0, the echo command has been enhanced to support both the > SunOS and UNIX System V version of the command. "SunOS version"? Geez. It's just the BSD version, or really just the V7 version. I guess some document-writer wasn't told the truth, or wasn't told anything and tried filling in the gaps by interpolation.
guy@auspex.UUCP (Guy Harris) (12/11/88)
>What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin >even on native BSD systems. They don't have to; the default PATH on BSD systems is ":/usr/ucb:/bin:/usr/bin". >I wouldn't risk that in shell scripts, either, so in effect they have >added a mechanism that will be of no practical use. Shell scripts generally want to set PATH right after they've set IFS (unless your shell doesn't import IFS); I generally do so in my scripts these days. If you're in an environment - such as, say, the BRL System V emulation, which you may be familiar with :-) - where "/usr/bin" and/or "/bin" may contain a BSD-style version of a command, and "/usr/5bin" may contain an S5-style version, your script should set the path appropriately for the version it expects. I don't know whether BSD-style versions of commands such as "tr" will be supplied in "/usr/ucb" in S5R4.0, or if this'll be left up to licensees to do, but at least on systems that do that (as I suspect the S5R4-based SunOS will), the rules will be "put '/usr/ucb' at the front if you expect BSD-style versions, and put it at the end or leave it out if you don't. "echo" is treated just like non-built-in commands in that sense (thanks and a tip of the Hatlo hat to Dave Korn for the idea); if the shell would have found the BSD-style version were it not built in, it makes it act like the BSD-style version, and if it would have found the S5-style version were it not built in, it makes it act like the S5-style version. The mechanism *is* of practical use if you want a script written for a particular environment (V7/BSD or S5) to run properly when run from both environments - just set PATH. >And, there is STILL no way to disable \-escape mapping >in the System V environment. The mechanism isn't of practical use for that purpose, but it wasn't meant to be. That problem needs to be addressed independently of the problem of making already-written shell scripts work.
meissner@xyzzy.UUCP (Usenet Administration) (12/11/88)
In article <960@etnibsd.UUCP> vsh@etnibsd.UUCP (Steve Harris) writes: | FYI -- SunOS 3.x has done this brain damaged thing of looking to see | which is first in your PATH variable: /usr/ucb or /usr/5bin. The | builtin echo (and, I believe, /bin/echo) will operate in either BSD or | ATT mode depending on which directory comes first. | | The problem is, what if I want /usr/ucb before /usr/5bin in my PATH, | but also want my echo to recoginze sysV escapes? I have to do, e.g.: | | OPATH=$PATH | $PATH=/usr/5bin:$PATH | echo "\tthis is a test\n" | PATH=$OPATH While in general, I prefer not to hard code paths, in this case pragmatism wins out. On scripts where you need System V escape semantics (like scripts that send control sequences to the terminal or windowing system), just hard code the path. If the script is only going to be run on Suns, just use /usr/5bin/echo directly, and don't futz around with the PATH. If your script(s) need to be run on multiple systems, you could set an environment variable, like I do (in /bin/sh notation): if [ -x /bin/sun3 ] && /bin/sun3; then SYSVECHO=/usr/5bin/echo else SYSVECHO=echo fi # ... ${SYSVECHO} ... -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <675@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: [I previously commented:] > >What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin > >even on native BSD systems. > They don't have to; the default PATH on BSD systems is > ":/usr/ucb:/bin:/usr/bin". But this is so well-known to be idiotic that everyone I know of sets his own PATH in his .profile. In fact since our .profiles are used on a wide variety of UNIX implementations, they generally include code like this: NPATH= for d in /usr/5bin /vld/bin $HOME/bin /bin /usr/bin /usr/sccs /.bin \ /usr/.bin /usr/ucb /usr/bsd /etc /usr/etc /usr/mdqs/bin /usr/brl/bin \ /usr/brlcad/bin /usr/brl/sbin /usr/local/bin /usr/local/eroff/bin /usr/lbin do if [ $d = /usr/local/bin -a ! -d $d ] then d=/usr/local fi if [ -d $d ] then NPATH=$NPATH$d: fi done if [ "$NPATH" ] then PATH=$NPATH. export PATH else echo '.profile: reverting to default $PATH' >&2 fi unset NPATH Even in a pure 4BSD environment, you will notice, I don't put /usr/ucb ahead of /bin and /usr/bin. There are several reasons for this, but the main ones are improved average search speed (since very few useful utilities are in /usr/ucb) and standard environment (since /usr/ucb/grep etc. are usually brain-damaged). > Shell scripts generally want to set PATH right after they've set IFS > (unless your shell doesn't import IFS); I generally do so in my scripts > these days. Yes, and even 4BSD shell scripts normally include something like PATH=/bin:/usr/bin:/usr/ucb export PATH (Again, getting the wrong version of "echo" under SVR4.0.) > ... the rules will be "put '/usr/ucb' at the front if you expect > BSD-style versions, and put it at the end or leave it out if you don't. Unfortunately this reversal of the /usr/5bin approach doesn't work right. There should have been a separate /usr/bsdbin or such to contain the BSD compatibility versions of utilities; /usr/ucb is already in use WITH A DIFFERENT MEANING. > "echo" is treated just like non-built-in commands in that sense (thanks > and a tip of the Hatlo hat to Dave Korn for the idea); if the shell > would have found the BSD-style version were it not built in, it makes it > act like the BSD-style version, and if it would have found the S5-style > version were it not built in, it makes it act like the S5-style version. But as you can see, the problem with this approach is that it encourages further delay in FIXING the broken System V "echo" behavior. The BRL Bourne shell can be configured to default either way, but in either configuration it supports the 9th Edition UNIX -e and -n options. (There is no opposite of -e, although probably System V could use one today.) This provides a transitional aid for people to fix the System V scripts to use -e when they really intend for \-escapes to be interpreted. However, this transition will not occur until implementors start cooperating. Instead of working to fix design errors via transition to better designs, vendors seem to be accreting all the misfeatures ever used by anybody..
erik@mpx2.UUCP (Erik Murrey) (12/12/88)
In article <2258@xyzzy.UUCP> meissner@xyzzy.UUCP (Michael Meissner) writes: > [ ... ] >like I do (in /bin/sh notation): > > if [ -x /bin/sun3 ] && /bin/sun3; then > SYSVECHO=/usr/5bin/echo > else > SYSVECHO=echo > fi > > # ... > > ${SYSVECHO} ... While this does work, it is *very* ugly. Try plowing through big shell scripts that use ${NAME-OF-PROGRAM-TO-RUN}'s all over the place. They may be more secure, but at the cost of maintainability. Setting the PATH & IFS at the top of each shell script fixes most security holes. Personally, I like the echo that I have here (and a similar one was posted to comp.sources.misc) that can understand both the BSD flags, and the Sys-V escapes. Maybe SysV.4 should have a "raw" echo for those times when you just want the actual arguments, un-retouched, sent to stdout. -- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx2.UUCP / / / / /| Data Systems, Inc. {spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================
david@sun.uucp (David DiGiacomo) (12/12/88)
In article <2258@xyzzy.UUCP> meissner@xyzzy.UUCP (Michael Meissner) writes: >While in general, I prefer not to hard code paths, in this case pragmatism >wins out. On scripts where you need System V escape semantics (like scripts >that send control sequences to the terminal or windowing system), just hard >code the path. If the script is only going to be run on Suns, just use >/usr/5bin/echo directly, and don't futz around with the PATH. Unfortunately, /usr/5bin/echo is part of the optional System V software category which very few Sun users install. You have to do the path switching trick or perhaps give up and use echo | tr. -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
sjs@jcricket.ctt.bellcore.com (Stan Switzer) (12/13/88)
Regardless of whether you prefer "echo -n" or "echo \c" sometimes you have to write a shell script that will prompt users correctly regardless of how echo works. I have been using the following trick for a while now, and I figured other people might find it useful: #!/bin/sh P1= P2= if test "`echo -n a; echo b`" = "ab" then P1="-n" # BSD style else P2="\c" # Sys V style fi echo $P1 "A prompt string: "$P2 read RESPONSE Possibly I picked this trick up from Larry Wall's "rn" configure script. Stan Switzer sjs@ctt.bellcore.com
guy@auspex.UUCP (Guy Harris) (12/13/88)
>On scripts where you need System V escape semantics (like scripts that >send control sequences to the terminal or windowing system), Note that unless the control sequence is very specific to the terminal, such that it doesn't appear in the "terminfo" database, if you have "tput" you're better off using it to send control sequences to the terminal, since it uses "terminfo" and thus can be terminal-independent. (There may already exists versions of "tput"-like commands for "termcap".) >If the script is only going to be run on Suns, just use /usr/5bin/echo >directly, and don't futz around with the PATH. If your script(s) need >to be run on multiple systems, you could set an environment variable, >like I do (in /bin/sh notation): If your script depends on System V semantics, as opposed to (V7/)BSD semantics, for other commands, futzing around with the PATH may well be the best approach.
guy@auspex.UUCP (Guy Harris) (12/13/88)
>But this is so well-known to be idiotic that everyone I know of sets his >own PATH in his .profile. Some people do so by prepending or appending to their $PATH, in which case they'd get "/usr/ucb" first on a BSD system. I set mine up explicitly, but I still stick "/usr/ucb" in front of "/bin" and "/usr/bin". >Even in a pure 4BSD environment, you will notice, I don't put /usr/ucb >ahead of /bin and /usr/bin. There are several reasons for this, but the >main ones are ... and standard environment (since /usr/ucb/grep etc. are >usually brain-damaged). Well, it appears the problem here is that in a S5/BSD environment, some BSD commands may be brain-damaged and some S5 commands may be brain-damaged (namely, "echo"). That's unfortunate, but that's life. >Yes, and even 4BSD shell scripts normally include something like > PATH=/bin:/usr/bin:/usr/ucb export PATH >(Again, getting the wrong version of "echo" under SVR4.0.) And the wrong version of "tr", and the wrong version of.... If there's a problem, it's not a problem with "echo" alone. >> ... the rules will be "put '/usr/ucb' at the front if you expect >> BSD-style versions, and put it at the end or leave it out if you don't. > >Unfortunately this reversal of the /usr/5bin approach doesn't work >right. There should have been a separate /usr/bsdbin or such to >contain the BSD compatibility versions of utilities; /usr/ucb is >already in use WITH A DIFFERENT MEANING. Perhaps. Given items such as "/usr/ucb/grep" (and "/usr/ucb/mail"), "/usr/ucb" has, at least in part, the meaning "place where Berkeley-modified variants of UNIX utilities live". It no longer has the meaning "place where Berkeley-written utilities live", since some of them don't live there - "csh" being one example.... It's not clear *WHAT* the meaning of "/usr/ucb" is. >But as you can see, the problem with this approach is that it encourages >further delay in FIXING the broken System V "echo" behavior. The primary goal of the SunOS S5 environment was to enable people to import programs and programmers from an S5 environment. Sorry, but getting "echo" fixed would, at best, have been a secondary goal. >Instead of working to fix design errors via transition to better designs, The first problem is convincing vendors that there is a design error. *I* agree that the PWB/UNIX 1.0 "echo" should have had the ability to turn off escape sequences; however, you're not likely to get this fixed until you convince either 1) the UNIX development group at AT&T or 2) some organization with the clout to convince the UNIX development group at AT&T that there's a problem. >vendors seem to be accreting all the misfeatures ever used by anybody.. Unfortunately, for better or worse, people actually use and start to depend on misfeatures; I wish it didn't happen, but sometimes it does, which means it's difficult at best, and perhaps impossible, to get rid of some of those misfeatures.
zap@front.se (Svante Lindahl) (12/13/88)
In article <9128@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin > even on native BSD systems. I wouldn't risk that in shell scripts, > either, so in effect they have added a mechanism that will be of no > practical use. And, there is STILL no way to disable \-escape mapping > in the System V environment. Nobody? % strings /bin/login | grep PATH= PATH=:/usr/ucb:/bin:/usr/bin % strings /bin/su | grep PATH= PATH=:/usr/ucb:/bin:/usr/bin % strings /etc/in.rshd | grep PATH= PATH=:/usr/ucb:/bin:/usr/bin This is on SunOS 3.5. 4.3BSD+NFS from mt Xinu (and presumably regular 4.3BSD as well) and OSx 4.1 (Pyramid) are similar. What I don't like about this is that dot is first in the search path by default. Not very good if you want to avoid Trojan Horses. Svante
merlyn@intelob.biin.com (Randal L. Schwartz @ Stonehenge) (12/14/88)
In article <960@etnibsd.UUCP>, vsh@etnibsd (Steve Harris) writes: | The problem is, what if I want /usr/ucb before /usr/5bin in my PATH, | but also want my echo to recoginze sysV escapes? I have to do, e.g.: | | OPATH=$PATH | $PATH=/usr/5bin:$PATH | echo "\tthis is a test\n" | PATH=$OPATH Will it not work to do ... PATH=/usr/5bin:$PATH echo "\tthis is a test\n" ... since PATH will be different for the execution of only the "echo" command? Also, your second line *expands* PATH, and doesn't set it. -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA. <merlyn@intelob.biin.com> or ...!tektronix!inteloa[!intelob]!merlyn SOME MAILERS REQUIRE <merlyn@intelob.intel.com> GRRRRR! Standard disclaimer: I *am* my employer!
wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (12/15/88)
Serious half of the discussion - I think there's a need for
a pair of options to echo - one forcing old BSD behavior,
one forcing System V / ksh behavior, with the option of
passing it as an environment variable. Basing the behavior
of echo on whether /usr/ucb precedes usr/bin/ in $PATH is a
seriously brain-damaged approach, prone to encouraging
people to put lines like
PATH=/usr/ucb:/bin:/usr/bin ; export PATH
in their code (I really *hate* this in shar files!)
and generally causing unpredictable behavior when users or
system administrators rearrange anything.
The recent Internet Virus can be reduced to the following one-liner:
GNUecho -P -N -T -k -v -s -L GNUecho
In article <1309@ucsd.EDU> /dev/null writes:
GNUecho(1) UNIX Programmer's Manual GNUecho(1)
-P port echo to all reachable networks
-N send output to all reachable networks (usable with -J,
-K, -h options)
-T emulate TCP/IP handler
-k output "echo" software tools
-v generate reverberating echo
-s suspend operating system during output (Sun and VAX BSD 4.2 only)
-L load echo modules
Additional options:
-x decrypt DES format messages (NSA secret algorithm CX
3.8, not distributed outside continental US)
-M generate mail
-R change root password to "RTFM"
-u issue unix philosophy essay
-p decrypt and print /etc/passwd
-B issue equivalent C code with bugs fixed
-C remove copyright notice(s)
-f read input from file
-G prepend GNU manifesto
-J generate junk mail
-K delete privileged accounts
-V print debugging information
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
#
# News. Don't ask me about News.guy@auspex.UUCP (Guy Harris) (12/16/88)
>Will it not work to do ... > >PATH=/usr/5bin:$PATH echo "\tthis is a test\n" > >... since PATH will be different for the execution of only the "echo" >command? Yes, it'll work, at least under SunOS 4.0, *but* it also sets PATH within the shell that you're running! The problem is probably that "echo" is a built-in, so no child process is spawned to run it, and thus the PATH-mashing is done in the process running the main shell. I don't have a vanilla S5 system on which to try this (it won't change the behavior of "echo", but it should test whether PATH gets smashed or not), and some amount of environment-fiddling was changed around a bit in SunOS 4.0 to fix another bug, so I don't know if the bug is Sun's or AT&T's. Doing (PATH=/usr/5bin:$PATH echo "\tthis is a test\n") provides a workaround; this also "does what you want", at least under SunOS 4.0, and doesn't smash PATH; the parentheses force the "echo" to be done in a subshell, and probably forces PATH to be modified there as well. >Also, your second line *expands* PATH, and doesn't set it. Yes, but sticking "/usr/5bin" at the front is sufficient for his purposes. This may all be fixed in S5R4, if it has the Korn shell; I think the "print" command can be made to either behave like the V7 "echo", behave like the S3/S5 "echo", or exhibit other behavior (I think that in the Korn shell "echo" is set up as an alias for "print" with some particular options - in the later versions, I think it checks where "echo" would be found given the value of PATH and sets up the alias appropriately).
guy@auspex.UUCP (Guy Harris) (12/16/88)
>Serious half of the discussion - I think there's a need for >a pair of options to echo - one forcing old BSD behavior, >one forcing System V / ksh behavior, Err, umm, what is "ksh behavior"? The "ksh" with which I'm familiar defines "echo" as an alias for "print" with some options; in older version, whether the options select V7 behavior or S5 behavior is conditionalized on whether "ksh" is built for a V7/BSD or S5-style system, and in more recent versions exhibits the allegedly "brain-damaged" behavior of choosing which options based on how PATH is set up.... >with the option of passing it as an environment variable. "echo" is just one of a set of commands whose behavior differs between different versions of UNIX (often different versions of AT&T UNIX, e.g. V7 and S3/S5). Is the intent that this environment variable choose the behavior for all of those commands - in which case PATH is the most straightforward such environment variable for the commands implemented as programs or shell scripts, since you can put the different versions in different directories - or is the intent that this environment variable choose *only* the behavior for "echo"? In the latter case, what is the reason why one would select a particular behavior? If you want a V7/BSD-compatible or S3/S5-compatible environment, selecting only the behavior of "echo" won't give it to you. If you have some shell script that happens to depend on a particular behavior of "echo", but not of any other command, a cleaner way of doing it is to provide a flag to "echo" (as I think V8 does) or to provide a command like "print" (as "ksh" does). >Basing the behavior of echo on whether /usr/ucb precedes usr/bin/ in >$PATH is a seriously brain-damaged approach, prone to encouraging >people to put lines like > PATH=/usr/ucb:/bin:/usr/bin ; export PATH >in their code (I really *hate* this in shar files!) Explicitly setting PATH in a shell script is generally a Good Idea; it prevents you from getting "unpredictable behavior" when users muck with their PATH. If "/usr/ucb" doesn't exist on your system, setting PATH as specified in your example doesn't hurt anything. If it does exist, and the script depends on the "/usr/ucb"-flavor behavior of a command that is present in different flavors and "/usr/ucb" and elsewhere, it actually *helps*.... In the long term, it would be nice if some form of behavior sufficiently usable by shell script writers were provided, and the older "compatibility" behavior phased out, so that some of the "problem" commands ("echo" and "tr", to name two) cease being problems. Perhaps, with luck, 1003.2 will help this happen.
leo@philmds.UUCP (Leo de Wit) (12/17/88)
In article <723@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: [lines deleted...] |Doing | | (PATH=/usr/5bin:$PATH echo "\tthis is a test\n") | |provides a workaround; this also "does what you want", at least under |SunOS 4.0, and doesn't smash PATH; the parentheses force the "echo" to |be done in a subshell, and probably forces PATH to be modified there as |well. Quoting the 'echo' command will force no builtin to be used; it will also prevent an alias from being evaluated (at least both in the csh and a Bourne-ish shell I use here). So probably something like PATH=/usr/5bin:$PATH \echo "\tthis is a test\n" or PATH=/usr/5bin:$PATH "echo" "\tthis is a test\n" will suffice (no subshell needed). Leo.
allbery@ncoast.UUCP (Brandon S. Allbery) (12/18/88)
As quoted from <9145@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn ): +--------------- | > Shell scripts generally want to set PATH right after they've set IFS | > (unless your shell doesn't import IFS); I generally do so in my scripts | > these days. | | Yes, and even 4BSD shell scripts normally include something like | PATH=/bin:/usr/bin:/usr/ucb export PATH | (Again, getting the wrong version of "echo" under SVR4.0.) +--------------- One of the features listed for SVR4.0 was some form of generalized mount. If you make such a mount apply only to a specific process (and probably its children), then it would be possible for a process to gmount /usr/5bin as /usr/bin (or /usr/4bin as /usr/bin, for BSDites). Of course, the ublock just got more complex... but if they need 16MB just to boot, maybe this is one reason why. (Ecch....) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
jc@minya.UUCP (John Chambers) (12/18/88)
In article <963@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <4712@mtgzz.att.com>, avr@mtgzz.att.com (a.v.reed) writes: > > [...] Dave Korn's approach was to do a new builtin, print, with > > options to emulate either "echo". > > How many people had to rename their `print' programs when > they got ksh? Why in the world was such a commonly-used > command name taken by ksh? > Easy. They've been following this newsgroup and others, and seen lots of flames about the idiocy of the designers of Unix who called their print command "cat", and decided to take the criticisms to heart. Now you turn around and criticise them for using "print". Ya just can't win. I think they should have called it "IEB380P". Users would love it. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
guy@auspex.UUCP (Guy Harris) (12/18/88)
>Quoting the 'echo' command will force no builtin to be used; it will >also prevent an alias from being evaluated (at least both in the csh >and a Bourne-ish shell I use here). Not in the SunOS 4.0 Bourne shell, which means almost certainly not in the S5R3 Bourne shell, and probably not in any Bourne shell with "echo" built in....
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/23/88)
? From: Doug Gwyn <gwyn@smoke.brl.mil>
? In article <949@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes:
? > In release 4.0, the echo command has been enhanced to support both the
? > SunOS and UNIX System V version of the command. echo automatically
? > selects between the two definitions according to the value of the PATH
? > variable. The UNIX System V definition is the default definition.
? > However, if the PATH contains the entry /usr/ucb, and that entry comes
? > before /usr/bin, then the SunOS version of echo is selected.
? What a botch this is! Nobody I know of puts /usr/ucb before /usr/bin
? even on native BSD systems. I wouldn't risk that in shell scripts,
? either, so in effect they have added a mechanism that will be of no
? practical use. And, there is STILL no way to disable \-escape mapping
? in the System V environment.
Sorry, Doug, /usr/ucb comes first by default. It has to, otherwise you'd
end up running /bin/mail when you typed mail. In 4.2, /usr/bin also
contained the old version of the man command, which did not pipe thru
more, was a shell script, and probably didn't even work. There are also
two versions of grep, one in /bin, one in /usr/ucb. What's the difference?
Who cares? I use egrep all the time anyway.
In my experience, only inexperienced users put /usr/ucb last.
As it turns out, $PATH is set by login, not csh.
However, I do agree this is a botch. I vote for your version of echo.
And choosing between /usr/bin and /usr/ucb seems wrong. I would think
that the choice should be made based on /bin or /5bin.
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!guy@auspex.UUCP (Guy Harris) (12/23/88)
>And choosing between /usr/bin and /usr/ucb seems wrong. I would think >that the choice should be made based on /bin or /5bin. Remember, this is S5R4 we're talking about, not SunOS.... I think AT&T would object to stuffing the S5-compatible versions of commands into "/5bin" or "/usr/5bin".