Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ukma!morgan
From: morgan@ms.uky.edu (Wes Morgan)
Newsgroups: comp.unix.shell,sublink.lang.shell
Subject: Re: Bourne Shell bug? Have a look..
Message-ID: <1991Jan16.153557.15548@ms.uky.edu>
Date: 16 Jan 91 15:35:57 GMT
References: <1174@otello.sublink.org> <1991Jan16.152933.7288@usenet.ins.cwru.edu>
Organization: The Puzzle Palace, UKentucky
Lines: 36

chet@po.CWRU.Edu writes:
>Paolo Ventafridda writes:
>
>$ :
>$ set "one two three 4"
>$ if [ "`echo $@ | grep '4'" != "" ]; then 
>$ 	echo "Four"
>$ fi
>$ 
>
>The `standard' AT&T Bourne shell will silently add a missing
>closing delimiter when it hits EOF.  I don't think ksh does,
>except maybe for sh compatibility; this was listed by Korn in
>his book as one of the differences between ksh and sh.  Bash
>doesn't either. 

Hmmmmm.....if it added the delimiter when it hit EOF, wouldn't
it put it at the end of the script, giving an "unexpected end
of file" error?   I had thought that this might be a precedence
problem.  If sh(1) assigned a higher precedence to " than to `
or ', wouldn't it insert it at the appropriate place?  I tested
this, and the script above works with missing ' as well as with
missing " or `..........

The FM on this system doesn't give a precedence listing for
metacharacters in sh(1); does such a beast exist?

Curious,
Wes


-- 
    | Wes Morgan, not speaking for | {any major site}!ukma!ukecc!morgan | 
    | the University of Kentucky's |        morgan@engr.uky.edu         |
    | Engineering Computing Center |   morgan%engr.uky.edu@UKCC.BITNET  | 
     Lint is the compiler's only means of dampening the programmer's ego.