I recently sent the following:
> Hardware: Sun 670/41
> OS: SunOS 4.1.3
>
> Hi,
>
> I have a program that normally runs interactively but I want it to
> run overnight. This should be a simple matter of sticking it into
> an appropriate shell script and giving it to _at_, which I tried.
> The program crashed (with zero grace, I might add), so I ran it
> under trace, kind of like this, but in a shell script with a lot of
> not relevant environmental setup:
>
> at now + 1 minute <<END
> #! /bin/sh
> exec > stdout 2> stderr
> trace pgm
> END
>
> This tells me that pgm is trying to open /dev/tty, which is possible,
> albeit lame, in an xterm window where the pgm normally runs, but
> under _at_, there is no longer the hook to the xterm and /dev/tty
> doesn't exist. I guess the reason pgm opens /dev/tty is that it
> wants to tell me something even though my standard out is redirected,
> both in interactive and batch mode.
>
> So I call my software vendor (I do not have the source, BTW), and they
> are going to get right on it and I should have a fix REAL SOON NOW, but
> meanwhile I REALLY NEED to run this compute hog program hundreds of
> times by the end of this month and not interfere with the very heavy
> day schedule. So I figure, what the heck.
>
> I wrote a perl script that goes in and finds /dev/tty and changes it to
> /tmp/dmy. I tried to run the program again and (shockingly enough) it
> works and even gets past the open and opens my file. BUT...
>
> The next thing that happens after the open is an ioctl call, which does
> something termio specific and therefore gives me:
>
> open ("/tmp/dmy", 02, 0) = 5
> ioctl (5, 0x40125401, 0xafebe4) = -1 ENOTTY (Inappropriate ioctl for device)
> writev (2, 0xeffff1f8, 4) = ioctl: Inappropriate ioctl for device
> ---- sudden program death syndrome ----
^^^
BTW, touching /tmp/dmy before executing the program lets it
go a little further in that the program gracefully closes its
files and exits, but it still doesn't do its job. I need to
fool the program into thinking it got what it wanted.
>
> which makes me think that the filio kind of thing I am not trying to do
> is getting an inappropriate ioctl call.
>
> So now I am reading ioctl and trying to figure how in the heck I am going
> to patch it. I can find the request -0x40125401-, but I'm a little unsure
> about the arg -0xafebe4-, which I think is a pointer to a struct anyway.
> I think I could just maybe clobber the ioctl call.
>
> Does anyone have any suggestions while I wait for my vendor to get me
> the real fix?
>
>
> Will Morse bhppa@sugar.neosoft.com
>
> ---- perl, the Swiss Army Chainsaw of sysadmin tools ----
>
I got several responses.
jdavis@cs.arizona.edu suggested a program called pty, which is available
from gatekeeper.dec.com. This looks like the best solution except it
does not seem to run on SunOS 4.1.3 judging from the documentation.
eirik@elf.ithica.ny.us suggested expect, which is a fairly complicated
solution for just this problem, but I am pursuing it because it may
be useful in other areas too. It uses Tcl, which we already use.
crhea@mayo.edu and ln1gec@entoil.co.uk bot suggested making the /tmp/dmy
a real or pseduo tty. As I see it, this will throw away part of the
report, but let the job complete. I am looking at this as well.
Other suggestions are still welcome.
Will Morse
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:56 CDT