Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SysV shell questions
Message-ID: <6297@brl-smoke.ARPA>
Date: Wed, 19-Aug-87 21:53:52 EDT
Article-I.D.: brl-smok.6297
Posted: Wed Aug 19 21:53:52 1987
Date-Received: Sat, 22-Aug-87 06:15:27 EDT
References: <10279@orchid.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 49

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.