POSIX Update: Shell and Utilities.

mak at mbf.UUCP mak at mbf.UUCP
Thu Mar 1 07:16:48 AEST 1990


At Date: 19 Feb 90 18:29:46 GMT , peter at ficc.uu.net (Peter da Silva) said:
--
--I just read in the recent /usr/group "white paper" that...
--
--	Earlier drafts de-emphasised the !test! command in favor of
--	a new ![[ ]]! command. This new invention was discarded in the
--	current draft (Draft 9), but a new shell keyword, !, was added
--	to negate the return value of a pipeline to make test easier
--	to use for complex expressions.
--
--I fail to understand what was wrong with the existing ![ ]! command.
--
--Could someone elaborate?

Peter,

I am not sure what all those !'s mean. But in re-reading the
first (included) paragraph, my guess is that I should refer you back
to Draft 8. Page 128, beginning with line 1063, reiterates
some of Dave's reasons for the [[ ]] vs. test. I remember
that he based this rationale on a study about shell programming
errors (internal to Bell Labs?).

Korn's data showed that a new, quoting syntax, ala
[[ ]], would be less prone to programming error, and it could be made to
have a richer set of tests. Unfortunately, the quoting itself is a
problem for standardization. (see my postscript.)

But there really is nothing there which explains why [[ ]] instead of
[ ], per se. I believe that it separates [ ] and [[ ]] semantics so
extra goodies can be put into the shell "language."

Also, I do note that [ ] is missing from Bourne's paper on the
UNIX shell, BLTJ, July/Aug '78. All that means (to me) is that [ ]
MAY not have been in bourne shell. (Please note the dichotomatic use
of the terms, bourne shell and  /bin/sh. My friends at Summit tell me
that these are different shells.)

I just hope that I was able to shed some light on the subject.
By the way, tell me what is this "white paper!"

= Bob Makowski

P.S. Between Draft 8 and Draft 9, the [[ ]] and (( )) were removed to
resolve balloting objections.

The Balloting Group has realized that the [[ ]] and the (( )) syntax 
break compatability with BOURNE, /bin/sh, csh: the problem is not so 
much the [[ ]] or (( )), per se. It's what goes inside these delimiters. 

o ksh required new semantics for shell meta-characters

	Let's start with * : it has a new meaning inside the (( )).
	If a ksh script is run by /bin/sh or csh, * could be filename
	expanded; so for ksh to work these math expressions, (( )) has to
	quote the file metacharacters. (In fact, Draft 8, line 721, p122,
	says (( )) behaves as if (" ") quoting were applied.)

	Obviously, (( )) does not have this semantic in csh or /bin/sh.

	For [[ ]], the situation is more or less the same; e.g., in Draft
	8, [[ ]], as well as (( )), support > and < for comparisions.
	Again, ksh quotes inside [[ ]], whereas /bin/csh and csh would not.

o counterindications: a thought experiment

	So SUPPOSE that a ksh script were run by /bin/sh. (There are only
	a million binary copies, so it might be important case ;-)

	So SUPPOSE that /bin/sh interpreted * , < , > from inside (( ))
	and [[ ]].

	With * in a math expression, there'd be filenames; With > in [[
	]], a file would be clobbered to a null length.

o unwinding and implementations

	I tried these on SVR3.2 and grammar does not "unwind" enough to
	interpret > or < as re-direction. But this is an "accident" of the
	implementation; I do not recall a specification requiring this to
	happen for POSIX compliant systems. Moreover, there is a strong
	predeliction against POSIX' requiring implementations.
	(Thankfully, this has much to do with the IEEE, per se, but it's
	also due to the DEC suit over the SVID in AFCAC.)

-- 
= Mak :.................................................................:
: [Americans] have a philosophical method ...  To evade the bondage of  :
: system and habit, of family maxims, class opinions, and in some       :
: degree, of national prejudices; to accept tradition, only as a lesson :
: to be used in doing otherwise and doing better; ...                   :
: ............................................Alexis de Tocueville, 1790:



More information about the Comp.org.usrgroup mailing list