rbj@icst-cmr.arpa (Root Boy Jim) (03/16/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> SVR3.0 is the first AT&T UNIX system release that I would rate as technically the equal of, or superior to, 4.nBSD on all major counts. The *first* one? I thought you were a believer years ago. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Isn't this my STOP?!
lm@arizona.edu (Larry McVoy) (03/16/88)
In article <12414@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > > From: Doug Gwyn <gwyn@brl-smoke.arpa> > > SVR3.0 is the first AT&T UNIX system release that I would rate as > technically the equal of, or superior to, 4.nBSD on all major counts. > >The *first* one? I thought you were a believer years ago. I missed the opener on this one; are you really serious, Doug? What do you mean by technically superior? A nicer implementation of the disk sched alg? Or a more reasonable computing environ as defined by the system call interface? Or something else, somewhere inbetween? Just curious, -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
In article <4361@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >> From: Doug Gwyn <gwyn@brl-smoke.arpa> >> SVR3.0 is the first AT&T UNIX system release that I would rate as >> technically the equal of, or superior to, 4.nBSD on all major counts. >I missed the opener on this one; are you really serious, Doug? Of course I'm serious. Consider: modular region-based virtual memory manager shared libraries file system switch transparent networked file system STREAMS network interface library record locking reliable signals windowing utilities HDB UUCP in addition to things already found in earlier releases of UNIX System V: usable system interface specification document faster, more complete standard C library somewhat better C compiler COFF FIFOs terminfo shell layers shared memory semaphores message passing process locking vendor support Berkeley's system has equivalents to some of these, no equivalents to others, and includes some things like LISP (not Common LISP) and rogue not found in AT&T's system. Berkeley's terminal handler is nicer- looking to the user but not as good for the application programmer. BSD-style job control is somewhat nicer for the user than shell layers, but this is not available in their Bourne shell. And so on... When we acquired our first VAX, we had to decide which flavor of UNIX to run on it. We identified three reasons to prefer the Berkeley variant: TCP/IP network support virtual memory for large applications compatibility for importing sources from other sites, particularly from the Alpha_1 project (which for example relied heavily on flexnames). The only one of these that might still be a factor is the latter, but our level of concern with importing a single specific application is much lower now, and in any case that is not a matter of technical superiority. Portability considerations are much more important, and UNIX System V is much closer to meeting useful standards than 4BSD.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/21/88)
In article <7499@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: [arguments why SVR3 is as good as 4.3BSD on all counts] Here are some things I see under 4.3BSD that I don't see under SVR3, unless they are either not documented or I somehow missed them. I'm comparing the full packages, not just the kernels. job control (stop/restart jobs, get status of jobs and know one is stopped for tty input) intelligent echoing to screen (SVR3 seems to blindly echo everything or nothing, can mess up screen, won't redraw partially-typed line, won't align tabs on char erase) intelligent mail handling -- sendmail, MH, biff, vacation "script" for recording terminal session "ul" for underlining when printing on various printers one complete KWIC index for all manuals symbolic links long filenames a user can be in multiple groups user information lookup ("finger", "lastcomm", "last") UUCP over TCP/IP links support for multiple command interpreters with #! as first line of script dbm library--fast /etc/passwd and /usr/lib/news/history access etc. context diffs from diff smarter, friendlier "at" program A note about UUCP: Although theoretically HDB UUCP is the equal of the 4.3BSD UUCP, I constantly hear horror stories on Usenet about how HDB UUCP doesn't work right for one reason or another. I don't hear quite as many horror stories about 4.3BSD UUCP, probably because it has been better integrated into the rest of the system and has had time to stabilize. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
bzs@bu-cs.BU.EDU (Barry Shein) (03/21/88)
Doug, I tend to agree with you that SVR3 has really pushed SystemV ahead and is promising to contribute a lot to the Unix community and improve all variants of Unix as they move towards a common standard. Other than job control and the user's view of the terminal handler (both of which are probably reasonably bridged with ksh, so the Bourne shell's lack is probably becoming moot) I'd still have to point out the System V file system which is vastly inferior to BSD's rework in some non-ignorable ways. I don't see that implementing the BSD file system under SysV would disrupt much anything either from a user's point of view (it just gives them long file names) or the system's (it just speeds up access, improves integrity a lot and reduces fragmentation to the point of becoming a non-issue.) What's the issue here? Just a matter of time or is there some real objection to adopting the BSD file system? Anyone have a handle on this? Similarly that should immediately give SysV dump and restore and other utilities (eg. a better fsck), things that would vastly improve the operational aspects which are very important in this day and age of people like us having to manage over 100 systems and needing good, reliable operational tools. Finc etc just don't cut it (do I need to explain why?) Also, adopting a standard and top-notch TCP/IP implementation with several of the needed utilities bundled in is critical to many of us and would force our hand if lacking. I would have to suspect that the ATT/SUN merger is going to resolve these issues, so I guess we wait just a little longer (heck, it's been 12 years now I've been waiting for all this to happen.) -Barry Shein, Boston University
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)
In article <20768@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >What's the issue here? Just a matter of time or is there some real >objection to adopting the BSD file system? I don't think there is any real problem with providing the 4.2BSD style of disk file system in UNIX System V via the file system switch. Implementations that currently support the old-style disk file system will probably continue to do so in order to avoid forcing the customer to rearrange existing disks when upgrading. Note that several UNIX System V implementations already use a different style of disk file system; for example, Silicon Graphics has an extent-based scheme. The nice thing about the FSS is that it provides a relatively painless way to migrate from one style to another, or to provide a special format, e.g. real-time data files, which may have different needs from general timesharing files. My evaluation of the 4.2BSD cluster approach is that it works best if the processor has cycles to spare, and may not be a good choice for small systems. >Also, adopting a standard and top-notch TCP/IP implementation with >several of the needed utilities bundled in is critical to many of >us and would force our hand if lacking. Unfortunately, the implementation you probably have in mind is tightly coupled to sockets. Wollongong developed a STREAMS-based TCP/IP for AT&T; I don't know how good it is but there is no a priori reason that a STREAMS implementation couldn't be as good as one based on sockets. One thing that a totally-STREAMS version of UNIX System V would achieve is transparency over "pseudo-tty" channels, so that terminal ioctls would work right. I've needed this many times on our 4.2BSD systems and have had to punt on it. >I would have to suspect that the ATT/SUN merger is going to resolve >these issues... Certainly most of us hope so. AT&T is definitely evolving UNIX far faster than they used to.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)
In article <2423@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <7499@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) >writes: >[arguments why SVR3 is as good as 4.3BSD on all counts] I said on all MAJOR counts. There are lots of small items on each system that the other could benefit from. I named some, you named some, and there are lots more. > job control (stop/restart jobs, get status of jobs and know > one is stopped for tty input) As I mentioned, the System V equivalent is "shell layers", which is not quite as nice from the user's perspective but it sure disrupts the system internals less than the 4BSD approach (which has been revised one way or another at least five times that I am aware of and still occasionally causes us problems). The 4BSD scheme for various reasons does not readily fit into System V; I think the scheme worked out for IEEE Std 1003.1 will probably be included in a future release of UNIX System V. > intelligent echoing to screen (SVR3 seems to blindly echo > everything or nothing, can mess up screen, won't redraw > partially-typed line, won't align tabs on char erase) I mentioned this. There is no particular reason most of these features could not be added to the System V terminal handler, and it would be useful if they were. Except for the user interface, the System V terminal handler is clearly superior for most applications, as the Berkeley developers have acknowledged; I think they've developed a POSIX-compatible replacement terminal handler but I don't know how you can get your hands on it. > intelligent mail handling -- sendmail, MH, biff, vacation Doesn't matter to me; we use MMDF, $MAILPATH, sysmon, etc. > "script" for recording terminal session "Script" screws up the application running under it sometimes. It could be implemented almost trivially with STREAMS. Somebody should do so. > "ul" for underlining when printing on various printers Another one we don't use. MDQS's line-printer spooler does a much better job, and our other printers know how to underline. > one complete KWIC index for all manuals That might be handy, but UNIX System V is intended to be distributed as a set of packages, many of them optional, so it is hard to see how to prepare such a merged index that would be maximally useful. > symbolic links Probably coming in a future release. As discussed previously, they do bring some problems, but are nonetheless probably worth having. > long filenames This is tied to the disk filesystem format, and unlike Berkeley, AT&T chose not to invalidate their customer's existing filesystems. However, the FSS now provides a mechanism for graceful migration to an improved filesystem in which longer names would be possible. I don't know if they're working on it, but undoubtedly it would come out of the AT&T/Sun merged-UNIX project. > a user can be in multiple groups Probably coming in a future release. I hope they fixed the Berkeley bug that kept me from logging in when the system administrator added me to my ninth group! > user information lookup ("finger", "lastcomm", "last") I don't use these, so no comment. > UUCP over TCP/IP links Supported by UNIX System V, last I heard. > support for multiple command interpreters with #! as first line of script This is totally unnecessary; if all scripts are executed by a Bourne shell, it is easy to simulate the #! feature, in fact to generalize on it. Nevertheless I think AT&T may be adding this kludge to the kernel exec code in a future release, alas. > dbm library--fast /etc/passwd and /usr/lib/news/history access etc. There are other ways to speed up /etc/passwd access that don't have the drawback of maintaining a separate index file. A good, standard ISAM would be useful, but dbm ain't it. > context diffs from diff This could be added easily enough, and I considered adding it to my System V emulation package but decided it wasn't particularly useful. > smarter, friendlier "at" program Another thing I don't care for; we use MDQS "batch" facilities. System V has user (non-superuser) crontab support that seems nice. >A note about UUCP: Although theoretically HDB UUCP is the equal of the >4.3BSD UUCP, ... Wrong; theoretically it is superior to 4.3BSD UUCP.
kutz@bgsuvax.UUCP (Kenneth Kutz) (03/22/88)
In article <2423@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > Here are some things I see under 4.3BSD that I don't see under SVR3, > unless they are either not documented or I somehow missed them. I'm > comparing the full packages, not just the kernels. > > job control (stop/restart jobs, get status of jobs and know > one is stopped for tty input) > intelligent echoing to screen (SVR3 seems to blindly echo > everything or nothing, can mess up screen, won't redraw > partially-typed line, won't align tabs on char erase) > intelligent mail handling -- sendmail, MH, biff, vacation > "script" for recording terminal session > "ul" for underlining when printing on various printers > one complete KWIC index for all manuals > symbolic links > long filenames > a user can be in multiple groups > user information lookup ("finger", "lastcomm", "last") > UUCP over TCP/IP links > support for multiple command interpreters with #! as first line of script > dbm library--fast /etc/passwd and /usr/lib/news/history access etc. > context diffs from diff > smarter, friendlier "at" program > > A note about UUCP: Although theoretically HDB UUCP is the equal of the > 4.3BSD UUCP, I constantly hear horror stories on Usenet about how HDB > UUCP doesn't work right for one reason or another. I don't hear quite > as many horror stories about 4.3BSD UUCP, probably because it has been > better integrated into the rest of the system and has had time to > stabilize. I've recently come from a System V environment to a BSD 4.3 environment. I've kept a list of some of the differences I've found. Some may seem insignificant but never-the-less I've included them for completeness. These are in no particular order other than the order which I noticed differences from switching environments. I've grown to like BSD quite a bit since my "switch". Bourne shell builtin "exit": Sys V: From the shell prompt, will return the user to the login prompt BSD : Does not log the user out. System file "/etc/inittab": Sys V: This file is used in place of "/etc/ttys" and "/etc/ttytype" of BSD. I consider "/etc/inittab" an improvement since it is single file with all the terminal information in it. Included is the ability to define "run levels" which allow a System Administrator to restrict who can log in when and where very easily. For example if you want to set your system up so that no local logins are allow between 8:00 PM and 7:00 AM you execute /etc/init with appropriate run level as an option at 8:00 PM. Going Single User: Sys V: "/etc/single" - Shell script to go single user by switching run levels. BSD : Shutdown first and then boot single user. Leaves "/etc/mtab" thinking there are file systems mounted. File system debugging: Sys V: "/etc/fsdb" - File system debugging tool. Something I have missed. BSD : No equivalent (that I have found yet). "echo": Sys V: Cursor control supported such as backspacing (\b), cursor up (\v), tab (\t), no new line (\c). BSD : Cursor control only by embedding the actual character (such as tab) into the string to echo, with the exception of no new line (-n option) System wide user start up script: Sys V: "/etc/profile" is a system wide start up script that gets executed for every user that logs in. BSD : Set up the administrator how he sees fit. No standard method. Accessing terminal capabilities: Sys V: "tput" accesses the terminfo database for terminal capabilities such as bold, underline, blinking etc. BSD : No standard unix utility (that I'm aware of) Getty definitions: Sys V: /etc/gettydefs BSD : /etc/gettytab Bourne shell: Sys V: provides a variable called "CDPATH". When set is used to allow a user to cd to paths in this variable without using the entire pathname but rather just the destination directory. BSD : Various shells from the net that provide wonderful things (tcsh, newcsh). I haven't used the korn shell yet. Combination of ps and who Sys V: /etc/whodo BSD : "w" - Much better since info for a user is on single line, more readable. "vi": Sys V: provides the variable "showmode" which will use the last row on the screen to show the vi user whether he/she is in "INSERT MODE" "REPLACE MODE", or "COMMAND MODE". Can be executed so set this automatically with "vedit". Excellent for vi beginners. BSD : Not there. "cal" Sys V: cal without any argument defaults to the current month BSD : must provide argument "find" Sys V: Does not keep a weekly tree structure in a file. BSD : Keeps the directory tree structure in a file so that when find is executed without any arguments it goes to this file for a much faster picture. Shutdown: Sys V: Provides a bourne shell script (/etc/shutdown) which will perform common shutdown functions (/etc/wall, /etc/umount, killing process id's etc.). Unmounting file systems at shutdown time makes a lot of sense. When you come back up to single-user it will give a true picture of what is mounted in /etc/mtab. BSD : shutdown - C program "date" Sys V: Many format options such as MM/DD/YY. Nice for scripts. BSD : One format "at" Sys V: Option to display queued jobs for "at" to run. BSD : Haven't found the equivalent command yet. Column/field extraction: Sys V: "cut": Used to cut out columns from a table or fields from a line of data. Very useful in scripts is easier and faster than awk. Our system: Pulled it off the AT&T Source tape :-) "ls" Sys V: "ls -l" gives the UID and user name BSD : Just user name Rahul points out some very significant gains BSD has on Sys V. Both have their merits. I am quite hooked on those things Rahul listed though. (I do miss /etc/fsdb and /etc/inittab). -- -------------------------------------------------------------------- Kenneth J. Kutz CSNET kutz@bgsu.edu UUCP ...!osu-cis!bgsuvax!kutz Disclaimer: Opinions expressed are my own and not of my employer's --------------------------------------------------------------------
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/22/88)
One of the problems with merging SysV and BSD is the long names. If
names are made > 14 char buffers in existing SysV programs break, if 14
is used some BSD things will break. I must confess I think BSD names are
too much of a good thing... do we really need names longer than the data
in the file? Most sites trim the filenames to either 1k or something
smaller, and I doubt that 1% of a ll files in the world have names
longer than some reasonable size, such as 64 or even 32 characters.
Other than that the change in filesystem should be invlisble to the
user. I find that BSD programs do non-intuitive things with symbolic
links about as often as I wish I had them on Sysv, so that's a wash.
Please reread the 211 articles posted as "symbolic links are a botch"
before posting any more on the topic. It has been beaten to a pulp and
there is serious disagreement. I suspect that some form of link will
appear, but not the current BSD version.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mebzs@bu-cs.BU.EDU (Barry Shein) (03/22/88)
Doug, Yup, I agree, the 4.x file system as an option via the file system switch, job control and a decent TCP/IP implementation via Streams and a lot of the merger would be accomplished. I would imagine that most of the current socket interface could be emulated (at worst) thru a library using TLI. Someone would have to study the semantics but I will boldly say* that the socket interface in application code is reminiscent of the terminal ioctl stuff, it usually accounts for a very small part of the application's code and usually in a very cliche'd manner at startup which wouldn't be too painful in most cases to rework (not the greatest thing to do with one's time, but I can't imagine it's more than a couple of hours work in almost all cases, given a reasonable substitute, the goal of obtaining a full-duplex file descriptor attached to the remote process is straightforward enough, how you got there shouldn't be too critical.) Obviously the hard cases would have to be looked at (eg. various socketopts.) I believe it's not so much an issue of the possibilities based upon the proposed interface but rather how good the provided implementations provided end up. Yup, looks rosy, so much for the Gwyn/Shein Sysv/BSD wars...:-) -Barry Shein, Boston University * I've been meaning to never split infinitives.
bzs@bu-cs.BU.EDU (Barry Shein) (03/22/88)
Well, I would agree with both Doug and Rahul on those point-by-points, they seem to fall into two cases, those that are effectively provided already or soon to be and those which really are applications which could be ported (eg. finger, we had our finger running under SVR1, I don't remember any great pain in moving it over.) One point that has been perhaps missed is that a critical reason for wanting the 4BSD file system is, besides performance, integrity, backups etc, semantics across remote file systems. What exactly happens when you copy a file with a long name to a SysV remote file system? I've heard truncation (that's no good, could conflict or cause various problems) and I've heard error returns (also less than desireable.) The reverse shouldn't be true, so the option of running all 4BSD file systems would be very desireable. Most of the other points seem non-important (job control is important, but there's no reason dbm couldn't be ported, for example, it's user level, I'm sure it's been ported, and providing a good ISAM etc library and migrating to it would be a good idea, as long as no one makes the mistake other vendors did and shoves it in the kernel or starts making utilities use it that have no business using it, that is, most of them, I remember running RUNOFF on VMS once and saving the output to a file to edit a few things only to find that EDT would not edit a RUNOFF printer format file because it was stored in some wierd record format! Outrageous, I won't even tell my IBM horror stories where a "cp" command is non-existant for this reason.) I'm sure the Unix community has more common sense than that. -Barry Shein, Boston University
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/22/88)
In article <10025@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: | | I must confess I think BSD names are |too much of a good thing... do we really need names longer than the data |in the file? Most sites trim the filenames to either 1k or something |smaller, and I doubt that 1% of a ll files in the world have names |longer than some reasonable size, such as 64 or even 32 characters. The software I use to archive USENET articles would be completely unmanageable if limited to 14 character names. Each file is stored under the message ID. If I had to truncate the filenames, then I would have several articles trying to occuply the same name. Any suggestions to hash the message ID into some 14 character encoding will be cheerfully met with a flame thrower. :-) I also use filenames as keywords. For instance, I have an archive of accounting reports, where the filename is of the format <machine>-<report>.<Month>_date-<AMorPM> I use the shell characters as a first level grep, allowing constructs like grep pattern *patterna*patternb* I also don't have to worry about creating backup files by adding a ".orig" to the original filename. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
jbuck@epimass.EPI.COM (Joe Buck) (03/23/88)
In article <7514@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2423@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >> [ what's missing from Sys V ] >> job control (stop/restart jobs, get status of jobs and know >> one is stopped for tty input) > >As I mentioned, the System V equivalent is "shell layers", which is >not quite as nice from the user's perspective but it sure disrupts the >system internals less than the 4BSD approach. shl isn't anywhere NEAR as nice from the user's perspective as job control and isn't an adequate replacement. This is the number one reason that I, and a vast number of other users, will not consider a Sys V environment. Windows are also not an adequate replacement; I use both windows and job control. You can explain why I'm technically foolish to have this attitude. But I use it and I like it. If the internal implementation is inelegant, that's unfortunate; I'd tolerate slight changes in the user interface if it would result in cleaner internals, but we do the internals to get the nice user interface, not the other way around! >> support for multiple command interpreters with #! as first line of script > >This is totally unnecessary; if all scripts are executed by a Bourne >shell, it is easy to simulate the #! feature, in fact to generalize >on it. Nevertheless I think AT&T may be adding this kludge to the >kernel exec code in a future release, alas. The reason Dennis Ritchie invented #! (that's right, it's not a Berkeleyism) was for the Pascal p-code interpreter. It wasn't originally designed for csh shell scripts at all! It makes programs like Larry Wall's "perl" much more wonderful as well. While it's unsafe to write a set-uid shell script, it's perfectly safe to write a set-uid perl script, and this can only be done with #!. There are things #! gives you that you can't get any other way, and implementing it isn't ugly at all -- it simply generalizes the concept of the "magic number" at the beginning of an executable. csh is not the reason for #!. >> dbm library--fast /etc/passwd and /usr/lib/news/history access etc. > >There are other ways to speed up /etc/passwd access that don't have >the drawback of maintaining a separate index file. A good, standard >ISAM would be useful, but dbm ain't it. Here I agree with you. dbm sucks, in many ways. I was extremely peturbed once when I found you can't have two dbm databases open in the same program -- I ended up forking off a second program to do part of the job. >> context diffs from diff > >This could be added easily enough, and I considered adding it to my >System V emulation package but decided it wasn't particularly useful. Context diffs are the safest way to transmit small source code changes in a distributed environment, and are easier both for programs and for people to deal with. Oh, by the way, Sys V versions of many utilities are vastly superior: lint and make especially come to mind. -- - Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
lm@arizona.edu (Larry McVoy) (03/23/88)
In article <7511@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Unfortunately, the implementation you probably have in mind is >tightly coupled to sockets. Wollongong developed a STREAMS-based >TCP/IP for AT&T; I don't know how good it is but there is no a >priori reason that a STREAMS implementation couldn't be as good as >one based on sockets. It is my personal belief that streams was intended as a _slow_ terminal "virtualization" (Padlipsky would be proud) mechanism. As such, one should probably think carefully about the performance aspects of implementing high bandwidth drivers that use streams. One could (I have seen it) suggest that all drivers talk through streams interfaces. Seems like a nice idea (modularity being the buzzword that comes to mind) until you start counting how many times you say "bcopy(src, dest, len)". This might be a moot point when we have infinitely fast CPU's and memories :-) (It should be obvious but I'll drive it home: the streams code that I've seen copies the data out of the upper level buffer and then into the lower level buffer [assuming "downward" movement]. The copying dominates the time spent in the streams drivers. If streams can handle imbedded pointers in their data then my comments are meaningless.) -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
rick@seismo.CSS.GOV (Rick Adams) (03/23/88)
In my biased opinion, HDB has 3 major advantages over the 4.3bsd uucp. 1) The Permissions file 2) The Dialers file 3) Subdirectories per site. 4.3 aleady has almost all of the other good ideas the HDB did. The subdirecories are coming soon. The Dialers are coming soon. The Permissions file is coming some day. It is my stated goal to make the 4.3bsd uucp do everything HDB does without using any of the HDB code. ---rick
ekrell@hector.UUCP (Eduardo Krell) (03/23/88)
In article <4441@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >(It should be obvious but I'll drive it home: the streams code that I've >seen copies the data out of the upper level buffer and then into the >lower level buffer [assuming "downward" movement]. The copying dominates >the time spent in the streams drivers. If streams can handle imbedded >pointers in their data then my comments are meaningless.) Well, now. The streams modules that I've seen so far avoid copying data as much as possible. Passing a message up or downstream is often accomplished by just passing pointers to the data. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
lm@arizona.edu (Larry McVoy) (03/24/88)
In article <10179@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >In article <4441@megaron.arizona.edu> I said: > >>(It should be obvious but I'll drive it home: the streams code that I've >>seen copies the data out of the upper level buffer and then into the > >Well, now. The streams modules that I've seen so far avoid copying data >as much as possible. Passing a message up or downstream is often >accomplished by just passing pointers to the data. Several people have pointed this out to me. It seems that I have been exposed to some fairly poorly written streams code and it is that code, not streams, that is brain-damaged. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
les@chinet.UUCP (Leslie Mikesell) (03/24/88)
In article <44269@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: > >In my biased opinion, HDB has 3 major advantages over the 4.3bsd uucp. > > 1) The Permissions file > 2) The Dialers file > 3) Subdirectories per site. SysVr3.1 (on the AT&T 3b2 anyway) has a Sysfiles file that allows use of multiple Systems/Devices/Dialers files and specification of which files to use for which service (uucp/cu..). This is nice where alternate network connections exist (uucico can talk directly over a STREAMS link where cu needs a real or pseudo tty). Also the dialer (at last) can work reasonably with carrier detect on the modems. Now if only the C library dial() routine would work with this good stuff..... Les Mikesell
jimb@mitisft.Convergent.COM (Jim Bennett) (03/24/88)
In article <4441@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: > (It should be obvious but I'll drive it home: the streams code that I've > seen copies the data out of the upper level buffer and then into the > lower level buffer [assuming "downward" movement]. The copying dominates > the time spent in the streams drivers. If streams can handle imbedded > pointers in their data then my comments are meaningless.) In general, it is not necessary to copy data in order to pass it downstream (or upstream). STREAMS comes with a set of procedures for pulling message blocks from queues, adding them to queues, linking messages together, etc. The only reasons I can think of why data might need to be physically copied: If message boundaries need to be changed, or if the data needs to be processed in a way that causes data expansion and the current streams buffer overflows. More to the point: At Convergent we have converted the 4.3 BSD TCP/IP from a sockets interface to a STREAMS interface and measured no loss in performance. Jim Bennett Convergent Technologies ...!uunet!pyramid!ctnews!mitisft!jimb
narayan@tandem.UUCP (Narayan Mohanram) (03/24/88)
In article <4441@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >you start counting how many times you say "bcopy(src, dest, len)". This >might be a moot point when we have infinitely fast CPU's and memories :-) > >(It should be obvious but I'll drive it home: the streams code that I've >seen copies the data out of the upper level buffer and then into the >lower level buffer [assuming "downward" movement]. The copying dominates >the time spent in the streams drivers. If streams can handle imbedded >pointers in their data then my comments are meaningless.) >-- >Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm This is entirely wrong. Each layer just passes mblks down. There is no copying of data once it is copied in from user code to kernel space into and mblk. Each layer then just tacks on its header to the front of the chain of mblk's. This is finally dma'd out to the net. If the driver is capable of scattered IO then dma is normally done from the chain of mblk's. Narayan Mohanram (narayan@ati.tis.llnl.GOV)
kre@munnari.oz (Robert Elz) (03/24/88)
In article <7514@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > > job control (stop/restart jobs, get status of jobs and know > > one is stopped for tty input) > > As I mentioned, the System V equivalent is "shell layers", Doug, you know better than that, shl is at attempt at windows for asr33's and as such has some advantages and some disadvantages over the bsd use of job control to attempt to force windows onto asr33's and lookalikes. But that's not job control. Job control is when I notice that /foobar is 98% full, and some cretin has a job running that's half way through extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control. (Then "kill -CONT <pid>" later if I can manage to scavenge enough space to allow the tar to continue. Nb: it matters little if the cretin is me or not in these circumstances). > > long filenames > > This is tied to the disk filesystem format, Well, kind of, filenames are tied to the directory format, which has nothing to do with the rest of the filesystem format (after all, directories are just files, in both systems). > > support for multiple command interpreters with #! as first line of script > > This is totally unnecessary; This is so much drivel its not even worth commenting on. kre
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/25/88)
In article <2050@munnari.oz> kre@munnari.oz (Robert Elz) writes: >But that's not job control. Job control is when I notice that /foobar >is 98% full, and some cretin has a job running that's half way through >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control. Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc. Running under "shl", there is a keyboard-generated signal similar to TSTP and analogs of fg, bg, etc. That is why I said that "shl" is the AT&T UNIX equivalent of 4BSD job control. As both of us have said, each approach has advantages and disadvantages w.r.t. the other. >(after all, directories are just files, in both systems). This isn't really true. The kernel's file-system code knows how to deal with specific directory formats. Similarly for NFS directory access. >This is so much drivel its not even worth commenting on. A refutation of my argument against #! would have been useful.
gwp@hcx3.SSD.HARRIS.COM (03/25/88)
Written 12:00 pm Mar 21, 1988 by davidsen@steinmetz (bill davidsen) > I must confess I think BSD names are > too much of a good thing... do we really need names longer than the data > in the file? Most sites trim the filenames to either 1k or something > smaller, and I doubt that 1% of all files in the world have names > longer than some reasonable size, such as 64 or even 32 characters. I don't understand this division between a files "name" and it's "data". In many cases (lock files, status files etc.) the files name _is_ its' data, i.e. the name (and possibly its' permission) is just about the only thing that is relevant to your application. From an implementation standpoint it's natural to think of them as being different, but from a conceptual standpoint there is no difference between a files "name" and its' "data", it's _all_ data (only some of it is used for different things). Gil Pilz | Harris Computer Systems Div. | gwp@ssd.harris.com
John_M@spectrix.UUCP (John Macdonald) (03/25/88)
In article <7514@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >[response to:] >In article <2423@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>[lots of detail differences where BSD4.3 is "preferred" than SVR3.0] > ... >[excellent response to most points] > >> support for multiple command interpreters with #! as first line of script > >This is totally unnecessary; if all scripts are executed by a Bourne >shell, it is easy to simulate the #! feature, in fact to generalize >on it. Nevertheless I think AT&T may be adding this kludge to the >kernel exec code in a future release, alas. I think you are going a bit too far here - it is easy to get sh to invoke another interpreter on a script, but not allowing the full capability that #! provides (unless I'm missing some clever sh trick). In particular, I don't think you can cause the command "file args" to effectively invoke "interp [path/]file args" and keep the name of the file available to the interpreter (for $0 type use). If $0 is not needed, of course, the sh script can just execute the interpreter with the rest of the script sent to its standard input. (Chip Salzenburg (sp?) recently provided a neat hack to allow perl programs to be executed either by sh or directly by perl, but it depended upon clever use of a statement that turns out to be an exec in sh, but a no-op in perl.) I can recall ("was it really?" 15 years ago) the idea that the shell was simply a user program that anyone could replace was referenced as demonstrating the simplicity and elegance of the design of Unix. Unfortunately, this idea breaks down (slightly) because scripts are invoked by the shell, and there was no way to specify *which* shell should be used. (This is similar to the fact that a compiled program can usually only run on one type of hardware. However, that has not been a pressing problem for most of us and COFF does provide a mechanism for specifying which hardware it must run on, even if very few Unix implementations currently allow it to be acted upon.) Using #! is definitely a kludge. Exec is neccessarily a function of the kernel, but the method of invoking it should be under the user's control. Why should the searchpath not be available when the indirection to the interpreter is being done? Because it is in the kernel and search is done by the shell, so the kernel #! processing doesn't know about it. Providing setuid on scripts is a huge security risk, despite its great convenience. Using #! is an easy solution in most regards. It is consistent with the BSD world and mostly solves the problem. The *right* alternative (as I see it) is to put #! checking into sh (and csh, ksh, and any other program that doesn't just use the system("command") function to figure it all out) as well as into the system library routine. This would allow using the search path both for finding the script and the interpreter (and the interpreter's interpreter...). And it would get rid of the current situation where all interpreters are equal, except sh which is a bit more equal. -- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
friedl@vsi.UUCP (Stephen J. Friedl) (03/25/88)
In article <7542@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: < In article <2050@munnari.oz> kre@munnari.oz (Robert Elz) writes: < >But that's not job control. Job control is when I notice that /foobar < >is 98% full, and some cretin has a job running that's half way through < >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control. < < Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc. < Running under "shl", there is a keyboard-generated signal similar to < TSTP and analogs of fg, bg, etc. That is why I said that "shl" is < the AT&T UNIX equivalent of 4BSD job control. As both of us have < said, each approach has advantages and disadvantages w.r.t. the other. Shell layers do not involve any kind of signals. When ^Z is hit, the sxt driver gives control back to channel zero, which is usually the layer manager (here, /usr/bin/shl). When a user command to shl asks that a child layer be run, the layer manager issues an ioctl to the multiplexor to give control to the child's layer (there is no SIGCONT). One result of this implementation is that I know of no way for a layer to suspend itself, certainly not with signals (if anybody else knows how I would love to hear it). Nevertheless it is not incorrect to equate job-control with shell layers in a general kind of way -- kre's way just may be more general than mine :-). -- Steve Friedl V-Systems, Inc. *Hi Mom* friedl@vsi.com {uunet,attmail,ihnp4}!vsi!friedl
jbuck@epimass.EPI.COM (Joe Buck) (03/26/88)
In article <2050@munnari.oz> kre@munnari.oz (Robert Elz) writes: >>But that's not job control. Job control is when I notice that /foobar >>is 98% full, and some cretin has a job running that's half way through >>extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control. In article <7542@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc. >Running under "shl", there is a keyboard-generated signal similar to >TSTP and analogs of fg, bg, etc. That is why I said that "shl" is >the AT&T UNIX equivalent of 4BSD job control. As both of us have >said, each approach has advantages and disadvantages w.r.t. the other. Correct me if I'm wrong, Doug, but I thought in shl you can't stop a process that isn't producing terminal output, so in Robert's example you'd have no hope of stopping the tar job except by killing it. . . . . -- - Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <445@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >Shell layers do not involve any kind of signals. Oops. sorry -- you're right; there is a "magic" key but it is handled by the multiplexor and doesn't generate a signal.
lm@arizona.edu (Larry McVoy) (03/26/88)
In article <445@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >Shell layers do not involve any kind of signals. When ^Z is hit, >the sxt driver gives control back to channel zero, which is >usually the layer manager (here, /usr/bin/shl). When a user Which means you could emulate shell layers with pty's. All that is going is the master side has several slave sides and switches between them. It is a far cry from job control. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <2038@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >Correct me if I'm wrong, Doug, but I thought in shl you can't stop a >process that isn't producing terminal output, ... I believe that's correct, due to having the sxt terminal multiplexor doing the actual work. I didn't say "shl" was exactly the same or even as useful as BSD-style job control, just that it was the nearest AT&T UNIX equivalent. I suspect you'll see BSD-style (signal-driven) job control in some future AT&T UNIX, especially given the AT&T/Sun merged-UNIX project. Commercial UNIX continues to accrete features...
sys1@anl-mcs.arpa (Systems Programmer) (03/26/88)
In UNIX-WIZARDS Digest V4#191 dhesi@bsu-cs.uucp (Rahul Dhesi) writes: >Here are some things I see under 4.3BSD that I don't see under SVR3, >unless they are either not documented or I somehow missed them. I'm >comparing the full packages, not just the kernels. > > [long surrounding list of other nice things deleted --SJB] > one complete KWIC index for all manuals I like the rest of the list, but this item is bogus. Of the first *ten* items I looked up in that index, *not a single one* was at (or even near) the place listed for it in the index. I guess some days I'm a slow learner :- | Scott Bennett Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * uucp: {decvax,ihnp4,ucbvax}!anlams!niuvax!sys1 * * BITNET: A01SJB1@NIU * *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++* * "Good government obtains when those who are near are made happy, * * and those who are far off are attracted." --Confucius * **********************************************************************
robert@pvab.pvab.se (Robert Claeson) (03/28/88)
In article <4109@vdsvax.steinmetz.ge.com>, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: > The software I use to archive USENET articles would be completely > unmanageable if limited to 14 character names. How long can a filename actually be in SVR3.x? Some says 14 char's, some says 20 char's whilst others says 32.
rbj@icst-cmr.arpa (Root Boy Jim) (03/29/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> > "script" for recording terminal session "Script" screws up the application running under it sometimes. It could be implemented almost trivially with STREAMS. Somebody should do so. Interesting. Please elaborate. > one complete KWIC index for all manuals That might be handy, but UNIX System V is intended to be distributed as a set of packages, many of them optional, so it is hard to see how to prepare such a merged index that would be maximally useful. Index everything, with caveats that certain packages may not be there. Then, at least we know what we're missing. Free Advertising :-) > a user can be in multiple groups Probably coming in a future release. I hope they fixed the Berkeley bug that kept me from logging in when the system administrator added me to my ninth group! Ouch! I've been bit by this as well. Another bogus limit! > support for multiple command interpreters with #! as first line of script This is totally unnecessary; if all scripts are executed by a Bourne shell, it is easy to simulate the #! feature, in fact to generalize on it. Nevertheless I think AT&T may be adding this kludge to the kernel exec code in a future release, alas. Given that there are and will be multiple shells on a given system, I think this is critical. It is far better than requiring each shell to look at the first line and decide if it's for `me', the `other' shell, or some lesser known processor. In short, it is A Good Thing for an interpreted script to be able to communicate who it wants to be interpreted by. Besides, who needs all those redundant shell processes cluttering up the system on simple scripts. Unfortunately, the current implementation is rather limited; only one `extra' argument, and `$0' is forced in there as well. This should be expanded upon and generalized. `More +2' is cute, but I can't think of many other uses the way it is now. > context diffs from diff This could be added easily enough, and I considered adding it to my System V emulation package but decided it wasn't particularly useful. True, but they are useful for patch files. What they really need to do is add diff -r and get rid of dircmp. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Hey, wait a minute!! I want a divorce!!.. you're not Clint Eastwood!!
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/29/88)
In article <12690@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > From: Doug Gwyn <gwyn@brl-smoke.arpa> > > "script" for recording terminal session > "Script" screws up the application running under it sometimes. It > could be implemented almost trivially with STREAMS. Somebody should > do so. >Interesting. Please elaborate. Elaborate on what? The screw-up is that certain operations do not work right on ptys. A streams-based implementation of "script" was sent to me by Norman Wilson; it consisted of a few lines of shell script. The only thing not working was signal propagation to the correct process group, because the Bourne shell doesn't have a way to manipulate that. A translation to C would also be only a few lines and could solve the signal problem.
davy@ea.ecn.purdue.edu (Dave Curry) (03/30/88)
In article <7581@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <12690@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >> From: Doug Gwyn <gwyn@brl-smoke.arpa> >> > "script" for recording terminal session >> "Script" screws up the application running under it sometimes. It >> could be implemented almost trivially with STREAMS. Somebody should >> do so. >>Interesting. Please elaborate. > >Elaborate on what? The screw-up is that certain operations do not >work right on ptys. Elaborate on that, please. *Which* operations? I don't claim there aren't any, but I haven't seen anything screw up in "script" in a long, long time. >The only thing not working was signal propagation to the >correct process group, because the Bourne shell doesn't have a way >to manipulate that. A translation to C would also be only a few >lines and could solve the signal problem. That's a pretty big "only". It is nice to know that you can do it in a few lines, though. Simplification is always good. Note however that "script" is hardly as short as it could be; I have written a clone of it in about 100 lines of code including variable declarations. --Dave Curry Purdue University Engineering Computer Network
root@uwspan.UUCP (Sue Peru Sr.) (03/30/88)
+---- In <1781@bgsuvax.UUCP> Kenneth Kutz writes ---- | +---- In <2423@bsu-cs.UUCP>, Rahul Dhesi writes ---- | | Here are some things I see under 4.3BSD that I don't see under SVR3, | +---- | | I've recently come from a System V environment to a BSD 4.3 environment. | I've kept a list of some of the differences I've found. In comparing this list to the SystemVr2 (Microport) that I have here, I found a few things that didn't jive. I would like to know if these are r2 -> r3 differences, or if they are "local additions". | exit Sys V: From the shell prompt, will return the user to the login prompt | BSD : Does not log the user out. BSD 4.3 (NFS/Wisconsin) exit does indeed log you out | echo Sys V: Cursor control supported such as backspacing (\b), cursor up (\v), | tab (\t), no new line (\c). | BSD : Cursor control only by embedding actual character (such as tab) Is this a r3-ism or what? \v would have to use the terminfo database... | Sys V: "/etc/profile" is a system wide start up script that gets executed | for every user that logs in. | BSD : Set up the administrator how he sees fit. No standard method. /etc/profile works ONLY for the Bourne Shell users - no go for csh or uucico... | Sys V: Bourne Shell provides variable "CDPATH". | BSD : Various shells from the net that provide wonderful things Not in r2 :-(, but standard? in 4.2/3 BSD csh. | Sys V: "ls -l" gives the UID and user name | BSD : Just user name ls -l gives user name and group name under Vr2. +---- -- Comp.Unix.Microport is now unmoderated! Use at your own risk :-)
cyliax@ea.ecn.purdue.edu (Ingo Cyliax) (03/30/88)
In article <7581@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <12690@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >> From: Doug Gwyn <gwyn@brl-smoke.arpa> >> > "script" for recording terminal session >> "Script" screws up the application running under it sometimes. It >> could be implemented almost trivially with STREAMS. Somebody should >> do so. >>Interesting. Please elaborate. > >Elaborate on what? The screw-up is that certain operations do not >work right on ptys. Yeah, like what "certain operations" don't work right on pty's ? I guess setting the baudrate probably doesn't make too much sense :-). By now (Bsd 4.3) everything that needs to work will work on pty's. If it didn't, we'd be up the sh*t creek here, because we have several machines that don't even have any real terminals hooked up. All the connections on these machines come in from the network through pty's. Everything people usually do works fine, vi, curses ... etc. I also like the way 4.3 handles window changes. The last time I ran layers with rlogin under Sys V, it didn't work too well ! In general 4.3 deals with tty's alot better than Sys V (with streams or without). -- /* Ingo Cyliax * * ...!ihnp4!pur-ee!cyliax ECN, Electrical Engineering Bldg. * * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * * ing@cc.purdue.edu (317) 494-3473 / (317) 463-1747 after 5pm */
ted@braggvax.arpa (03/31/88)
>From: Doug Gwyn <gwyn@brl-smoke.arpa> >Subject: Re: SVR3.0 vs BSD4.3 >Elaborate on what? The screw-up is that certain operations do not >work right on ptys..... I seems to me that it must be more than that. On Suns at least, we had certain applications that would die horribly if run under script. To catch their output, I would go to another machine, start up script, telnet or rlogin to the target machine and run the program. This worked fine, and both telnet and rlogin use ptys... Ted Nolan ted@braggvax.arpa
allbery@ncoast.UUCP (Phil Smith) (04/03/88)
As quoted from <2050@munnari.oz> by kre@munnari.oz (Robert Elz): +--------------- | > > support for multiple command interpreters with #! as first line of script | > | > This is totally unnecessary; | | This is so much drivel its not even worth commenting on. +--------------- As written, yes; but it's close. A cheap csh + "alias shell" + a tiny program together allow me to use #! syntax almost always. If everyone used "exec?p()" and "exec?p()" used $SHELL, it would work ALL the time. Since the majority of good programs use $SHELL, I have few problems. Note that we don't even run System V, much less BSD. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
allbery@ncoast.UUCP (Brandon Allbery) (04/05/88)
As quoted from <518@spectrix.UUCP> by John_M@spectrix.UUCP (John Macdonald): +--------------- | In article <7514@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | >[response to:] | >In article <2423@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: | >>[lots of detail differences where BSD4.3 is "preferred" than SVR3.0] | > ... | >[excellent response to most points] | > | >> support for multiple command interpreters with #! as first line of script | > | >This is totally unnecessary; if all scripts are executed by a Bourne | >shell, it is easy to simulate the #! feature, in fact to generalize | >on it. Nevertheless I think AT&T may be adding this kludge to the | >kernel exec code in a future release, alas. | | I think you are going a bit too far here - it is easy to get sh to invoke | another interpreter on a script, but not allowing the full capability | that #! provides (unless I'm missing some clever sh trick). In particular, | I don't think you can cause the command "file args" to effectively invoke | "interp [path/]file args" and keep the name of the file available to | the interpreter (for $0 type use). If $0 is not needed, of course, the sh +--------------- Go look in the comp.sources.misc archives, and pull out issue 8706/2, "bexec". This can do everything you ask for including retaining $0. And if it can be done from outside a shell (admittedly, by a hack) then it can be done more easily from inside the shell. execv?() allows argv[0] to be different from the path for a reason. A copy of /bin/sh modified for this would handle everything on "vanilla" System V systems except programs using something other than exec?p(); which programs ought be stamped out, in my opinion. To avoid changing the shells, it should be changed in exec?p(), and the shells should use it (dunno if sh does, but I'm certain that csh doesn't). A user-mode solution is better than a kernel hack. (All you lose is setuid shell scripts, which are an abomination anyway.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
simon@its63b.ed.ac.uk (ECSC68 S Brown CS) (04/08/88)
In article <445@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >>In article <7542@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >< In article <2050@munnari.oz> kre@munnari.oz (Robert Elz) writes: >< >But that's not job control. Job control is when I notice that /foobar >< >is 98% full, and some cretin has a job running that's half way through >< >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control. >< >Shell layers do not involve any kind of signals. When ^Z is hit, >the sxt driver gives control back to channel zero, which is >usually the layer manager (here, /usr/bin/shl). When a user >command to shl asks that a child layer be run, the layer manager >issues an ioctl to the multiplexor to give control to the child's >layer (there is no SIGCONT). One result of this implementation >is that I know of no way for a layer to suspend itself, certainly >not with signals. If your layer manager keeps the desciptor for channel zero open in it's subprocesses (and provides some method to allow these children to find out what descriptor it is - such as reserving a known descriptor for this use [Yeauch!]), then the subprocesses can do ioctls on this, so they can issue the ioctl to switch the current layer to zero, just as if ^Z had been typed. >Nevertheless it is not incorrect to equate job-control with shell >layers in a general kind of way -- kre's way just may be more general >than mine :-). Well, the only ESSENTIAL difference is that BSD job-control is cpu-control whereas SysV layers is io-control (you control what jobs can/cannot do input and/or output, rather than what jobs can/cannot be actively running). It's quite possible to put job-control code into a shell using layers that looks pretty close to BSD job-control - except that you can't control jobs that aren't doing terminal io. --Simon -- -------------------------------------------------- | Simon Brown | | Laboratory for Foundations of Computer Science | | Department of Computer Science | | University of Edinburgh, Scotland, UK. | -------------------------------------------------- UUCP: uunet!mcvax!ukc!lfcs!simon ARPA: simon%lfcs.ed@nss.cs.ucl.ac.uk JANET: simon@uk.ac.ed.lfcs