roche@cs.rochester.edu (James Roche) (09/22/90)
I'm trying to write a replacement for Pnews to handle some special local requirements. I am having trouble getting an editor to start from within the perl script. I have tried: `/usr/ucb/vi /tmp/postnews$$`; A ps shows that the editor was started, but it doesn't display anything. I can type input and it all works, but nothing gets displayed. What's the trick to starting an interactive program from within a perl script. Jim Roche -- Jim Roche University of Rochester Computer Science Department Rochester, NY 14627 ARPA: roche@cs.rochester.edu UUCP: rochester!roche
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/22/90)
In article <1990Sep21.190641.9221@cs.rochester.edu> roche@cs.rochester.edu (James Roche) writes:
: I'm trying to write a replacement for Pnews to handle some special
: local requirements. I am having trouble getting an editor to start
: from within the perl script.
:
: I have tried:
: `/usr/ucb/vi /tmp/postnews$$`;
:
: A ps shows that the editor was started, but it doesn't display anything.
: I can type input and it all works, but nothing gets displayed.
:
: What's the trick to starting an interactive program from within a perl
: script.
Don't use backticks. They eat the stdout of the subprocess.
Say this:
$EDITOR = $ENV{'VISUAL'} || $ENV{'EDITOR'} || '/usr/ucb/vi';
system "$EDITOR /tmp/postnews$$";
Larryallbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (09/22/90)
As quoted from <1990Sep21.190641.9221@cs.rochester.edu> by roche@cs.rochester.edu (James Roche): +--------------- | I'm trying to write a replacement for Pnews to handle some special | local requirements. I am having trouble getting an editor to start | from within the perl script. | | I have tried: | `/usr/ucb/vi /tmp/postnews$$`; +--------------- The whole point of `` is that, as in a shell, the standard output and standard error of the program are trapped and returned to Perl as a (very large...) string (or list, depending on context). Try the following instead: system '/usr/ucb/vi', "/tmp/postnews$$"; (Splitting it up like that means that the overhead of a shell is unnecessary, but you *must* use a full pathname for the editor. Use a single string if you can't guarantee the existence of a full pathname.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR/KT on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/25/90)
In article <1990Sep22.144126.21099@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes:
: system '/usr/ucb/vi', "/tmp/postnews$$";
:
: (Splitting it up like that means that the overhead of a shell is unnecessary,
: but you *must* use a full pathname for the editor. Use a single string if you
: can't guarantee the existence of a full pathname.)
Not so, unless your execvp(3) is broken. Just tried
system 'vi', '/tmp/foo';
and it worked fine. Incidentally,
system "vi /tmp/postnews$$"
doesn't invoke the shell either, since there are no shell metacharacters
after double quote interpretation.
Larryokamoto@hpcc01.HP.COM (Jeff Okamoto) (09/27/90)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: > The whole point of `` is that, as in a shell, the standard output and > standard error of the program are trapped and returned to Perl as a > (very large...) string (or list, depending on context). This is not the behavior I see on an HP 9000/800 running HP-UX A.B7.00. If I say: @test = `./a.out`; print "Out: @test"; where a.out is the simple C program: main() { printf("Hello, "); fprintf(stderr, "world.\n"); } I get: % perl backticktest world. Out: Hello, Because of this, I've written a subroutine to capture both the standard output and error and return it in a list. -- ___________ The New Number Who, / ____ / / Jeff Okamoto /_/ / / / HP Corporate Computing & Services / / / GUNDAM okamoto@ranma.corp.hp.com / / / __ / / /___/ / (415) 857-6236 / /__________/ "Zeta Gundam, Camille, ikimasu!"
chrise@hpnmdla.HP.COM (Chris Eich) (09/28/90)
In comp.lang.perl, okamoto@hpcc01.HP.COM (Jeff Okamoto) writes:
... I've written a subroutine to capture both the standard
output and error and return it in a list.
Why not just do `foo 2>&1` or `(complex-shell-stuff) 2>&1`?
Chrisokamoto@hpcc01.HP.COM (Jeff Okamoto) (10/03/90)
chrise@hpnmdla.HP.COM (Chris Eich) reminds me: >> ... I've written a subroutine to capture both the standard >> output and error and return it in a list. > Why not just do `foo 2>&1` or `(complex-shell-stuff) 2>&1`? This will indeed work, and I should have thought of it. At least, however, the work I had to do to get around this taught me a lot about fork, wait.... -- \ oo The New Number Who, \____|\mm Jeff Okamoto //_//\ \_\ HP Corporate Computing & Services /K-9/ \/_/ okamoto@ranma.corp.hp.com /___/_____\ ----------- (415) 857-6236
worley@compass.com (Dale Worley) (10/05/90)
> Why not just do `foo 2>&1` or `(complex-shell-stuff) 2>&1`?
Doesn't this form have the disadvantage of starting an extra sh? I
know that it's the most efficient way to do it, but it sorta annoys me
that an sh has to be started to do a simple redirect, especially when
I realize that Perl is redirecting stdout already in order to capture
the output...
Whine, whine,
Dale Worley Compass, Inc. worley@compass.com
--
If the United States were really a democracy, we would have concentration
camps for AIDS patients.