pfeiffer@irit.fr (Daniel Pfeiffer) (04/09/91)
Actually I don't know what shell I have. It is about the same under
EPIX and SunOS except that the former allows echo -n only when called
as sh -B, which breaks scripts on other machines, since that's not a
standard option. And the latter doesn't at all accept echo \c -- talk
about standards! On neither machine the manual gives credit to the
author(s). It looks quite Bournish and it's called /bin/sh. But it
has (like Korn shell I believe) [ test ] as a builtin though the below
neat syntax won't work. There is also a nifty new getopts builtin.
And of course there's job control. Actually again and again I hear
that this is an invention of C shell, but as recently as last year in
spring I still had a csh w/o this. It would seem to me that this is
an old (at least 6 years) feature which was then known as layered
shell (lsh). On my machine at the time this was supposed to allow you
to switch processes and only that so you'd have to have a shell
running under this. Alas, at the time this was broken, and since this
seems to have disappeared, so I've never seen this run.
The title says it: what shell is this???
How I would like tests (feasible since this is a builtin):
if [ test ] then
while [ test ] do
--
-- 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)
\_ _/
---
Sclewis@ferret.ocunix.on.ca (Chris Lewis) (04/18/91)
In article <1456@irit.irit.fr> pfeiffer@irit.fr (Daniel Pfeiffer) writes: >Actually I don't know what shell I have. It is about the same under >EPIX and SunOS except that the former allows echo -n only when called >as sh -B, which breaks scripts on other machines, since that's not a >standard option. And the latter doesn't at all accept echo \c -- talk >about standards! On neither machine the manual gives credit to the >author(s). It looks quite Bournish and it's called /bin/sh. But it >has (like Korn shell I believe) [ test ] as a builtin though the below >neat syntax won't work. There is also a nifty new getopts builtin. They're both Bourne shells. "echo -n" is a BSD-istic echo, hence it's preference on SunOS, and echo "\c" is an SV-istic echo. "[ test ]" is a builtin in most Bourne shells nowadays. "echo" is a builtin in many Bourne shells now too. On recent versions of SunOS there is a complete suite of System V compatibility features, /bin/sh5 etc. Ksh can be identified by seeing if there's a "$RANDOM" variable defined and that it changes each time you reference it. The ability to do shell functions is in the "current" Bourne shell and doesn't indicate that the shell is ksh. >And of course there's job control. Actually again and again I hear >that this is an invention of C shell, but as recently as last year in >spring I still had a csh w/o this. It would seem to me that this is >an old (at least 6 years) feature which was then known as layered >shell (lsh). On my machine at the time this was supposed to allow you >to switch processes and only that so you'd have to have a shell >running under this. Alas, at the time this was broken, and since this >seems to have disappeared, so I've never seen this run. Few System V versions of UNIX have job control in their csh's because the kernel support for it is (was) a BSD-only-ism and rarely present. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
dcon@cbnewsc.att.com (david.r.connet) (04/19/91)
In article <1410@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >They're both Bourne shells. "echo -n" is a BSD-istic echo, hence it's >preference on SunOS, and echo "\c" is an SV-istic echo. "[ test ]" >is a builtin in most Bourne shells nowadays. "echo" is a builtin >in many Bourne shells now too. On recent versions of SunOS there is >a complete suite of System V compatibility features, /bin/sh5 etc. There is actually a /5bin (or is it /usr/5bin, it's been a while...). The commands are in there (like sh, echo ...) Dave Connet dcon@iwtng.att.com
karl.kleinpaste@osc.edu (04/20/91)
clewis@ferret.ocunix.on.ca writes: >And of course there's job control. Actually again and again I hear >that this is an invention of C shell, but as recently as last year in >spring I still had a csh w/o this. Few System V versions of UNIX have job control in their csh's because the kernel support for it is (was) a BSD-only-ism and rarely present. Most SysV vendors should be flogged over the head with a listing of the ancient csh source they use in their distributions. A couple things about it... Most csh incantations distributed with SysVRel[0-3] are derived from (something like) the 2.8BSD PDP-11 distribution, circa 1982 or thereabouts. This csh was rather primitive (some would say "primitive csh" is redundant, and they might be right) in that it pre-dated the releases of BSD with VM, job control, the new tty driver, and all that rot. It'll compile straight on a real V7, possibly even V6, PDP-11 because it expects no peculiar functions at all. This is why it's nice-n-easy to bring along on SysV. Unfortunately, it also lacks a number of the nicer things csh has gained over the years, such as the dir stack, the eval builtin, and the $< pseudovariable. So if you mumble "dirs" at your Microport or SCO csh, it'll probably complain, "Command not found." That said, I'll assert, for the N+1st time, that it's possible to emulate a hefty fraction of BSD-style job control under SysV using ptrace(2). It's do-able, and livable; I've done it and lived under it for 3+ years when working for AT&T with only SysV for an environment. I hadn't touched it in a couple of years since leaving AT&T, but found cause to clean up a few warts here and there in just the last couple of days, for the sake of someone bringing it up again on cblpn.att.com. --karl