I am very new to perl. I am trying to create a perl script which will execute multiple unix command to create VNC session in some unix server.
Here is my script -
#!/usr/bin/perl -w
use Carp;
use strict;
use warnings;
# here get the parameters idsid
my $IdsId=$ARGV[0];
#excecute the commands here
my $user=`su -l $IdsId`;
my #finalresult=`vncserver -randr 1024x768,800x600,1024x768,1152x824,1280x1024,1280x800,1440x900,1400x1050,1600x1200,1920x1200`;
print "#finalresult";
But when I am executing this script its not working.
Please some body help me.
I would expect to see you executing:
exec "su", "-l", "$IdsID", "-c", "vncserver -randr ...";
which makes the Perl script largely irrelevant since you could write it in shell as:
exec su -l "${1:-$USER}" -c "vncserver -randr ..."
It might be better to use sudo rather than su. The difference is that with su, you have to know the other user's password; with sudo, you only have to know your own password (and the system administrator must have given you permission to use sudo for the task on hand).
When you use backticks, a sub shell is created and the main program is halted. When the process in that sub shell is finished, the control returns to the main program. So in this case, I imagine that su never exits, and that vncserver does not run with the user you intend (nor does it exit to return control to the perl script) -- because it is executed in another sub shell where su never happened.
What you probably need is to do these commands in the same line:
my #result = qx(su -l $IdsId; vncserver -randr ....);
Although whether this works or not you'll have to find out for yourself.
Related
I am trying to run a couple of commands in putty from perl. Right now my code gets me into putty but I am unsure of how to execute commands from there.
my $PUTTY = 'C:\Users\Desktop\putty.exe';
my $dacPutty = "$PUTTY, -ssh username#server - l username -pw password";
system ($dacPutty);
system (ls);
use plink instead. ( http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter7.html )
plink is in the same directory as putty.
Usually in Perl it's better to use a Perl module, where one exists, than to shell out.
Using a module is more portable, and often gives you more control. system introduces many opportunities for security bugs, so it's good to avoid it where possible.
In this case, use Net::SSH::Perl http://search.cpan.org/~turnstep/Net-SSH-Perl-1.38/lib/Net/SSH/Perl.pm
Once installed:
use Net::SSH::Perl;
my $ssh = Net::SSH::Perl->new("host1");
$ssh->login("user1", "pass1");
$ssh->cmd("cd /some/dir");
$ssh->cmd("foo");
For reliability, you should actually check the result of each cmd:
my ($stdout, $stderr, $exit) = $ssh->cmd("cd /some/dir");
unless ($exit == 0) {
// Handle failed cd
}
The document notes that with SSH-1, each cmd reconnects, so the above would not work -- you would cd in one shell, then foo in a completely new shell. If you have to use SSH-1, then you'd need to do:
$ssh->cmd("cd /some/dir; foo");
(And you can use a similar trick even if you're making a system call to plink)
Since export cannot be used with a Perl script I've used the environment variable.
This code doesn't return any error but the command perl -c to check the syntax of the .pm file does not print the output.
myscript.pl
$ENV{'PATH'}='C:/Users/abc/Desktop/mno/wwwww/scripts/lib/perl/';
system("perl -c ContentModifySeasonPassOverlayRecord.pm");
Let me make another guess at what you want to do:
You want to batch syntax-check all your Perl modules, maybe in a cronjob. The script you are using to do that is located somewhere outside your working directory (where your framework sits). The scripts you want to check also sit somewhere else.
What you need to do is run the perl -c command from where the lib (framework) is, so that the working directory for the script while running has the lib files. You need to change the working directory before doing your perl -c call, and you need to include the full path to your scripts in the call.
#!/usr/bin/perl
use strict; use warnings;
# Change current working directory to where the framework is
chdir('/home/user/Desktop/QWARTS-0.6/autoinfra/lib/perl/');
# Run the perl -c command for each of your scripts you want to check
foreach my $script (qw(ContentModifySeasonPassOverlayRecord.pm otherfiles.pm)) {
system("perl -c /path/to/your/scripts/$script");
}
#!/usr/bin/perl
use warnings;
use strict;
system("perl -c /root/.cpan/build/DateTime-TimeZone-1.31-oqQt_7/lib/DateTime/TimeZone/America/Noronha.pm");
I don't see how it doesn't work?
# ./errr.pl
/root/.cpan/build/DateTime-TimeZone-1.31-oqQt_7/lib/DateTime/TimeZone/America/Noronha.pm syntax OK
I think you are doing a wrong way to execute a perl script with in perl script
here is the right way of executing a perl script with in perl script
use strict;
use warnings;
use IPC::System::Simple qw(system capture);
# Run a command, wait until it finishes, and make sure it works.
# Output from this program goes directly to STDOUT, and it can take input
# from your STDIN if required.
system($^X, "yourscript.pl", #ARGS);
# Run a command, wait until it finishes, and make sure it works.
# The output of this command is captured into $results.
my $results = capture($^X, "yourscript.pl", #ARGS);
And to check the errors in a module , You can just 'use' the module in your perl script and run the script in an usual way , if it has errors it will throw to stdout
If you want to test large number of perl modules you can build a shell script for that purpose .
#!/bin/sh
// List all modules
MODULES="Data::Dumper Foobar::Test"
for i in $MODULES ; do
if $(perl -M$i -e '1;' >/dev/null 2>&1 ); do
echo "Ok."
else
echo "No."
fi
done
I came across the following example. I tried to google but could not find much so I'm posting this question here.
What is the benefit of executing the perl script like this?
How can we make the shell script work like a "normal" shell script once we are through executing the perl code?
Here's the code:
#!/bin/ksh
#! -*- perl -*-
eval 'exec $PERLLOCATION/bin/perl -x $0 ${1+"$#"} ;'
if 0;
print "hello world\n";
# how can I make it behave like a "normal" shell script from this point onwards? What needs to be done?
# echo "hello world" ### this results in error
This idiom is described in the perlrun documentation.
The -x switch scans the whole file and ignores anything that appears before the first line that begins with #! and also contains the word perl.
It means that your system will run the script with the Perl interpreter whether you invoke the script with perl or with a shell command (sh/bash/ksh/etc.)
That is,
$ perl this_script
and
$ sh this_script
will both run the script with perl.
To address your second question, this idiom has just about nothing to do with combining shell script and Perl script in the same file. There are a few different ways to approach that problem, but maybe the most readable way is to write in shell script, but use the shell's heredoc notation to invoke perl code.
#!/bin/bash
# this is a bash script, but there is some Perl in here too
echo this line is printed from the shell
echo now let\'s run some Perl
perl <<EOF
# this is now perl script until we get to the EOF
print "This line is printed from Perl\n";
EOF
echo now this is from the shell script again
1. If you start a Perl script in the usual way:
#!/usr/bin/perl
print "hello world\n";
the #! line will only work if the Perl interpreter is actually installed under /usr/bin. The perl/ksh bilingual script you show is a tricky kluge to make the script work even if perl is installed somewhere else. For more information, see e.g. this.
2. You can't. When the shell process encounters the exec command, it terminates and hands control over to perl. (Technically, it executes perl in place of the shell, without creating a new process.) The only way to run more shell commands after that would be to launch a new shell.
It's way simpler than what's already been posted.
#!$PERLLOCATION/bin/perl
doesn't work because the shebang (#!) line is interpreted by the kernel (not the shell), and the kernel doesn't do variable interpolation.
The code invokes ksh to expand the environment variable and to launch the specified installation of Perl.
In debian lenny, when running /etc/init.d/tomcat5.5 start, it runs jsvc and expects it to daemonize itself.
From a simple bash shell, this works fine.
However, from a script, this gets completely stuck:
For example, the following works like a charm:
#!/usr/bin/perl
my $cmd = '/etc/init.d/tomcat5.5 start';
system($cmd);
However, the following gets stuck as jsvc does not daemonize:
#!/usr/bin/perl
my $cmd = '/etc/init.d/tomcat5.5 start';
`$cmd`;
It also gets stuck when running it using backticks in bash:
#!/bin/bash
CMD='/etc/init.d/tomcat5.5 start'
`$CMD`
Is this a bug in jsvc? Any idea why this works in a shell or using system() , but not using backticks? I am actually getting defunct/zombie processes because of this issue.
Just a hunch -- for a job to become a daemon it needs to close any file descriptors that were opened in its parent process. Perhaps this is easier to do with system than with backticks/readpipe, though I can't come up with any good reasons why that would be so. What if you used the backticks like:
`$CMD < /dev/null > /dev/null 2>&1`
Backticks will evaluate to the output of the command, if there's lots of data, you may fill the buffer. No need to use the backticks if you don't want to evaluate or catpure the output in the script itself.
In example, this bash script should work:
#!/bin/bash
CMD="/etc/init.d/tomcat5.5 start"
# note no backticks
$CMD
Also please define "daemonize"? You want this nohup'd and asynchronous?
In Perl, is it possible to make 'exec', 'system', and 'qx' use a shell other than /bin/sh (without using a construct like 'exec "$SHELL -c ..."', and without recompiling perl)?
EDIT: The motivation for this question is a bash script that does 'export -f foo' and then uses perl in a subshell to invoke the function directly via 'system "foo"'. I am not sure that this technique will work with all sh, and although 'system "/bin/bash -c foo"' may work in that scenario, I wouldn't expect the exported function to propagate through all variants of /bin/sh. But mostly I was just curious, and am now curious about how to extend the solution to qx. Also, since I know nothing about non-unix platforms, I'd like to avoid hard coding the path to an alternate shell in the solution.
You can override exec and system. See perldoc perlsub for the details, but here is roughly what you want (modulo some quoting bugs I don't feel like trying to fix):
#!/usr/bin/perl
use strict;
use warnings;
use subs qw/system/;
sub system {
#handle one arg version:
if (#_ == 1) {
return CORE::system "$ENV{SHELL} -c $_[0]";
}
#handle the multi argument version
return CORE::system #_;
}
print "normal system:\n";
system "perl", "-e", q{system q/ps -ef | grep $$/};
print "overloaded system:\n";
system 'ps -ef | grep $$';
exec and system will use the shell (which will likely not be /bin/sh on non-UNIX systems) if you only pass one argument to it. (Details are described in perlfunc)
You may want to have a look at IPC::Run3 as an alternative to system
Why don't you want to use 'exec "$SHELL -c ..."'? If you don't want see that code every time you call exec or system, just hide it in a subroutine. That's what they're there for. :)
sub my_exec {
exec $ENV{SHELL}, '-c', #_;
}
If you want to do that, however, I suggest somehow sanitizing $ENV{SHELL} so that people don't do odd things to your script by setting weird values. You might want to ensure that the shell is listed in /etc/shells or whatever way your system lists approved login shells. You also need to do a bit more work to make this taint-clean, which you should probably do if you are going to send data to another process.
exec doesn't use /bin/sh
It just execs the program you specify. No shells.
If you want it to go through a shell you have to do that yourself.