Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mips!wyse!bob
From: bob@wyse.wyse.com (Bob McGowen x4312 dept208)
Newsgroups: comp.unix.shell
Subject: Re: Finding the last arg
Keywords: Bourne shell arguments
Message-ID: <3083@wyse.wyse.com>
Date: 2 Jan 91 20:12:05 GMT
References: <18476@shlump.nac.dec.com> <3074@wyse.wyse.com> <1991Jan2.174157.21530@usenet.ins.cwru.edu>
Sender: news@wyse.wyse.com
Reply-To: bob@wyse.UUCP (Bob McGowen x4312 dept208)
Organization: Wyse Technology
Lines: 40

In article <1991Jan2.174157.21530@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes:
>>>In fact, they need to be BSD bourne shell
>>>scripts rather that ATT Bourne shell scripts.  The difference is probably
>>>significant here, because of the differences in the way these two Bourne
>>
>>  As an aside, could you explain this comment?  I have had minimal contact
>>  with BSD, but my experience does not seem to support this statement.
>
>The BSD /bin/sh is the one from v7, with minimal changes for the 4.2 BSD
>signal semantics (restarted system calls, etc.) and # as a comment
>character.  The AT&T /bin/sh changed drastically beginning with System V.2,
>and further changes appeared in System V.3. 
>
>Here's a short list of what was added to the v7 sh for the System V.2 sh:

---description of differences deleted---

>accepts # as a comment only when non-interactive.
>
>Chet
>-- 

Thanks for the list of differences.  It will be useful, I'm sure!-)

However, the original posters statement was that there were differences
in how the versions of the shells handle "variables", which my 
experience seems to show is either the same or very nearly so, since
all of the scripts I have written work with both BSD and AT&T sh's.
So, even though the above list is very useful, the specific point of
possible differences in how the shells handle parameters (command
line arguments and variables) is still open.

Any information on this particular point would be helpful.

Thanks,

Bob McGowan  (standard disclaimer, these are my own ...)
Product Support, Wyse Technology, San Jose, CA
..!uunet!wyse!bob
bob@wyse.com