izen@amelia.nas.nasa.gov (Steven H. Izen) (11/19/89)
The C-shell which was included with 386/ix (a system V UNIX for 386 boxes)
does not support job control. Is this because
1) The kernel is missing something required to support it,
2) ISC was too lazy to implement it, or
3) other?
Enquiring minds want to know.
--
Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner:
or steve%izen386.uucp@skybridge.scl.cwru.edu /
or izen@cwru.cwru.edu /-------------------------/ My second bike is a car.
| The problem is that I *was* paying attention.gwyn@smoke.BRL.MIL (Doug Gwyn) (11/19/89)
In article <3880@amelia.nas.nasa.gov> izen@cwru.cwru.edu (Steven H. Izen) writes: >The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) >does not support job control. Is this because > 1) The kernel is missing something required to support it, That's it. The horrible kludges needed for job control are rumored to be present in SVR4.0.
leach@tolerant.com (Geoffrey Leach) (11/20/89)
From article <3880@amelia.nas.nasa.gov>, by izen@amelia.nas.nasa.gov (Steven H. Izen): > The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) > does not support job control. Is this because > 1) The kernel is missing something required to support it, > 2) ISC was too lazy to implement it, or You think that ISC's csh is bad, just try the one that ATT ships on their version of the 386 software! Eech!. My guess at the reason. Csh is a Berkley development and SystemV people don't care for Berkley-isms. I once complained about the absence of '-r' on the System V cp command and was told, in efect, that in that context, '-r' was an offence against Decency and the Natural Order of Things.
cpcahil@virtech.uucp (Conor P. Cahill) (11/20/89)
In article <3880@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: > The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) > does not support job control. Is this because This is because job control is a BSDism that has never been part of vanilla System V unix systems. It will be present in system V release 4.0 (available some time next year). Job control requires kernel support that is not present in the 386/ix kernel. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
platt@ndla.UUCP (Daniel E. Platt) (11/21/89)
In article <3880@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: > The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) > does not support job control. Is this because > 1) The kernel is missing something required to support it, > 2) ISC was too lazy to implement it, or > 3) other? > The answer is closer to option 1) (please forgive verbosity... I need to fill space to get this through the news filter...) The Job Control features are based on Berkely xx.xx (pick your version). The C Shell (csh) sends SIGSTOP and SIGCONT. These Berkely functions are not available on SysV (AT&T Unix), and most of the other Unixen supported on i386 boxes. Regards, Dan Platt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- || 1(914)945-1173 || || Dan Platt 1(914)941-2474 || || Watson (IBM) PLATT@YKTVMV.BITNET || || ..!uunet!bywater!scifi!ndla!platt || || || || The opinions expressed here do not necessarily reflect || || those of my employer! || || || -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
marc@dumbcat.UUCP (Marco S Hyman) (11/21/89)
In article <1989Nov19.180741.8950@tolerant.com> leach@tolerant.com (Geoffrey Leach) writes:
I once complained about the absence of '-r' on the System V cp command
and was told, in efect, that in that context, '-r' was an offence against
Decency and the Natural Order of Things.
As long as we are offending nature how about getting really kinky and asking
for a
chmod user.group file ...
such as I do on my BSDish sun at work all the time. I know the litany...
wait for V.4... wait for V.4...
// marc
--
// Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marcnews@haddock.ima.isc.com (overhead) (11/22/89)
In article <251@ndla.UUCP> platt@ndla.UUCP (Daniel E. Platt) writes: >In article <3880@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: >> The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) >> does not support job control. Is this because >> 1) The kernel is missing something required to support it, >> 2) ISC was too lazy to implement it, or >> 3) other? >The answer is closer to option 1) (please forgive verbosity... I need to fill >space to get this through the news filter...) Change the >'s to #'s. >The Job Control features are based on Berkely xx.xx (pick your version). The >C Shell (csh) sends SIGSTOP and SIGCONT. These Berkely functions are not >available on SysV (AT&T Unix), and most of the other Unixen supported on >i386 boxes. OK, I'm getting tired of reading how 386/ix doesn't have Job Control (JC). As a developer, I've been running an inhouse version of JC for some time. 386/ix has JC starting with 2.1[.0]. 386/ix 2.2[.0] will be released soon (I think there has been an announcement). Starting with 2.1, 386/ix supports POSIX 1003.1, and FIPS 151-1. This requires JC. 386/ix 2.2 should be pretty stable, judging by my pre-release 2.1 system. My Compaq 386/25 has been running without problems - up for the last 14 straight days. I believe I brought it down a couple weeks ago to run native MSDOS briefly (it was quicker than installing VP/ix, considering I don't use DOS on this machine "ever"). I haven't had a crash in quite some time. I use the machine extensively. I understand that the changes for 386/ix 2.2 involve bug fixes and making it run on some strange configurations of hardware. ISC spends alot of time making 386/ix run on strange hardware. If we could just use (say) Compaq's, life would be pretty easy. Reasonably massive kernel & utility changes were required for JC under an SVr3 system. ISC listens to their customers. I'd like to thank the IEEE P1003.1 committees for putting Job Control into the POSIX specification (as an option). I'd like to thank the US Government for stating in no uncertain terms (FIPS 151-1) that they want Job Control. The US Government is a buyer with absurd buying power. If they said, "we'd like pretty flowers on the screen during startup", the very next version of 386/ix would have it. Further, it would be out in record time. For the record, the US has made no such request. If I had the choice of running 386/ix 1.0.6 (pre Fast File System (HPDD/FFS)) with JC, and running 386/ix 2.0.2 (last release without JC, but has HPDD/FFS) I would go with the Fast File System every time. I'm used to JC, but with training, I can get myself to put things into the background at command invocation. The Fast File System increases disk performance by a factor of 10 to 15 (given good hardware - track buffering & 1:1 interleave). UNIX systems are often disk bound. I thought that speeding up the disks would make 386/ix CPU bound. False. System throughput increased by a factor of 10 to 15. The system still waits for the disks or the users. X windows can be used as a poor man's JC. Virtual screens can be used as a poor man's JC. Nothing can replace a high speed file system. Oh, I recall someone complaining about not having manual pages. I believe 386/ix 2.2 will also have on-line manual pages. I'd like to blame the AT&T license for this fiasco. First they let you have them, then they didn't, now they'll let us have them again. If you ever get a set on line - i'd keep them on a tape somewhere. If AT&T changes their mind again - you may not have up to date man pages - but you'll still have some. It's legal - you paid for them! Stephen Uitti Interactive Systems Corp suitti@haddock.ima.isc.com DISCLAIMER: I don't speak for INTERACTIVE, I speak for me. Please pardon my header, I'm still trying to get nntp to work right.
news@haddock.ima.isc.com (overhead) (11/22/89)
In article <124@dumbcat.UUCP> marc@dumbcat.UUCP (Marco S Hyman) writes: >In article <1989Nov19.180741.8950@tolerant.com> leach@tolerant.com (Geoffrey Leach) writes: > I once complained about the absence of '-r' on the System V cp command > and was told, in efect, that in that context, '-r' was an offence against > Decency and the Natural Order of Things. 'cp' didn't get '-r' at UCB until after 'rcp' was introduced (which has always had '-r', as far as I know). Somehow, it's what you want, most of the time. Under SysV, % find . -print | cpio -ocB | (cd otherdir ; cpio -icdmB) seems to work. I know, cpio has an option to just copy the directory tree without the other invocation of cpio, but cpio has lots of options... >As long as we are offending nature how about getting really kinky and asking >for a > chmod user.group file ... >such as I do on my BSDish sun at work all the time. I know the litany... >wait for V.4... wait for V.4... Curiously, I wrote something to do that for BSD before it had it. For some reason it doesn't quite work under SysV, else maybe I'd post it. I wrote it because i figured it was quicker than: % find . -exec chown foo '{}' -exec chgrp bar '{}' (This predates xargs). I predict that ISC will jump on the SVr4 bandwagon at the earliest oportunity. For my money, I'd look for one of the last releases of SVr3.2, with POSIX, job control and manual pages. At least this technology is getting stable. (There's always at least one more bug.) I predict that SVr4 will become as stable, fast and functional as, say 386/ix 2.2 (released "soon") in 1993, if ever. For one thing, SVr4 has the Berkeley Fast File System. Vendors will look elsewhere for improvements. Judging by Sun's 386i system, it will be real slow. Stephen Uitti suitti@haddock.ima.isc.com DISCLAIMER: My opinions are my own. In fact, they bear little resemblance to any official opinions anywhere.
martin@mwtech.UUCP (Martin Weitzel) (11/23/89)
In article <15246@haddock.ima.isc.com> suitti@anchovy.UUCP (Stephen Uitti) writes: [some lines deleted] > % find . -print | cpio -ocB | (cd otherdir ; cpio -icdmB) >seems to work. I know, cpio has an option to just copy the directory >tree without the other invocation of cpio, but cpio has lots of options... WHAT! Also internally at ISC there is no online manual. Upgrade to 2.2 :-) (OK, I know, the topic was allready beaten to death.) BTW: If memory serves, try cpio -p ... >> chmod user.group file ... >>such as I do on my BSDish sun at work all the time. I know the litany... [some lines deleted] Wait a minute ... the following shell-script should do it Place it in a directory *before* /bin in your PATH. ------------------------------------------ # BSD-Style(?) chown via chmod # BUGS: Doesn't allow blanks in file names # Doesn't allow dots or blanks in user/group names case $1 in *.*) u="$1";shift;f="$*";IFS=.;set $u;IFS=' ' chgrp $2 $f && exec chown $1 $f ;; *) exec /bin/chmod ${1+"$@"} esac ------------------------------------------ Excuse me, this is a three minute hack, I didn't test very much. I didn't know about this particular BSD-feature before I read this posting. A *real* improvment, I allways wanted, would be a command which *automatically* determines the group of the new user and chgrp-s a file, if I 'chown' it - does BSD have it? [more lines deleted] MW
karl@ficc.uu.net (Karl Lehenbauer) (11/24/89)
Regarding cp -r, I think in 3.2 you will find the "copy" command (from the Xenix compatibility changes), which has a -r option to recursively copy subdirectories. -- -- uunet!ficc!karl "The last thing one knows in constructing a work is what to put first." -- Pascal
platt@ndla.UUCP (Daniel E. Platt) (11/25/89)
In article <15244@haddock.ima.isc.com>, news@haddock.ima.isc.com (overhead) writes: > In article <251@ndla.UUCP> platt@ndla.UUCP (Daniel E. Platt) writes: > >In article <3880@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: > >> The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> does not support job control. Is this because > >> 1) The kernel is missing something required to support it, > >> 2) ISC was too lazy to implement it, or > >> 3) other? > >The answer is closer to option 1) (please forgive verbosity... I need to fill > >space to get this through the news filter...) > Change the >'s to #'s. > > >The Job Control features are based on Berkely xx.xx (pick your version). The > >C Shell (csh) sends SIGSTOP and SIGCONT. These Berkely functions are not > >available on SysV (AT&T Unix), and most of the other Unixen supported on > >i386 boxes. > > OK, I'm getting tired of reading how 386/ix doesn't have Job > Control (JC). As a developer, I've been running an inhouse > version of JC for some time. .... Ok, you are providing Berkely JC in your kernal. That's Great! However, SysV doesn't generally have JC. Many other products based on System V (Stellix, Irix, &c) do support it. Also, some Unixen running on '386's already in distribution do support JC (for example AIX-PS/2). I still don't know why you'd flame people who answered a simple question like: 'why doesn't SysV have job control?' as if it were a personal attack on your prodigious software development efforts? Dan Platt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- || 1(914)945-1173 || || Dan Platt 1(914)941-2474 || || Watson (IBM) PLATT@YKTVMV.BITNET || || ..!uunet!bywater!scifi!ndla!platt || || || || The opinions expressed here do not necessarily reflect || || those of my employer! || || || -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
gmd@ubbs-nh.MV.COM (George MacDonald) (11/29/89)
In article <1989Nov19.180741.8950@tolerant.com> leach@tolerant.com (Geoffrey Leach) writes: >From article <3880@amelia.nas.nasa.gov>, by izen@amelia.nas.nasa.gov (Steven H. Izen): >> The C-shell which was included with 386/ix (a system V UNIX for 386 boxes) >> does not support job control. Is this because >> 1) The kernel is missing something required to support it, >> 2) ISC was too lazy to implement it, or > >You think that ISC's csh is bad, just try the one that ATT ships on their >version of the 386 software! Eech!. > >My guess at the reason. Csh is a Berkley development and SystemV people >don't care for Berkley-isms. One reason for the lack of enthusiasm for csh is that the ksh has existed for over 6 years inside AT&T. FYI the ksh provides all of the csh features in a slightly different way, plus it is smaller, faster and upwards compatible with the bourne shell. The biggest plus with the ksh for me is the command editing is either 'vi' style or 'emacs' style, I can reuse all that I learned from years of vi useage. Ksh is available for the i386 machines and runs very well, some vendors are smart enough to include it(Apple for one) in their distributions. Also ksh is part of Sys V.4 so you will see it sooner or later 8-). Most people who try it like it, although some heavy csh users just can't tear themselves away from the ! culture. >I once complained about the absence of '-r' >on the System V cp command and was told, in efect, that in that context, '-r' >was an offence against Decency and the Natural Order of Things. The argument for "control of -r[R]" goes like this. If we add -r to cp, then why not chmod, chown, ls ..... ad infinitum. This duplicates a lot of functionality, and in many cases this is not done right. Better is to provide this functionality in one place and do it well. Hence, find, cpio -pdl ... On the otherhand, I also have gotton used to cp -r or rcp -r and prefer it! I guess pandora box is already open!
leach@tolerant.com (Geoffrey Leach) (12/02/89)
From article <324@ubbs-nh.MV.COM>, by gmd@ubbs-nh.MV.COM (George MacDonald): > In article <1989Nov19.180741.8950@tolerant.com> leach@tolerant.com (Geoffrey Leach) writes: >>From article <3880@amelia.nas.nasa.gov>, by izen@amelia.nas.nasa.gov (Steven H. Izen): > > One reason for the lack of enthusiasm for csh is that the ksh has existed for > over 6 years inside AT&T. FYI the ksh provides all of the csh features in > a slightly different way, plus it is smaller, faster and upwards compatible > with the bourne shell. The biggest plus with the ksh for me is the command > editing is either 'vi' style or 'emacs' style, I can reuse all that I learned > from years of vi useage. And there's also what looks like a good book on Ksh. Sigh. Perhaps I'll just have to retrain. > On the otherhand, I also have gotton used to cp -r > or rcp -r and prefer it! I guess pandora box is already open! Ah, a truely open mind!
mike@antel.uucp (Michael Borza) (12/04/89)
In article <15244@haddock.ima.isc.com> suitti@anchovy.UUCP (Stephen Uitti) writes: >OK, I'm getting tired of reading how 386/ix doesn't have Job >Control (JC). As a developer, I've been running an inhouse >version of JC for some time. 386/ix has JC starting with >2.1[.0]. And who out there in netland that actually paid money for 386/ix is running 2.1? To the best of my knowledge, 2.0.2 is the latest released version. I've certainly never received a notice that I could upgrade from 2.0.2 to 2.1. If 2.1 has been released for general consumption, I'd be delighted to be corrected (and I'd like my copy). If not, then you as an ISC insider with access to both unreleased information and software have no business slamming users who are expressing their wishes for future product enhancements. I have enjoyed (and hope to continue to enjoy) the presence of ISC people on the net. I do not enjoy the occasional inference that we customers must be inept because we don't have access to the same resources as our supplier. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike
support@ism780c.isc.com (Support account) (12/07/89)
In article <1989Dec3.195259.25413@antel.uucp> mike@antel.uucp (Michael Borza) writes: >And who out there in netland that actually paid money for 386/ix is >running 2.1? To the best of my knowledge, 2.0.2 is the latest >released version. I've certainly never received a notice that >I could upgrade from 2.0.2 to 2.1. If 2.1 has been released for Release 2.1 of 386/ix is a special release intended *only* for companies doing government bids. Here is part of the internal product release information sheet on that release: Release 2.1 is both POSIX 1003.1 and FIPS (Federal Information Processing Standard) 151-1 compliant. The OS also features Job Control and the Software Development System contains a special library intended for those who want to write applications that are POSIX compliant at the source level. The OS and the utilities will retain their current behaviour in order to maintain SVID (System V Standard Interface Definition) compliance. Packaged product will be available only to system integrators who need a POSIX and/or C2 secure system for government bids. 386/ix Security Release 1.1 will be a mandatory extension for the Release 2.1 OS. This product, when loaded while installing 386/ix release 2.1, will turn the 386/ix Operating System into a C2 secure system. 386/ix Security will not work on OS Release 2.0.2. For release 2.2 of 386/ix, a new version of this package will be required. More information about this release can be obtained from the Federal Systems Sales office: (703) 847 4228 Apologies to those inconvenienced by not receiving information about this limited distribution upgrade. ....
guy@auspex.auspex.com (Guy Harris) (12/07/89)
>Also ksh is part of Sys V.4 so you will see it sooner or later 8-).
So is "csh", for what it's worth (SunOS 4.1-derived, which means
4.3BSD-derived, not crufty old Xenix/ancient BSD-derived). (Given a
system with both, I'd personally use "ksh", but, just like editors, it's
99% an issue of taste and 1% an issue of objective advantages and
disadvantages, I suspect....)