I have a simple system command to copy file from one folder to another:
my $cmd = "xcopy /Y c:\DBs\Support\db.bak c:\jenkins\workdir\sql-bak-files";
When I try to run the following system commands, all fails:
1. my $res = qx/$cmd/;
2. my $res = qx($cmd);
3. using back ticks
All tries returned the error: Error number -1, error message: "Bad file descriptor".
When trying to use system($cmd) the error was Error number 65280, error message: "No such file or directory".
This perl code is running via Jenkins (ver 2.190.1) and perl v5.26.0.
This problem started after migrating the code from mercurial to git, but I don't think it's related.
It worked before, but now always fail :(
A backslash has a special meaning in a Perl quoted string. It is used to escape the following character - to "turn off" any special meaning. If you want to use a backslash in a Perl quoted string, then you need to use another backslash to escape it.
my $cmd = 'xcopy /Y c:\\DBs\\Support\\db.bak c:\\jenkins\\workdir\\sql-bak-files';
Alternatively, Perl recognises forward slashes in Windows paths, so it might be easier to replace your code with this:
my $cmd = 'xcopy /Y c:/DBs/Support/db.bak c:/jenkins/workdir/sql-bak-files';
Note that in both cases I have replaced your double-quotes with single-quotes. This has no effect on your problem, but it seems strange to use double-quoted strings if you're not using any of their special characteristics (like the expansion of variables).
Update: To debug a problem like this, you can try printing the string.
$ perl -E'say "xcopy /Y c:\DBs\Support\db.bak c:\jenkins\workdir\sql-bak-files"'
xcopy /Y c:DBsSupportdb.bak c:jenkinsworkdirsql-bak-files
Related
How do I handle a folder name containing spaces in Perl? For example C:\Sample Picture\Data.
I wrote this
use File::Glob ':glob';
$indir = "C:\\Sample Picture\\Data\\";
#flist = bsd_glob( $indir.'*');
This is throwing an error
The syntax of the command is incorrect.
The error message The syntax of the command is incorrect comes from the Windows command line, not from Perl
The issue is not to do with File::Glob, but with whatever you are doing with the contents of #flist. It's my guess that you're using backticks or system to rename one or more of the files or directories. This will fail if you use paths that contain spaces without enclosing the complete path in double quotes
If you need any more help then you must show the relevant part of your code
I am writing a Perl script to do a secure file transfer using SSH sftpg3.exe
But I am having issue to accessing the source file.
the script able to pick the file from C:\xx\t.txt while running it from the directory
It is not showing error C:\Program is not a valid command.
my $sftpPath="C:\\Program Files\\client";
my $srcPath="C:\\xx\\test.txt";
my $trgCommand=$sftpPath." -D $srcPath user#host:/tmp/";
my $result=system("$trgCommand");
while running this script from C:\ directory it is running without error but I can not see the file in destination server.
Could you please help me sort out this file path issue ?
I want to run it from O:\ and it will pick the target file and sftpg3.exe from C:\ drive and do the file transfer (in ASCII mode) successfully.
try the below code
my $cmd="sftpg3.exe " . "$src_path user#host:";
system("C:\\Program Files\\Client\");
system($cmd);
Thanks.
You might have interpolation of #host in your third line because you are using double quotes (""). Do you have use strict and use warnings turned on? There might also be an issue with the space () in the path.
use strict;
use warnings;
use feature 'say';
my $sftp_path = q{"C:\Program Files\Client\sftpg3.exe"};
my $src_path = 'C:\xx\test.txt';
my $result = system( $sftp_path, '-D', $src_path, 'user#host:/tmp/' );
say $result;
Let's look at what I did.
When you tab-complete a path like C:\Program Files\foo in Windows cmd, it usually wraps them in double quotes if there is a space inside the path. So we use the q operator, which is equivalent to single quotes, and put double quotes inside. That also gives us the benefit that we don't have to escape the backslash \. Also see quote-like operators in perlop.
Same goes for the source path.
system allows you to pass all the arguments to the program you want to run as arguments to itself and will take care of the quoting
The double quote in "user#host:" will try to expand #host as an array. That doesn't work, because it's not defined. So there's a warning that you probably didn't see because you did not use strict and use warnings. Instead of the double quotes, use single quotes.
I used $sftp_path instead of $sftpPath because there is a convention in Perl to use underscores and no capital letters. We like camels, but not in our variable names. :)
If I execute the following command on a Windows 8.1 machine:
robocopy "C:\Temp\A\" "C:\Temp\B\"
Robocopy fails due to the following problem:
Source : C:\Temp\A" C:\Temp\B"\
Dest -
...
ERROR : No Destination Directory Specified.
It looks like \ is used as some kind of escape character (which is not normal behavior in the windows command line) The final \" is even transformed to "\ which I do not understand at all. Why's that so?
Note: this is not the default behavior of the command line, if they would have used argv[1] and argv[2] within robocopy, they would've retrieved the correct arguments.
Why are they using their own command line parsing? It really confused me for the last hour...
You should omit the trailing backslashes.
From http://ss64.com/nt/robocopy.html :
If either the source or destination are a "quoted long foldername" do
not include a trailing backslash as this will be treated as an escape
character, i.e. "C:\some path\" will fail but "C:\some path\\" or
"C:\some path." or "C:\some path" will work.
robocopy is not an exception. Any executable uses its own line parser to determine the arguments that were sent to it. The OS just uses the API to create the process and pass to it a string to be handled as arguments. The process can handle the string as it wants.
In the case of robocopy, the parser used is the standard Microsoft C startup code. This parser follow the rules described here, and in the full list you can found
A double quotation mark preceded by a backslash, \", is interpreted as
a literal double quotation mark (").
I want to open a text file in notepad++ in a particular line number. If I do this in cmdline the command should be:
start notepad++ "F:\Path\test.txt" -n100
And it is working fine from command line. Now I have to do this from tcl. But I can't make this command work with exec. When I try to execute this:
exec "start notepad++ \"F:\Path\test.txt\" -n100"
I am getting this error:
couldn't execute "start notepad++ "F:\Path\test.txt" -n100": no such file or directory.
What am I missing. Please guide.
Similar to this question:
exec {*}[auto_execok start] notepad++ F:/Path/test.txt -n10
First, you need to supply each argument of the command as separate values, instead of a single string/list. Next, to mimic the start command, you would need to use {*}[auto_execok start].
I also used forward slashes instead of backslashes, since you would get a first level substitution and get F:Path est.txt.
EDIT: It escaped me that you could keep the backslashes if you used braces to prevent substitution:
exec {*}[auto_execok start] notepad++ {F:\Path\test.txt} -n10
You can simply surround the entire exec statement in curly braces. Like this:
catch {exec start notepad++.exe f:\Path\test.txt -n10}
I haven't found a perfect solution to this yet. All my execs seem to be different from each other. On windows there are various issues.
Preserving double quotes around filename (or other) arguments.
e.g. in tasklist /fi "pid eq 2060" /nh the quotes are required.
Preserving spaces in filename arguments.
Preserving backslash characters in filename arguments.
[Internally, Windows doesn't care whether pathnames have / or \, but some programs will parse the filename arguments and expect the backslash character].
The following will handle the backslashes and preserve spaces, but will not handle double-quoted arguments. This method is easy to use. You can build up the command line using list and lappend.
set cmd [list notepad]
set fn "C:\\test 1.txt"
lappend cmd $fn
exec {*}$cmd
Using a string variable rather than a list allows preservation of quoted arguments:
set cmd [auto_execok start]
append cmd " notepad"
append cmd " \"C:\\test 1.txt\""
exec {*}$cmd
Note that if you need to supply the full path to the command to be executed, it often needs to be quoted also due to spaces in the pathname:
set cmd "\"C:\\Program Files\\mystuff\\my stuff.exe\" "
I'm confronted with a rather strange problem an echo command causes in a script.
It's supposed to be really REALLY basic stuff, but still, there's something "off".
Suppose, I have this script:
#!/bin/bash
# SERVERPID='cat lite_server_pid.txt'
# kill -9 $SERVERPID
nohup java -Xmx3G -Xms2G -jar tekkit_lite_065.jar nogui > output.txt &
echo $! > lite_server_pid.txt
Yes, this starts my own little Minecraft/Tekkit-Server. ;-)
The Problem is, the file thats created is (for some reason) named
lite_server_pid.txt?
and YES, this includes the "?"! Doing the same command in shell, a file without ? is correctly created! Also, the content of the file is the desired processID.
Still, the ? following the filename is a major problem...
What am I doing wrong?
Check your file for DOS line endings. I suspect that ? is actually your terminal's attempt to display a carriage return (\r). Since bash expects UNIX-style newlines, the carriage return part of the DOS newline (\r\n) is treated as a legal character for the file name.
Run your script through dos2unix.