lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (11/30/88)
Leslie Mikesell writes:
: Perhaps the reason is that it is not compiled into the official AT&T
: release, at least not up to SysVr3.1 on the 3B2's. It would be extremely
: useful, though, as would the ability to execute a script like that
: found in the Dialers file at an arbitrary time (i.e. after the connection
: is made). The code is obviously already there. Is Larry Wall listening?
: How about adding ioctl() to perl so we can use it instead?
Er, um, that's kinda hard. But I been thinkin' about it.
In the meantime, if it's something that stty knows about you can just
fork one off to do whatever you want after making sure you have the tty
open on stdout (stdin on some systems).
open(TTY,"/dev/tty07");
...
open(dupout,">&stdout"); # dup stdout
close stdout;
open(stdout,">&TTY"); # dup filehandle TTY
system 'stty', '-echo', 'raw';
close stdout;
open(stdout,">&dupout"); # restore stdout
close dupout;
If efficiency isn't as important you can just say
system 'stty -echo raw >/dev/tty07';
To do ioctl in perl I'd have to have a way to supply variable sized 3rd
arguments to ioctl. I figure I could do that with a pre-sized array, with
extra information to say whether it is to be interpreted as bytes, shorts
or longs. A scalar could likely substitute for a single element array.
The main problem with doing ioctl in perl is not the 3rd argument as much
as the 2nd. Have you looked at the shenanigans they do in sys/ioctl.h?
(On BSD and Sun at least--I don't know about Sys V.) Those cute little
identifiers you feed to the 2nd argument are awful. You say, in C,
something polite like:
ioctl(0,FIONREAD,&cnt);
and cpp turns that into the following mishmash
ioctl(0,(0x40000000|((sizeof(int)&0x1fff)<<16)|('f'<<8)|127),&cnt);
So if I'm gonna let you write, in perl,
ioctl(stdin,$FIONREAD,$cnt);
I've gotta have some way of teaching perl about the gobbledygook above.
Anyway, I'm thinking about it. Adding chroot() would be much easier.
And maybe getppid(). I think I'll make the current priority a variable,
usable only if your system supports getpriority/setpriority:
$" -= 20; # grab that CPU!
The nice program could then be written like this:
#!/usr/bin/perl
$diff = ($ARGV[0] =~ s/^-(-?\d+)/$1/) ? shift : 10;
$" += $diff;
exec @ARGV;
Is this reasonable?
I'm still thinking about that ioctl...
Larry Wall
lwall@jpl-devvax.jpl.nasa.gov
"So many programs, so little time..."les@chinet.chi.il.us (Leslie Mikesell) (12/01/88)
In article <3605@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >: How about adding ioctl() to perl so we can use it instead? >Er, um, that's kinda hard. But I been thinkin' about it. I was just thinking in terms of being able to dial out a tty port and chat and/or exec some file transfer protocol (with uucp compatible lock files, etc.) For that purpose it might be easier to build in "stty" instead of the full ioctl() functionality with the associated problem of undefined structs. However, perhaps I should ask your opinion on a "higher-level" approach. What would you do if you did not have "rsh" and needed similar functionality over dial-up or direct serial lines with some unix, some non-unix machines. I'm using various versions of kermit for some of this, especially exchanging files with a VM/CMS host where nothing else works, but I'm not entirely satisfied with it. Should I be looking at SLIP and something to emulate rsh under SysV, or a wrapper around zmodem protocol (this may need to run over a satellite connection), or fixing kermit to do what I want, or...? Les Mikesell