I have a perl script as below, where I want to access a network path on a remote windows machine from a linux machine using rsh.
$cmd = "rsh -l $username $host \"pushd \\\\network\\path\\to\\the\\directory && dir\"";
print $cmd, "\n";
print qx($cmd);
When I run the script the third line prints output The system cannot find the path specified. However, if I run the command printed by the second line directly from the terminal it works fine.
I'm not able to understand why the script is not working. If the command works from the terminal, it should work using qx() too.
While you escape your meta-characters against interpolation by double-quotes and by the remote shell, qx might itself interpolate the string again, in which case you might need to add another level of escaping. From the documentation of qx:
A string which is (possibly) interpolated and then executed as a system command with /bin/sh or its equivalent. ...
How that string gets evaluated is entirely subject to the command interpreter on your system. On most platforms, you will have to protect shell metacharacters if you want them treated literally. This is in practice difficult to do, as it's unclear how to escape which characters. See perlsec for a clean and safe example of a manual fork() and exec() to emulate backticks safely.
Related
I have a command
my $output = `somecommand parm1 parm2`;
When I try to run this Perl script I get the message
Can't exec "somecommand" at .....
It seems it is not seeing anything past the first space in between the backticks. I have a friend who runs this in a different environment and it runs fine.
What could I have in my environment that would cause this? I am running Perl v5.20 but so is my friend.
Perl's not ignoring the command parameters, it's just mentioning only the part of the command that it has a problem with -- it can't find somecommand
Whatever your somecommand is, it's not a shell command and it's not in a directory listed in your PATH variable
Change PATH to add its location to the end and it will work for you. You can do that system-wide or you dan modify it temporarily in your Perl code by manipulating $ENV{PATH} before you run the command
I can use system in Perl 5 to run external programs. I like to think of system like a miniature "Linux command line" inside Perl. However, I cannot find documentation for system in Perl 6. What is the equivalent?
Perl6 actually has two commands that replace system from Perl 5.
In Perl6, shell passes its argument to the shell, similar to Perl 5's system when it has one argument that contains metacharacters.
In Perl6, run tries to avoid using the shell. It takes its first argument as a command and the remaining arguments as arguments to that command, similar to Perl 5's system when it has multiple arguments.
For example:
shell('ls > file.log.txt'); # Capture output from ls (shell does all the parsing, etc)
run('ls','-l','-r','-t'); # Run ls with -l, -r, and -t flags
run('ls','-lrt'); # Ditto
See also this 2014 Perl 6 Advent post on "running external programs".
In addition to using shell or run, which replace system from Perl 5, you can also use NativeCall to invoke the libc system function.
On my Windows box, it looks like this:
use NativeCall;
sub system(Str --> int32) is native("msvcr110.dll") { * };
system("echo 42");
I'm using AS perl on win7.
print `cd \\\\ `; # does nothing, says nothing
Same with qx()
print `dir \\\\ `; # correctly prints the root directory
other commands also seem to work fine.
cd works fine from the command line of a batch file.
Has anyone else seen this? Is there a workaround?
You may be looking for chdir. Using a shell command in backticks is not going to have a lasting effect. When you run a backtick command, you spawn a new shell, execute the command, and return the standard output to Perl. Then the shell exits and any and all changes to it is lost.
perldoc -q changed
I {changed directory, modified my environment} in a perl script. How come the change disappeared when I exited the script? How do I get my changes to be visible?
In the strictest sense, it can't be done--the script executes as a different process from the shell it was started from. Changes to a process are not reflected in its parent--only in any children created after the change.
I have a Perl script which needs to be called from a clean environment. The way I call the script is as follows.
env -i test.pl
After invoking env -i, certain environment variables are left intact, such as PATH. However, according to the ENV hash, the PATH variable is empty.
Here is the script (abridged):
#!/usr/bin/perl -w
system('echo "system: $PATH"');
print "perl hash: $ENV{'PATH'}\n";
This is the output when I run env -i test.pl:
system: /usr/local/bin:/bin:/usr/bin
Use of uninitialized value in concatenation (.) or string at test.pl line 4.
perl hash:
How can I get the ENV hash to be correct when I invoke the script under env -i?
The -i option to env does in fact clear $PATH out of the environment. The reason you see inconsistent results from the system call is because of how system works:
If there is only one scalar argument, the argument is checked for
shell metacharacters, and if there are any, the entire argument is
passed to the system's command shell for parsing (this is /bin/sh -c
on Unix platforms, but varies on other platforms). If there are no
shell metacharacters in the argument, it is split into words and
passed directly to execvp , which is more efficient.
Because you are calling system with a single commandline that must be parsed by a shell, one is started, which initializes its own $PATH upon startup (because shells do that), and that's the one you're seeing.
After invoking env -i, certain environment variables are left intact, such as PATH. However, according to the ENV hash, the PATH variable is empty.
On my rhel system, env -i does:
-i, --ignore-environment
start with an empty environment
So when you run the Perl program, the system() call is forking a shell, whic is probably reading an rc file that is setting PATH. but when you print $ENV{PATH} directly form the Perl program, it is empty as expected.
You should either manually set PATH, or determine the full paths to the various executables that you intend to run.
If you're going to spend a lot of time running system() commands, then maybe a shell script, with some Perl to process intermediate results is a better processing model in this case.
How would I determine what script, program, or shell executed my Perl script?
Example: I might want to have human readable output if executed from shell (customized for each type of shell), a different type of output if called as a script from another perl script, and a machine readable format if executed from a program such as a continuous integration server.
Motivation: I have a tool that changes its output based on which shell executes it. I'd normally implement this behavior as an option to the script, but this tool's design doesn't allow for options. Other shells have environment variables that indicate what shell is running. I'm working on a patch to support Powershell, which has no such special variable.
Edit: Many of these answers happen to be linux specific. Unfortuantely, Powershell is for Windows. getppid, the $ENV{SHELL} variable, and shelling out to ps won't help in this case. This script needs to run cross-platform.
You use getppid(). Take this snippet in child.pl:
my $ppid = getppid();
system("ps --no-headers $ppid");
If you run it from the command line, system will show bash or similar (among other things). Execute it with system("perl child.pl"); in another script, e.g. parent.pl, and you will see that perl parent.pl executed it.
To capture just the name of the process with arguments (thanks to ikegami for the correct ps syntax):
my $ppid = getppid();
my $ps = `ps --no-headers -o cmd $ppid`;
chomp $ps;
EDIT: An alternative to this approach, might be to create soft links to your script, make the different contexts use different links to access your script and inspect $0 to build logic around that.
I would suggest a different approach to accomplish your goal. Instead of guessing at the context, make it more explicit. Each use case is wholly separate, so have three different interfaces.
A function which can be called inside a Perl program. This would likely return a Perl data structure. This is far easier, faster and more reliable than parsing script output. It would also serve as the basis for the scripts.
A script which outputs for the current shell. It can look at $ENV{SHELL} to discover what shell is running. For bonus points, provide a switch to explicitly override.
A script which can be called inside a non-Perl program, such as your continuous integration server, and issue machine readable output. XML and/or JSON or whatever.
2 and 3 would be just thin wrappers to format the data coming out of 1.
Each is tailored to fit its specific need. Each will work without heuristics. Each will be far simpler than trying to guess the context and what the user wants.
If you can't separate 2 and 3, have the continuous integration server set an environment variable and look for it.
Depending on your environment, you may be able to pick it up from the environment variables. Consider the following code:
/usr/bin/perl -MData::Dumper -e 'print Dumper(\%ENV);' | grep sh
On my Ubuntu system, it gets me:
'SHELL' => '/bin/bash',
So I guess that says I'm running perl from a bash shell. If you use something else, the SHELL variable may give you a hint.
But let's say you know you're in bash, but perl is run from a subshell. Then try:
/bin/sh -c "/usr/bin/perl -MData::Dumper -e 'print Dumper(\%ENV);'" | grep sh
You will find:
'_' => '/bin/sh',
'SHELL' => '/bin/bash',
So the shell is still bash, but bash has a variable $_ which also show the absolute filename of the shell or script being executed, which may also give a valuable hint. Similarily, for other environments there will most probably be clues left in the perl %ENV hash that should give you valuable hints.
If you're running PowerShell 2.0 or above (most likely), you can infer the shell as a parent process by examining the environment variable %psmodulepath%. By default, it points to the system modules under %windir%\system32\windowspowershell\v1.0\modules; this is what you would see if you examine the variable from cmd.exe.
However, when PowerShell starts up, it prepends the user's default module search path to this environment variable which looks like: %userprofile%\documents\windowspowershell\modules. This is inherited by child processes. So, your logic would be to test if %psmodulepath% starts with %userprofile% to detect powershell 2.0 or higher. This won't work in PowerShell 1.0 because it does not support modules.
This is on Windows XP with PowerShell v2.0, so take it with a grain of salt.
In a cmd.exe shell, I get:
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
whereas in the PowerShell console window, I get:
PSModulePath=E:\Home\user\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsP
owerShell\v1.0\Modules\
where E:\Home\user is where my "My Documents" folder is. So, one heuristic may be to check if PSModulePath contains a user dependent path.
In addition, in a console window, I get:
!::=::\
in the environment. From the PowerShell ISE, I get:
!::=::\
!C:=C:\Documents and Settings\user