Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcvax!ukc!its63b!simon From: simon@its63b.ed.ac.uk (ECSC68 S Brown CS) Newsgroups: comp.unix.questions Subject: Re: BSD & Sys5 Job Control Message-ID: <247@its63b.ed.ac.uk> Date: Thu, 5-Feb-87 06:26:56 EST Article-I.D.: its63b.247 Posted: Thu Feb 5 06:26:56 1987 Date-Received: Sat, 7-Feb-87 21:02:51 EST References: <1324@cadovax.UUCP> <161@piaget.UUCP> <114@dolphy.UUCP> <1055@sfsup.UUCP> <164@myab.UUCP> Reply-To: simon@its63b.ed.ac.uk (ECSC68 S Brown CS) Organization: I.T. School, Univ. of Edinburgh, U.K. Lines: 121 Keywords: shell, job control, sxt, SysV In article <164@myab.UUCP> lars@myab.UUCP (Lars Pensj|) writes: > >It is quite possible to make csh use the sxt devices. We have done >such an implementation, and are now using csh in place of sh. Strangely enough, I've done the same for sh (and of course am using it in place of csh :-) ). > >Result: > >++++ Possibilities to switch between 7 jobs and let them > run in the background. Seven because the shell itself is using channel 0 for input/output of commands - but in that case, there is a little problem with terminal groups; namely: The shell can't just keep its old "real" tty as its controlling terminal because this cannot be accessed (via read(2)) any more once an sxt cluster has been multiplexed onto it, so the shell will have to take over sxt channel 0 for its own purposes. The only way of getting a new terminal as your controller is to do the following: 1. Do a setpgrp(). 2. Open a new terminal. So, you would naturally think that the way to get an sxt chan 0 for your shell's controller would be to do this: 1. setpgrp(); 2. open("/dev/sxt??0",2); All well and fine - until you try to multiplex the rest of the cluster onto chan 0 (SXTIOCLINK ioctl) - for this to work, your controlling terminal must be a "real device" (not an sxt), so you can't put the setpgrp() there. And if you don't do that, then sxt??0 is not set up to be your controller. Ok, next attempt is probably 1. fd=open("/dev/sxt??0",2); 2. ioctl(fd,SXTIOCLINK,...); 3. setpgrp(); 4. open("/dev/sxt??0",2); ie, re-open the chan-0 device. But this falls over because of the "ownership" problem with sxt's. [Brief summary: A standard non-priviliged user will need to be able to open these sxt devices in read/write mode. But once they have done so, nobody else had better be able to do so! (for obvious security reasons). Also, programs such as shl are pretty untidy about the mess they leave behind them - shl chown()'s the sxt's to the userid of whoever is using them, but doesn't chown back to some standard user (root?) afterwards. So, if 16 people logged in and ran shl and logged out again, then all the sxt devices will be owned by them and only them - nobody else ('cept root) has a hope of ever being able to access them again. (Subsiduary remark: My solution to this (pretty crappy, I know), is to have a setuid service-program which "allocates" sxt's by chowning them to the real-uid of the caller. The job-control shell will then access an sxt device cluster by doing a) execute this "sxt-allocator". b) go through all the sxt's, trying to open each cluster's channel-0. If the open succeeds, then you've got one. It it fails with errno==EBUSY then keep on trying. If it fails with errno anything else, then give up and that particular instance of the shell can't have any job-control. c) multiplex the subchannels. d) set chan-0 to exclusive-use (TIOCEXCL ioctl) to stop anyone else from stealing it from under you. e) ...... Another advantage of this is that the setuid allocator can then modify utmp (you can't, 'cos you aren't root). If the shell calls the allocator again (when its finished being a shell), then utmp can be changed back again - its all pretty transparent. ) ] Or perhaps its not, actually. I'll have to think about this again :-) Anyway to get back to the original argument... you could fix this by making channel-1 the controlling terminal - but then you can only have 6 remaining subchannels, which isn't too many.. > >- Csh doesn't modify tty name in wtmp. We "hacked" getlogin() to > do it another way, and relinking all programs using it. You'd also have to "hack" all the functions in the getut(3) family. > >- Csh have problems handling type ahead, because typed characters > are associated to the sxt device attached to the current > process. When the process exits, csh has to read them back from > this device. That's ptetty straightforward - it means that anything typed while a process is getting 'round to dying off can be picked up by the shell and read as part of the next command - but you can't type further input and expect it to get picked up by the next command, 'cos it won't be: Example: $ ex filename # edit (or whatever) something) :q # quit mail fred # while its dying, start typing next command hello # ... and type some data as input? hi fred, this is mail..... ^D $ # shell-prompt, then it executes "mail" Subject: # ... huh? why is it waiting? I thought # ... I'd given it some input, it seems # ... to have forgotten that! ^D $ hello: not found # oh look! it stored up what I typed in $ hi: not found # the _shell_'s input buffer! Of course, if SysV provided a TIOCSTI ioctl call like BSD does, then this could be fixed by the shell's sticking the extra characters into the input queue of whatever sxt device is running next :-) > >- A process can not know whether it is blocked or not. Well...., if the sxt controller channel (chan 0) were left open, then processes could do a SXTIOCSTAT ioctl on it and look for themselves. But this would be gross. :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Simon Brown Department of Computer Science, University of Edinburgh, Scotland, UK. UUCP: ...!decvax!seismo!mcvax!ukc!{cstvax,its63b}!simon JANET: simon@uk.ac.ed.{cstvax,its63b}