egisin@orchid.UUCP (08/19/87)
I'm working on enhancing a public domain Bourne shell to be SysV compatible, and have a couple of questions. The SysV built-in echo command recognizes some \ escapes. I don't thing this was a good idea. You can't rely on `echo "$var"' to print an variable whose value contains \'s correctly anymore. Have people had problems with this, and what have you done about it? The author of the PD shell suggested I make functions exportable. It seems this was a design goal for the SysV shell, but was not implemented for some reason. It could have been an implementation problem, or that function definitions in the enviroment break other programs. Has function exportation been implemented in any Bourne-based shell? Does anyone have any suggestions regarding this? Eric Gisin, egisin@waterloo.edu, watmath!egisin
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/20/87)
In article <10279@orchid.waterloo.edu> egisin@orchid.waterloo.edu (Eric Gisin) writes: >The SysV built-in echo command recognizes some \ escapes. >I don't thing this was a good idea. You can't rely on `echo "$var"' >to print an variable whose value contains \'s correctly anymore. What is needed is (1) agreement on an acceptable ultimate "echo" and (2) a transition plan. What I propose for (1) (and have implemented for (2) in my System V emulation package and Bourne shell) is: echo stuff # plain echo without \-interpretation echo -n stuff # ditto without trailing NL (a la 7th Ed.) echo -e stuff # echo with \-interpretation (a la 8th Ed.) echo -? # (other options) -- error (unless "--") The transition plan is: Berkeley and other systems based on 7th Ed.: Implement the final design (add -e). System III and V based systems: Phase I: Add the -n option; Accept -e (no-op in Phase I). Phase II: Convert all shell scripts to use -e. Phase III: Implement the final design. I have assumed that echo -? (? not e or n) is not important to anyone; if it is; they need to fix those scripts (use "--"). Now, if we can get IEEE 1003.2 to bless the final specification (or at least Phase I of the System V transition plan), we'd be on the way to a single combined, sensible "echo" command. >Has function exportation been implemented in any Bourne-based shell? Yes, in 8th Edition UNIX. I recommend NOT doing this, for the following reasons: (1) Most environment-reading applications and standards require the environment strings to all have the form name=value. For example, older Bourne shells die miserably when the environment contains something not in that form. (2) The environment is a resource that should not be squandered. Some of us could just about use it up just for our function definitions, and large environments slow down execs. (3) One can conveniently define shell functions in a per-invocation startup file, as in the Korn and BRL shells via the ENV environment variable (startup file name). This facility turns out to be very handy for lots of other things and is therefore more generally useful than putting function definitions in the environment.
rml@hpfcdc.HP.COM (Bob Lenk) (08/21/87)
> echo stuff # plain echo without \-interpretation > echo -n stuff # ditto without trailing NL (a la 7th Ed.) > echo -e stuff # echo with \-interpretation (a la 8th Ed.) > echo -? # (other options) -- error (unless "--") > The transition plan is: > Berkeley and other systems based on 7th Ed.: > Implement the final design (add -e). > System III and V based systems: > Phase I: > Add the -n option; > Accept -e (no-op in Phase I). > Phase II: > Convert all shell scripts to use -e. > Phase III: > Implement the final design. > > Now, if we can get IEEE 1003.2 to bless the final specification > (or at least Phase I of the System V transition plan), we'd be > on the way to a single combined, sensible "echo" command. The big problem is still the cost of phase II for System III and V based systems. Many/most vendors would not be willing to force that upon customers, backward compatibility being non-negotiable. The sense of -e could be reversed, but that would just place the cost on the other side of the BSD/ATT fence. Two flags to specify the desired (non)interpretation of backslash, with the default implementation defined might be the best compromise reachable. Having echo be sensitive to some environment variable that set the default might be a slight improvement on that compromise. Bob Lenk {ihnp4, hplabs}!hpfcla!rml
allbery@ncoast.UUCP (Brandon Allbery) (08/22/87)
As quoted from <10279@orchid.waterloo.edu> by egisin@orchid.waterloo.edu (Eric Gisin): +--------------- | The author of the PD shell suggested I make functions exportable. | It seems this was a design goal for the SysV shell, but was not implemented | for some reason. It could have been an implementation problem, | or that function definitions in the enviroment break other programs. | Has function exportation been implemented in any Bourne-based shell? +--------------- The problem with exporting functions is that if they are compatible with getenv() then there's no reliable way to identify them as functions; and if they aren't, then any program calling getenv() will break when used under the shell with exported functions. I personally prefer the $ENV solution: if the environment contains "ENV=filename" when the shell starts up, source the file. (This is from ksh.) BTW, if this is the Minix sh, let me know what you are doing. I'm trying to cajole Doug Gwyn to send me diffs to implement Tenex-style line editing in the Bourne shell, with intent to see how hard it would be to retrofit them into the Minix sh -- the source looks something like the same kind of code as in the SVR2 shell. (At least, as I remember it from a few years ago.) [If that fails, I'll try designing one of my own, and would prefer to use a "modernized" shell.] -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" is changing its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". ***
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/23/87)
In article <5980007@hpfcdc.HP.COM> rml@hpfcdc.HP.COM (Bob Lenk) writes: >The big problem is still the cost of phase II for System III and V based >systems. I didn't say how long Phase 2 would have to last. If there is going to be a merged "echo" with semantics the application developer can count on common to both Berkeley- and System V- based environments, obviously at some point all uses of echo in one environment or the other will HAVE to be revised. That's what a transition plan is for. The original Bell Labs "echo" did not "interpret" its arguments (i.e. map escape sequences). The PWB folks who added that feature botched it when they provided no way to disable the interpretation. Therefore it is quite fair for that camp to be the one that has to do the work eventually. (Note that I am often accused of being in that camp myself.) My proposal for -n and -e has already been implemented in 8th Edition UNIX (except possibly for reserving all other - options), and I've spread it around a bit in the BRL UNIX System V emulation for 4.nBSD and in the support that can be optionally built into the native 4.nBSD version (actually, any version) of our fancy Bourne shell. Technically one could indeed add yet another flag defined to mean "definitely don't interpret escapes", although I don't really think it helps -- portable applications would STILL have to change to meet the "echo" standard, and by not specifying the default behavior you would force ALL existing use of "echo" to be changed (at least, if one is concerned about portability), not just one camp's. Using environment variables for stuff like this is just too yucky! If you understand the design principles behind the UNIX environment, it should be obvious that plain, unadorned "echo" should do the semantically simplest thing, namely no escape interpretation. That is consistent with what I propose but not with System V's current behavior. I was hoping that IEEE 1003.2 would straighten out a lot of the featurefulness that has infected basic UNIX utilities over the years, rather than bless it. It would behoove them to study a 9th Edition UNIX Programmer's Manual, then try to improve on it.
ado@elsie.UUCP (Arthur David Olson) (08/25/87)
> If there is going to be a merged "echo" with semantics the application > developer can count on common to both Berkeley- and System V- based > environments, obviously at some point all uses of echo in one environment > or the other will HAVE to be revised. I think the egalitarian thing to do here is have all uses of echo in BOTH environments revised. I'd accomplish this by replacing the "echo" command with some new command--say, for example, say, as in $ say what\? what? The old echoes would be left in place (but deprecated) for some period of time; then removed (or set up to send broadcast messages to everyone on the system if used :-). The advantage of this approach is that it eliminates guesswork--if a shell script uses "say", you *know* the shell script is counting on the agreed-upon merged semantics being applied. -- UUCP: elsie!ado Elsie and Ado are trademarks of Borden, Inc. and Ampex.
dgk@ulysses.homer.nj.att.com (David Korn[eww]) (08/28/87)
I have tried to find a satisfactory solution for the echo incompatibility
problem for the last several years.
No solution works. A lot of code will break no matter what you do. I propose
that we use a new command to replace echo. The new command would be able
to subsume both the AT&T and BSD functionality.
This solution will not break any old scripts. In about 50 years or so, all
the old scripts with echo can be converted to use the new command.
ksh has the print built-in command which subsumes both BSD and Sys V echo.
print -r does not perform escape sequence expansions
print -n does not echo a newline
print -u2 will echo into file descriptor 2.
David Korn
{ihnp4,allegra}ulysses!dgkgwyn@brl-smoke.ARPA (Doug Gwyn ) (08/28/87)
In article <2888@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes: >I propose that we use a new command to replace echo. If we're going to invent a new command for this (a real pity), let's get its design RIGHT this time. Default (no options) behavior should NOT interpret escape sequences. \c is an ugly kludge that should be removed and a no-newline (-n) option used instead when that behavior is desired. You basically end up with 8th/9th Edition "echo" but with a different name (which means it can just be a link to "echo" on non-SysV systems). 9th Edition UNIX also has a "printf format args..." utility that does the obvious thing.
loverso@encore.UUCP (John LoVerso) (08/29/87)
In article <2888@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes: > print -u2 will echo into file descriptor 2. Why not just "print 1>&2" ? John LoVerso <loverso@multimax.arpa> Encore Computer
xsimon@its63b.UUCP (08/31/87)
In article <2888@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes: > >ksh has the print built-in command which subsumes both BSD and Sys V echo. >print -r does not perform escape sequence expansions >print -n does not echo a newline >print -u2 will echo into file descriptor 2. > >David Korn >{ihnp4,allegra}ulysses!dgk I don't see why a "print -u2" is necessary. Is this a particular example of a more-general "print-on-a-named-descriptor" feature (so that "print -u4", etc.. will do The Obvious Thing), or is it a once-off? In either case, there seems little point in introducing extra syntax for doing what can be easily done with existing syntax - namely "print ... 1>&2". Or is it that you cannot redirect i/o on a builtin in ksh? (I know, I should try this out to see, but that involves fetching sources off tape and compiling them which will take years and years...) Another thing - it looks like this "print" built-in cannot be used to echo anything that already begins with a "-" (because this would get interpreted as an option-flag). Or is there another option-flag to say "No more flags, just echo the rest!". %{ Simon. %} -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!its63b!simon | Department of Computer Science | JANET: simon@uk.ac.ed.its63b | University of Edinburgh, | ARPA: simon%its63b.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | ---------------------------------- "Life's like that, you know"