How do I send a value that starts with a dash to Getopt::Long? - perl

I've got a client-side script I'm making that communicates with GNU-FTP. I want to be able to send it a custom argument on the command line, so I've created an argument --ftp-args
This is what it looks like
GetOptions(
.. redacted stuff..
"ftp-args=s%" => \$FTP_ARGS
) or die("Error in command line arguments\n");
However, whenever I try to call it I get an error,
$ ./script/dm-ftp360 --ftp-args="-E"
Option ftp-args, key "-E", requires a value
Error in command line arguments
Is it possible to get around this, and make this possible?

You've specified s% - defining an option that specifies hash entries. That implies a form key=value for each argument to the option. But you've only specified -E. The error message is about the missing =value part, not the leading -.
Perhaps use s# instead to ingest a set of simple options? Or give an empty value using "-E=" if you need to separate the keys and values before passing them to ftp.

Related

Weechat add hook command in every send Messages

I am a new user in Weechat. I have made a customized weechat script from another existing script. To run that script I need to use hook command every time i send text to channel . For example /myhook message_to_channel . I want to automate this process so every time I send messages to a channel i wouldn't need to write /myhook but just message_to_channel . Is there any way I could make it happen. Thanks.
The alias plugin that is included in WeeChat by default can facilitate this.
You can run the following command to create the alias you want.
/alias add message_to_channel /myhook message_to_channel
After that, you should be able to just use /message_to_channel. You can also add arguments if you like:
$n: argument 'n' (between 1 and 9)
$-m: arguments from 1 to 'm'
$n-: arguments from 'n' to last
$n-m: arguments from 'n' to 'm'
$*: all arguments
$~: last argument
$var: where "var" is a local variable of buffer (see /buffer localvar)
examples: $nick, $channel, $server, $plugin, $name
The documentation is here.

Calling a shell command with multiple arguments

