pfeiffer@irit.fr (Daniel Pfeiffer) (04/09/91)
Gosh, so many shells! When I started UNIX all we had was Bourne
shell, so I learnt this and dreamed about C shell. When I finally got
that, it fairly much turned me off, so I stuck with Bourne. Then came
C Shell, Toronto C shell, Korn shell, Bourne Again shell and I just
read about ash ...
I don't need a huge shell (as in csh's 266240 bytes compared to sh's
102400 which is still a whopper)! Of course with paging and swapping
it doesn't make a difference, but I just don't _like_ it :-)
I don't need a history or a command line editor, GNU Emacs does that
better than any shell will ever be able to!
Does some shell just provide improvements over Bourne shell. Given
the amount of code that exists for Bourne shell this should be upwards
compatible. For example I heard that [ test ] is a built in for ksh.
Does that mean we have we can say (without ;):
if [ test ] then
while [ test ] do
The only things I miss in Bourne shell is a list type or something
like that, so I can get at ${27} or ${$#} for command line args, and
for similar but separate structures of my own. And it would be nice
if it could do some clever redirection for builtins and functions in
pipelines, rather than fork off a subshell for each one. Then we
wouldn't have to bend over backwards to set variables, cd and other
things.
--
-- Daniel Pfeiffer <pfeiffer@cix.cict.fr>
-- Tolosa (Toulouse), Midi-Pyrenees, Europe <pfeiffer@irit.fr>
-- "Beware - polyglot esperantist" <pfeiffer@frcict81.bitnet>
--
N
_---_
/ \ NEWS, it goes around the world.
W (-------) E (sorry, my bitmap doesn't have a world-class resolution)
\_ _/
---
Sjbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) (04/16/91)
In <1455@irit.irit.fr> pfeiffer@irit.fr (Daniel Pfeiffer) writes: >I don't need a history or a command line editor, GNU Emacs does that >better than any shell will ever be able to! Have you tried emacs mode in KSH? I'm not familiar with Emacs (GNU or otherwise), but I find that emacs mode in KSH is great. >Does some shell just provide improvements over Bourne shell. Given >the amount of code that exists for Bourne shell this should be upwards >compatible. For example I heard that [ test ] is a built in for ksh. >Does that mean we have we can say (without ;): > >if [ test ] then >while [ test ] do Actually, I think what you say in KSH is: (the preferred notation) if [[ expression_to_be_run ]] then while [[ expression_to_be_run ]] then The 'test' notation and the [ notation (according to the KSH book) have been made obsolete by the [[ ]] notation. >The only things I miss in Bourne shell is a list type or something >like that, so I can get at ${27} or ${$#} for command line args, and >for similar but separate structures of my own. And it would be nice >if it could do some clever redirection for builtins and functions in >pipelines, rather than fork off a subshell for each one. Then we >wouldn't have to bend over backwards to set variables, cd and other >things. Sounds like KSH is for you! You can do all that, but ${$#} is the PID of the command, and not the number of arguments to the command ($# is this). I recommend you get the KSH and the book by Morris I. Bolsky and David G. Korn called the "The Kornshell Command and Programming Language" (ISBN 0-13-516972-0). It's a great book and even though I've only had my copy for about 3 weeks, I've already gained a world of knowledge from it. >-- >-- Daniel Pfeiffer <pfeiffer@cix.cict.fr> >-- Tolosa (Toulouse), Midi-Pyrenees, Europe <pfeiffer@irit.fr> >-- "Beware - polyglot esperantist" <pfeiffer@frcict81.bitnet> >-- Jeff -- +----------------------------------------------------------------------------+ | "If you hear an onion ring - answer it." J.B. Nicholson | +----------------------------------------------------------------------------+ | jeffo@uiuc.edu (Internet) These opinions are mine, that's all.| +----------------------------------------------------------------------------+
andy@ausvm1.iinus1.ibm.com (Andy Martin) (04/16/91)
In article <1991Apr16.050922.22662@ux1.cso.uiuc.edu>, jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: > From: jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) > Subject: Re: shells? > > In <1455@irit.irit.fr> pfeiffer@irit.fr (Daniel Pfeiffer) writes: > > >I don't need a history or a command line editor, GNU Emacs does that > >better than any shell will ever be able to! > > Have you tried emacs mode in KSH? I'm not familiar with Emacs (GNU or > otherwise), but I find that emacs mode in KSH is great. > > Sounds like KSH is for you! You can do all that, but ${$#} is the PID > of the command, and not the number of arguments to the command ($# is > this). I recommend you get the KSH and the book by Morris I. Bolsky > and David G. Korn called the "The Kornshell Command and Programming > Language" (ISBN 0-13-516972-0). It's a great book and even though I've > only had my copy for about 3 weeks, I've already gained a world of > knowledge from it. > Are you telling me after nine years of loyalty to the Bill Joy school of thought that vi (vee-eye) and csh are no longer the preferrered editor and shell. Frankly I'm appalled. Joy may have changed his image over there at Mountain View but his legacy is as valid to day as it was in those early days at Berkeley. I for one continue to use vi and csh. +------------------------------------------------------------------------+ | Andy Martin, Cooperating Compound Object Toolkit (CCOT). | | IBM Personal Systems Programming, 11400 Burnet Road, Austin, TX, 78759.| | Office: 808/1K-014, Internal Zip: 3008, Phone: (512) 823-1801. | | Internet: amartin@ausvm1.vnet.ibm.com | | VNET: AMARTIN at AUSVM1 | | Austin: andy@ruddles.austin.ibm.com | +------------------------------------------------------------------------+
marcus@illusion.uucp (Marcus Hall) (04/17/91)
In <1455@irit.irit.fr> pfeiffer@irit.fr (Daniel Pfeiffer) writes: +Does some shell just provide improvements over Bourne shell. Given +the amount of code that exists for Bourne shell this should be upwards +compatible. For example I heard that [ test ] is a built in for ksh. +Does that mean we have we can say (without ;): + +if [ test ] then +while [ test ] do In article <1991Apr16.050922.22662@ux1.cso.uiuc.edu> jeffo@uiuc.edu writes: =Actually, I think what you say in KSH is: (the preferred notation) = =if [[ expression_to_be_run ]] then =while [[ expression_to_be_run ]] then = =The 'test' notation and the [ notation (according to the KSH book) have =been made obsolete by the [[ ]] notation. Most current day Bourne shells have a built-in test. There acutally is a good reason to continue using "["; it is more portable to write in the subset of ksh that the Bourne shell supports. +The only things I miss in Bourne shell is a list type or something +like that, so I can get at ${27} or ${$#} for command line args, and +for similar but separate structures of my own. And it would be nice +if it could do some clever redirection for builtins and functions in +pipelines, rather than fork off a subshell for each one. Then we +wouldn't have to bend over backwards to set variables, cd and other +things. =Sounds like KSH is for you! You can do all that, but ${$#} is the PID =of the command, and not the number of arguments to the command ($# is =this). I recommend you get the KSH and the book by Morris I. Bolsky =and David G. Korn called the "The Kornshell Command and Programming =Language" (ISBN 0-13-516972-0). It's a great book and even though I've =only had my copy for about 3 weeks, I've already gained a world of =knowledge from it. Well, you can get ${$#}, but you have to use eval to get it. This would echo the last argument: eval echo \${$#} The reason that ${$#} gives you the PID is that ${var#pattern} is being used where var is "$" and pattern is "". So, "" is matched (and deleted) from the start of $$ and the result is the process ID. It is possible to do a form of subscripting in ksh (and sh as well) by playing with eval. Thus, if you set xx_1="one", xx_2="two", xx_3="three", i=2, and execute: eval echo \$xx_$i you will get "two" output. This works for any alphanumeric index. Finally, ksh will run loops and functions with simple redirection in the current process, but pipes cause it to create a child process. Thus it still requires the bending over backwards to get variables back from the loop/function. marcus hall
jik@athena.mit.edu (Jonathan I. Kamens) (04/17/91)
In article <1455@irit.irit.fr>, pfeiffer@irit.fr (Daniel Pfeiffer) writes: |> compatible. For example I heard that [ test ] is a built in for ksh. |> Does that mean we have we can say (without ;): |> |> if [ test ] then |> while [ test ] do No, what it means is that the syntax is the same in ksh as it was for sh, but rather than invoking the program "test" to do the test, ksh emulates test internally. In other words, if I have if [ test ]; then ... code here ... fi In the bourne shell, a fork and exec would have to take place to run "test" to perform the test. In the korn shell, the test is performed in the shell process. If the syntax were changed in order to make tests built-in, then many /bin/sh scripts would break under ksh (or, at the very least, would not get the performance advantage of the built-in). Csh's echo is similar to this -- when you use "echo" in csh, you are calling a shell built-in, which pretends to be the separate program "echo", but does what echo would do without any subprocesses. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
chet@thor.INS.CWRU.Edu (Chet Ramey) (04/17/91)
In article <1991Apr17.101443.4196@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In the bourne shell, a fork and exec would have to take place to run "test" to >perform the test. In the korn shell, the test is performed in the shell >process. In all but truly ancient versions of /bin/sh, or perhaps in Research Unix versions, (I do not have my manuals handy to check), test is built in. Chet -- Chet Ramey Internet: chet@po.CWRU.Edu Case Western Reserve University NeXT Mail: chet@macbeth.INS.CWRU.Edu ``Now, somehow we've brought our sins back physically -- and they're pissed.''
chet@odin.INS.CWRU.Edu (Chet Ramey) (04/18/91)
I wrote: >In all but truly ancient versions of /bin/sh, or perhaps in Research Unix >versions, (I do not have my manuals handy to check), test is built in. I should clarify the above by stating that the shell shipped as /bin/sh on 4.2 BSD, 4.3 BSD, and Ultrix systems is indeed a truly ancient version, before people point out that these shells do not have `test' built in. Chet -- Chet Ramey Internet: chet@po.CWRU.Edu Case Western Reserve University NeXT Mail: chet@macbeth.INS.CWRU.Edu ``Now, somehow we've brought our sins back physically -- and they're pissed.''