Help needed in handling special char in cmdline 1

[whn]

My testing code:

if($ARGV[0] eq "\?" || $ARGV[0] eq "?" || $ARGV[0] eq '\?' || $ARGV[0] eq '?') {
  &usage;
}
elsif($ARGV[0] eq "\'" || $ARGV[0] eq "'" || $ARGV[0] eq '\'' ||
  $ARGV[0] eq '\"' || $ARGV[0] eq '"' || $ARGV[0] eq '\"') {
  print "Invalid char passed in from cmdline: #$ARGV[0]#\n";
}
else {
  print "==-->>\$ARGV[0] = #$ARGV[0]#\n";
}
exit;

sub usage {
  print "In usage().\n";
  exit;
}

Test runs:

[Linux|bash] 50 => ./a.pl ?
==-->>$ARGV[0] = #a#
[Linux|bash] 51 => ./a.pl '
>
[Linux|bash] 51 => ./a.pl "
>

Qustions:

1) How come that a question mark becomes a letter 'a'?
2) what is the correct implementation to treat a double quote " & a single quote ' as a plain character in cmdline?

Thanks!

 

[KevinADC]

probably on Linux the single-quotes would be seen as quoting the arguments you pass the script and not as part of the argument. Double-quotes would be passed in as part of the arguments and so would a ? mark which is nothing special on the command line that I am aware of. It might help to show what your command line looks like.

------------------------------------------
- Kevin, perl coder unexceptional!

 

[whn]

Thank you, Kevin.

I already show my cmdlind in my original post (I named my code as a.pl). would you please take one more look?

 

[prex1]

Can't understand the substitution of ?: on my system it doesn't. You should try other combinations to see what it does: seems it is somehow greped with the filename. Anyway if you surround it with quotes (single or double) it should work.
Concerning the quotes, simply surround any text containing single quotes with doubles and viceversa.

Franco

http://www.xcalcs.com

: Online engineering calculations

http://www.megamag.it

: Magnetic brakes for fun rides

http://www.levitans.com

: Air bearing pads

 

[PinkeyNBrain]

1) How come that a question mark becomes a letter 'a'?

Your bash shell is interpreting the '?' to represent all files that have one letter names. Try the command "ls ?" and you'll see what is happening (definately reply if still unclear)

2) what is the correct implementation to treat a double quote " & a single quote ' as a plain character in cmdline?

Again you have to keep in mind your shell. To experiment try the commands

echo "'"
echo \'
echo '"'
echo \"
echo /'

and you'll see what things look like after the shell is done with it. That last one will likely put you into your secondary prompt, just add the closing quote and you'll drop out of it. Note that the behaviors you see may differ between the different shells (bash, sh, ksh, csh, etc)


I've (unfortunately) been out of the *-nix loop for a while and may not be on the money with this comment but, isn't is common practice under this OS genre to use a leading - (the minus sign) to pass arguments?
e.g. ./a.pl -? and/or ./a.pl -help

 

[whn]

Thank you, Pinkey and prex!

I tried other shells and they all have the same or similar behaviors, which I have never noticed before.

Though I have already implemented this cli with -h for help, the code should be able to handle anything that a user passed in, right? So, how can I handle the single/double quotes gracefully? I'd guess there must be a way to do it.

Thanks again.

 

[PinkeyNBrain]

... the code should be able to handle anything that a user passed in, right?

For the most part I agree, however to what extent is a call the programmer has to make (and/or what is buried in the requirements doc). In your specific case, if the user enters "./a.pl ?", it is out of your hands, the shell is acting on the ? before you can get to it. Likewise if the user types quotes, backslashes, pipes, IO redirection symbols, and other creatures that the bash wants to act upon.

An option I've had to resort to (in some cases) looks like:

while (1) {
   &print_option_list();
   $option = <STDIN> ;
   last if ($option =~ /stop|quit|bye|end|exit|qq/i);
   &process_option($option);
}

When you're reading from within the perl shell, bash is far enough in the background that it won't play around with what you're typing. The above approach however diminishes the convenient command line interface (not entirely gone, but reduced). This is just my opinion but when in Rome, use the common lingo. If you're on **-nix, use - symbols to signify program options. If Win-**, use /'s, etc.