I'm trying to automate creating certificates via a Perl script.
The command I want to run is:
easyrsa build-client-full $clientname nopass
The way I thought it should be done in Perl is:
my $arguments = ("build-client-full $clientname nopass");
my $cmd = "$easyrsa_path/easyrsa"." "."$arguments";
system("bash", $cmd);
However, this yields
"file not found"
on execution. I triple checked that the path is correct.
If I try it like this:
my #arguments = ("bash", $easyrsa_path,"build-client-full $clientname nopass");
system(#arguments);
Bash returns
"Unknown command 'build-client-full test nopass'. Run without commands
for usage help."
Background
When you use system(LIST) where LIST has more than one element, Perl will not call the shell, and instead directly invoke the program given by the first element in the LIST, and use the rest of the list as command line arguments to be passed verbatim, with no interpolation by the shell, including no splitting arguments on whitespace.
So in your first example, Perl is running the command bash and passing the string "$easyrsa_path/easyrsa build-client-full $clientname nopass", literally as one big long argument, and in your second example, it's running the command bash and passing the two arguments $easyrsa_path and "build-client-full $clientname nopass". However, I assume that easyrsa needs the three arguments as separate strings in its argument list, which the shell would normally split, but since both of your calls to system aren't using the shell, it's not working.
system (and exec) have four ways of interpreting their arguments, as per the documentation:
If you pass a single string (including a LIST with only one element) that does not contain any shell metacharacters, it is split into words and passed directly to execvp(3) (meaning it bypasses the shell).
Warning: This invocation is easily confused with the following - a single metacharacter will cause the shell to be invoked, which can be dangerous especially when unchecked variables are interpolated into the command string.
If you pass a single string (including a LIST with only one element) that does contain shell metacharacters, the entire argument is passed to the system's command shell for parsing. Normally, that's /bin/sh -c on Unix platforms, but the idea of the "default shell" is problematic, and there is certainly no guarantee that it'll be bash (though it could be).
Warning: In this invocation of system, you have the full power of the shell, which also means you're responsible for correctly quoting and escaping any shell metacharacters and/or whitespace. I recommend you only use this form if you explicitly want the power of the shell, and otherwise, it's usually best to use one of the following two.
If there is more than one argument in LIST, this calls execvp(3) with the arguments in LIST, meaning the shell is avoided.
(See below for caveats on Windows.)
The form system {EXPR} LIST always runs the program named by EXPR and avoids the shell, no matter what's in LIST.
(See below for caveats on Windows.)
The latter two are desirable if you want to pass special characters that the shell would normally interpret, and I'd actually always recommend doing this, since blindly passing user input into system can open up a security hole - I wrote a longer article about that over on PerlMonks.
Solutions
#Borodin and #AnFi have already pointed out: If you simply split up the elements of the LIST properly, it should work - it doesn't look like you need any features of bash or any shell here. And don't forget to check for errors!
system("$easyrsa_path/easyrsa","build-client-full",$clientname,"nopass") == 0
or warn "system failed: \$? = $?";
Note that there are good modules that provide alternatives to system and qx, my go-to module is usually IPC::Run3. These modules are very helpful if you want to capture output from the external command. In this case, IPC::System::Simple might be easier since it provides a drop-in replacement for system with better error handling, as well as systemx which always avoids the shell. (That module is what autodie uses when you say use autodie ':all';.)
use IPC::System::Simple qw/systemx/;
systemx("$easyrsa_path/easyrsa","build-client-full",$clientname,"nopass");
Note that if you really wanted to call bash, you'd need to add the -c option and say system("bash","-c","--","$easyrsa_path/easyrsa build-client-full $clientname nopass"). But as I a said above, I strongly recommend against this, since if $easyrsa_path or $clientname contain any shell metacharacters or malicious content, you may end up having a huge problem.
Windows
Windows is more complicated than the above. The documentation says that the only "reliable" way to avoid calling the shell there is the system PROGRAM LIST form, but on Windows, command line arguments are not passed as a list, but a single big string, and it's up to the called command, not the shell, to interpret that string, and different commands may do that differently - see also. (I have heard good things about Win32::ShellQuote, though.)
Plus, there's the special system(1, #args) form documented in perlport.
If you pass multiple parameters to system then each one forms a separate parameter to the command line. So it is as though you had entered
easyrsa "build-client-full test nopass"
and you correctly get the error
Unknown command 'build-client-full test nopass'
You also don't need to add bash: perl will run the shell for you if necessary
You can either pass the whole command to system
system($cmd)
and perl will pass it to the shell to be processed as if you'd entered it at the command prompt. Or you can split the parameters properly
system("$easyrsa_path/easyrsa", "build-client-full", $clientname, "nopass")
which will make perl call easyrsa directly unless the command contains things that need the shell to process, like output redirection

How to print variable inside function

I'm using RRDs::Simple function and it needs bunch of parameters.
I have placed these parameters in a special variable (parsing, sorting and calculating data from a file) with all quotes, commas and other stuff.
Of course
RRDs::create ($variable);
doesn't work.
I've glanced through all perl special variables and have found nothing.
How to substitute name of variable for the data that contained in that variable?
At least could you tell me with what kind of tools(maybe another special variables) it can be done?
Assuming I'm understanding what you're asking:
You've build the 'create' data in $variable, and are now trying to use RRDs::create to actually do it?
First step is:
print $variable,"\n"; - to see what is actually there. You should be able to use this from the command line, with rrdtool create. (Which needs a filename, timestep, and some valid DS and RRA parameters)
usually, I'll use an array to pass into RRDs::create:
RRDs::create ( "test.rrd", "-s 300",
"DS:name:GAUGE:600:U:U", )
etc.
If $variable contains this information already, then that should be ok. The way to tell what went wrong is:
if ( RRDs::error ) { print RRDs::error,"\n"; }
It's possible that creating the file is the problem, or that your RRD definitions are invalid for some reason. rrdtool create on command line will tell you, as will RRDs::error;

Passing a variable to a command in a script

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.

'unexpected token' in PowerShell when fully pathing executable

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"