Quick question... I'm trying the following:
set changedir "cd $JSDIR/"
eval $changedir
..Where $JSDIR is defined already. Running this script gives the error: "set: Variable name must begin with a letter."
What's the fix?
Thanks.
That's not an error message generated by Tcl, because Tcl's variables most definitely do not need to begin with a letter. OK, it tends to be convenient to keep them alphanumeric because the $var shorthand syntax is more restrictive than the general space of variable names, but the set var form can handle virtually anything.
I'm guessing that script is being evaluated by something that isn't Tcl, perhaps bash?
Try to set changedir cd ${JSDIR/} instead
This message can appear when in fact the variable name is entirely correct, and the real problem is that the variable value needs to be quoted. Try instead of: set changedir "cd $JSDIR//"
Related
I am currently working on a project but I have one big problem. I have some picture with a whitespace in the name and I want to do a montage. The problem is that I can't rename my picture and my code is like that :
$pic1 = qq(picture one.png);
$pic2 = qq(picture two.png);
my $cmd = "C:\...\montage.exe $pic1 $pic2 output.png";
system($cmd);
but because of the whitespace montage.exe doesn't work. How can I execute my code without renaming all my pictures?
Thanks a lot for your answer!
You can properly quote the filenames within the string you pass to system, as #Borodin shows in his answer. Something like: system("montage.exe '$pic1' '$pic2'")
However, A more reliable and safer solution is to pass the arguments to montage.exe as extra parameters in the system call:
system('montage.exe', $pic2, $pic2, 'output.png')
Now you don't have to worry about nesting the correct quotes, or worry about files with unexpected characters. Not only is this simpler code, but it avoids malicious injection issues, should those file names ever come from a tainted source. Someone could enter | rm *, but your system call will not remove all your files for you.
Further, in real life, you probably are not going to have a separate scalar variable for each file name. You'll have them in an array. This makes your system call even easier:
system('montage.exe', #filenames, 'output.png')
Not only is that super easy, but it avoids the pitfall of having a command line too long. If your filenames have nice long paths (maybe 50-100 characters), a Windows command line will exceed the max command length after around 100 files. Passing the arguments through system() instead of in one big string avoids that limitation.
Alternatively, you can pass the arguments to montage.exe as a list (instead of concatenating them all into a string):
use strict;
use warnings;
my $pic1 = qq(picture one.png);
my $pic2 = qq(picture two.png);
my #cmd = ("C:\...\montage.exe", $pic1, $pic2, "output.png");
system(#cmd);
You need to put quotes around the file names that have spaces. You also need to escape the backslashes
my $cmd = qq{C:\\...\\montage.exe "$pic1" "$pic2" output.png};
In unix systems, the best approach is the multi-argument form of system because 1) it avoids invoking a shell, and 2) that's the format accepted by the OS call. Neither of those are true in Windows. The OS call to spawn a program expects a command line, and system's attempt to form this command line is sometimes incorrect. The safest approach is to use Win32::ShellQuote.
use Win32::ShellQuote qw( quote_system );
system quote_system("C:\\...\\montage.exe", $pic1, $pic2, "output.png");
Using fish shell, I'm writing very simple script that checks the command execution
#!/usr/bin/fish
command
if $status
echo "Oops error"
else
echo "Worked OK"
#...
end
And get the error message:
fish: Variables may not be used as commands. Instead, define a function like “function status; 0 $argv; end”. See the help section for the function command by typing “help function”.
The message looks pretty straight forward but no "defining function like..." nor "help function" helps solving the problem.
There is also a 'test' command, that sounds promising. But docs say it is to be used to check files...
How this simple thing should be done with fish shell?
Heh... And why all documentation is SO misleading?..
P.S. Please, don't write about 'and' command.
Fish's test command currently works exactly like POSIX test (i.e. the one you'll find in bash or similar shells). It has a couple of operations, including "-gt", "-eq", "-lt" to check if a number is bigger, equal or less than another number, respectively.
So if you want to use test, you'll do if test $status -eq 0 (a 0 traditionally denotes success). Otherwise, you can check the return value of a command by putting it in the if clause directly like if command (which will be true if the command returns 0) - that's what fish is trying to do here, which is why it complains about a variable being used in place of a command.
I've been searching all over the place and since I'm taking my first steps in PERL this might be one of he dumbest questions but here it goes.
So I'm creating a script to manage my windows and later bind it to keyboard shortcuts, so I I'm trying to run a command and passing some variables:
my $command = `wmctrl -r :ACTIVE: -e 0,0,0,$monitors->{1}->{'width'}/2,$monitors->{1}->{'height'}`;
But I get an error saying I'm not passing the right parameters to the command, but if I do this, everything works great:
my $test = $monitors->{1}->{'width'}/2;
my $command = `wmctrl -r :ACTIVE: -e 0,0,0,$test,$monitors->{1}->{'height'}`;
So do I really have to do this? assign it first to a variable and then pass it, or there's a more elegant way of doing it?
The backticks operator (or the qx{}) accepts A string which is (possibly) interpolated. So accepts string and not expression like $var/2.
Thats mean than the $variables ($var->{1}->{some} too) are expanded but not the arithmetic expressions.
Therefore your 2 step variant works, but not the first.
If you want evaluate an expression inside the string you can use the next:
my $ans=42;
print "The #{[ $ans/2 ]} is only the half of answer\n";
prints
The 21 is only the half of answer
but it is not very readable, so better and elegant is what you're already doing - calculate the command argument in andvace, and to the qx{} or backticks only pass the calculated $variables.
I'm trying to set a variable I previously set in a Perl script as an environment variable, but it seems to not realize the parameter I'm passing in is a variable and not the actual path I want.
For example, when I run this:
$ENV{'ENV_VARIABLE'}='\'$file_path\'';
print($ENV{'ENV_VARIABLE'});
I only get:
'$file_path'
Is there any way I can tell it that what I'm passing in is actually a variable and not a literal string?
In Perl, single quoted strings do not interpolate variables. You want to use a double quote:
$ENV{'ENV_VARIABLE'}= "'$file_path'";
In that line, the rvalue is interpreted as q{'} . $file_path . q{'} where q{'} is a fancy way of writing '\'', which is a bit harder to read.
Just trying to better understand why the second item below does not work. The first item is simple, the second seems clearer, the third seems unintuitive.
# My path includes pscp so this works.
pscp.exe -i $PRIVATE_KEY $file ${PROXY_USER}#${PROXY_HOST}:${PROXY_DIR}
# This does not work. I get unexpected token error. Why? What does that mean?
$PUTTY_PATH\pscp.exe -i $PRIVATE_KEY $file ${PROXY_USER}#${PROXY_HOST}:${PROXY_DIR}
# & is required to solve the problem.
& "$PUTTY_PATH\pscp.exe" -i $PRIVATE_KEY $file ${PROXY_USER}#${PROXY_HOST}:${PROXY_DIR}
That's because this is also considered a parse error:
"foo"\pscp.exe
Whereas this parses correctly as you have found:
"$PUTTY_PATH\pscp.exe"
That resolves to a valid string but as you have already noticed, a string doesn't execute. You have to use the call operator & to invoke the command that is named by the string that follows.
It's taking the \ to be part of the variable name, and complains because it is not legal. If you are using this snippet like i would, by putting it into a .ps1 file in your path, then i would just cd over to $putty_path if you don't want to have pscp.exe in your global PATH env var.
Just guessing, but I have a feeling you might be misusing the curly braces. Are you trying to get the environment variable PROXY_USER instead? Typically the curly brackets are used for starting a new statement block.
$Env:PROXY_USER
Also, you may want to encapsulate that proxy info inside a string to ensure it is treated as a single argument:
"$Env:PROXY_USER#$Env:PROXY_HOST:$Env:PROXY_DIR"