|
Re: I got two questions, please see here:)
by atcroft (Abbot) on Feb 18, 2011 at 04:07 UTC
|
For both questions, I would suggest reviewing perlipc, the perl documentation on inter-process communications. The section on signal handling mentions both Ctrl-C and Ctrl-Z (from question 1), while the section "Using open() for IPC" would be a good place to start for question 2.
Hope that helps.
Update: (2011-02-17)
For reference, I believe (after a quick search) that Ctrl-C sends SIGINT (INT), and Ctrl-Z sends SIGTSTP (TSTP).
Update: (2011-02-17)
The example from the section on signal handling can be modified as follows to illustrate handling the INT and TSTP signals:
A modification of the second code example in the section mentioned for question two uses open() to retrieve interface IP information using the ifconfig command:
| [reply]
[d/l]
[select] |
Re: I got two questions, please see here:)
by Khen1950fx (Canon) on Feb 18, 2011 at 06:05 UTC
|
To suppress output of the command, use the capture method from
IPC::System::Simple. The capture command replaces the backticks. For example:
#!/usr/bin/perl
use strict;
use warnings;
use IPC::System::Simple qw(capture);
my @output = capture("ls", "/root/Desktop");
The output's there just not printed to output. To retrieve
the results:
#!/usr/bin/perl
use strict;
use warnings;
use IPC::System::Simple qw(capture);
my @output = capture("ls", "/root/Desktop");
print @output, "\n";
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l] |
|
|
| [reply] |
Re: I got two questions, please see here:)
by cdarke (Prior) on Feb 18, 2011 at 09:36 UTC
|
If I press Ctrl+Z or Ctrl+C to stop a perl script
Presumably you are running on UNIX or Linux? Please confirm. On those platforms CTRL+Z does not usually stop a process but places it suspended in the background. Depending on the shell you are using, type jobs and you will see a list of them. The shell built-in fg will resume the background process in the foreground. Read the man pages for your shell.
Both these signals (see above) can be assigned to other keys using stty(1). So if someone has been playfull with your terminal settings they could do almost anything.
You can trap most signals and execute a signal handler subroutine in most languages (even korn shell and bash: see the trap builtin). For Perl see %SIG in perlvar. | [reply]
[d/l]
[select] |
|
|
Looks like Windows. He mentioned ipconfig.
| [reply] |
Re: I got two questions, please see here:)
by DrHyde (Prior) on Feb 18, 2011 at 10:42 UTC
|
- You'll get better responses if you give your posts a descriptive title. If you have two seperate questions, post them seperately so both can have a good title.
- See %SIG in perlvar
- You can redirect their STDOUT and STDERR when you shell out to them in the same way as you would in the shell, or you can capture them using backticks or open
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Yes, I agree with all of you.
Sorry for not clear about my titles, I will do better:)
Thank you all guys :)
| [reply] |
Re: I got two questions, please see here:)
by sundialsvc4 (Abbot) on Feb 18, 2011 at 14:46 UTC
|
Piping command-output to “the bit-bucket” (/dev/null on a Unix box) is also useful, with Perl and otherwise. Both the STDOUT and the STDERR streams can be piped into oblivion in this way. This notion really isn’t Perl-specific at all: it’s general shell-scripting practice.
| |
Re: I got two questions, please see here:)
by Anonymous Monk on Feb 18, 2011 at 13:56 UTC
|
For Q1, %SIG is the answer, as noted above.
For Q2, it depends on what you need to do. If you don't need the command output you can just redirect the output to /dev/null. Backticks, or qx//, shouldn't print anything to STDOUT, so maybe you're getting some of hte progam STDERR instead. You can try to execute the command as my @output = `$command 2>&1`, or go to IPC::Open2 or IPC::Open3 if you need to parse the output.
| [reply]
[d/l]
[select] |