kelso@seas.gwu.edu (John Kelso) (03/03/90)
Greetings-
I've been trying, without any luck, to get a dumped (and then undumped)
perl script to read and write from standard input and standard output.
It can do I/O to regular files without any problems.
If it can be done, could someone give me an example, or a RTFM
pointer, or even an informative flame?
Many thanks,
John
--
John Kelso, System Engineer, George Washington University
SEAS Computing Facility, 725 23rd St NW, Washington DC 20052
kelso@seas.gwu.edu -or- uunet!gwusun!kelso
--lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (03/06/90)
In article <1648@sparko.gwu.edu> kelso@seas.gwu.edu (John Kelso) writes: : I've been trying, without any luck, to get a dumped (and then undumped) : perl script to read and write from standard input and standard output. : It can do I/O to regular files without any problems. : : If it can be done, could someone give me an example, or a RTFM : pointer, or even an informative flame? I snooped around and found the same behavior on my Suns (but not on my Vax). Apparently, there's something in the startup code that gets confused when trying to init the stdio structure the second time through. Anyway, the _flag byte is ending up 0, on Suns at least. Maybe they're using XOR to install the bits, so the second time through it clears them? Anyway, here is an unofficial patch. It's unofficial because I don't know who needs it and who doesn't, and who it will blow out of the water. Also, it might be something that undump should fix. I dunno. *** perly.c.orig Mon Mar 5 14:43:20 1990 --- perly.c Mon Mar 5 14:44:02 1990 *************** *** 74,79 **** --- 74,82 ---- if (do_undump) { do_undump = 0; loop_ptr = -1; /* start label stack again */ + stdin->_flag |= _IOREAD; + stdout->_flag |= _IOWRT; + stderr->_flag |= _IOWRT; goto just_doit; } (void)sprintf(index(rcsid,'#'), "%d\n", PATCHLEVEL); See if that makes it feel any better. If anyone else wants to try it, here's a test program. #!/usr/bin/perl -u $foo=<STDIN>; print STDOUT $foo; If the undumped version is a no-op, you have the problem. Larry
piet@cs.ruu.nl (Piet van Oostrum) (03/07/90)
In article <7274@jpl-devvax.JPL.NASA.GOV>, lwall@jpl-devvax (Larry Wall) writes:
`
`Apparently, there's something in the startup code that gets confused
`when trying to init the stdio structure the second time through. Anyway,
`the _flag byte is ending up 0, on Suns at least. Maybe they're using
`XOR to install the bits, so the second time through it clears them? Anyway,
`here is an unofficial patch. It's unofficial because I don't know who needs
`it and who doesn't, and who it will blow out of the water. Also, it might
`be something that undump should fix. I dunno.
Larry, we had that problem in one of the earliest versions of perl3.0.
I had a patch then, but that got lost. The problem is in the abort() call.
It closes the files, and that means on most systems, clearing the flags. So
you must abstain from closing, i.e you must have some alternative to abort
that doesn't close the files. (Like just sending a signal to yourself). You
should flush the files however. (There is no portable way to flush all open
files, unless you keep a list of the open files yourself.)
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (03/08/90)
In article <2600@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes:
: Larry, we had that problem in one of the earliest versions of perl3.0.
: I had a patch then, but that got lost. The problem is in the abort() call.
: It closes the files, and that means on most systems, clearing the flags. So
: you must abstain from closing, i.e you must have some alternative to abort
: that doesn't close the files. (Like just sending a signal to yourself). You
: should flush the files however. (There is no portable way to flush all open
: files, unless you keep a list of the open files yourself.)
I tried doing a kill(getpid(),SIGIOT), but that seems to have the same
effect as abort() in terms of wiping out _flag.
We don't have to worry about files other than std*, since we can't keep
them open anyway. An fflush(stdout) is about all that's needed.
But the kill didn't work. Is some library routine catching the signal
somehow? No, signal(SIGIOT,SIG_DFL) doesn't change things.
How do they close it? Does the kernel do it? I still suspect the
startup code.
Larry