Perl command line processing, Windows/dos style ? 
Author Message
 Perl command line processing, Windows/dos style ?

Hi,

I'm trying to get a perl script to behave more like other windows
command line tools, and it is driving me NUTS that I cannot get perl
to simply give me the command line as-is.

As is normal under unix, perl expands the command line automatically.
For instance, when invoking  'scipt.pl'  with as option '*', you'll
get a list of all files in the current directory as arguments.

So I already got used to enclose the arguments with double quotes to
prevent expansion. Not too bad, because if you want to pass paths with
embedded spaces, you have to enclose these with double quotes anyway
to keep the parts together.
But you forget you're dealing with a perl script, and forget the
double quotes, well, anything can happen, as your script gets
arguments that he does not expect.

So you try to be carefull, and use double quotes. But then you try to
pass the argument C:\ as an argument  enclosed by double quotes, so as
"C:\". Doesn't work. The sequence \" is replaced by single quote, and
the argument is concatenated with the next argument: the \" is a way
to include a double quote in a double quoted String. AAARRRGGGGHHHH

I JUST WANT THE COMMANDLINE THE WAY THE USER ENTERS IT!!!!

Anbody a good suggestion?

Thanks  !!!!!

I use (Active)Perl release 5.6.1 under Windows XP.



Fri, 01 Jul 2005 23:46:42 GMT  
 Perl command line processing, Windows/dos style ?

Quote:

>Hi,

>I'm trying to get a perl script to behave more like other windows
>command line tools, and it is driving me NUTS that I cannot get perl
>to simply give me the command line as-is.

>As is normal under unix, perl expands the command line automatically.
>For instance, when invoking  'scipt.pl'  with as option '*', you'll
>get a list of all files in the current directory as arguments.

>So I already got used to enclose the arguments with double quotes to
>prevent expansion. Not too bad, because if you want to pass paths with
>embedded spaces, you have to enclose these with double quotes anyway
>to keep the parts together.
>But you forget you're dealing with a perl script, and forget the
>double quotes, well, anything can happen, as your script gets
>arguments that he does not expect.

>So you try to be carefull, and use double quotes. But then you try to
>pass the argument C:\ as an argument  enclosed by double quotes, so as
>"C:\". Doesn't work. The sequence \" is replaced by single quote, and
>the argument is concatenated with the next argument: the \" is a way
>to include a double quote in a double quoted String. AAARRRGGGGHHHH

>I JUST WANT THE COMMANDLINE THE WAY THE USER ENTERS IT!!!!

Might I ask why? :)
I believe that the expansion of *->filenames (etc.) is not done by perl per se
but by the startup code in the CRT it uses. This means there's not much you
can do about it, unless a batch file of the form

perl.exe script.pl "%*"

will work. Your perl script should then get one argument only, with the entire
command line on; which you can then deal with any way you please.

Ben



Sat, 02 Jul 2005 00:20:57 GMT  
 Perl command line processing, Windows/dos style ?


Quote:
> I'm trying to get a perl script to behave more like other windows
> command line tools, and it is driving me NUTS that I cannot get perl
> to simply give me the command line as-is.

When you says 'foo.pl *' to a shell on Unix the shell will expand the
'*' because it's a shell metacharacter [note: there are many shells, and
they all potentially glob things differently and have different
metacharacters. you could write a shell that did no globbing, if you
wanted.] So, _before_ the perl binary is exec()'d the '*' has been
changed to, most likely, all things in the current directory. That's the
shell doing it. Perl doesn't even _get_ the '*'. It has no idea that's
what the user typed. I don't _know_ what happens in the windows shell
but it appears to be the same sort of deal.

It sounds like you want the "non interpolating" quotes in your shell, so
that whatever is quoted will not be expanded by the shell... which
you'll need to check the docs about, and also you want to know how to
escape such quotes - that'll also be in the docs.

Quote:
> I JUST WANT THE COMMANDLINE THE WAY THE USER ENTERS IT!!!!

It is possible to alter the action associated with your .pl files,
although whether that affects shell metacharacters or not I couldn't say.

So if a user types in:

foo.pl wibble\ bar * " go on< foo.txt

what should the perl script get as its args? One long string containing
the entire command line verbatim? Split on spaces into a number of small
strings? Should the '\ ' be interpreted as a space to split options on,
or not? Should the 'foo.pl ' be removed from the start?

I think the best thing is to see a n example. Have you an example
command line that you want to experiment with? I've got Win2k at work
with activeperl so I can try stuff there, if that's any use.

P

--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply



Sat, 02 Jul 2005 04:20:03 GMT  
 Perl command line processing, Windows/dos style ?

Quote:

> When you says 'foo.pl *' to a shell on Unix the shell will expand the
> '*' because it's a shell metacharacter [note: there are many shells,
> and they all potentially glob things differently and have different
> metacharacters. you could write a shell that did no globbing, if you
> wanted.]

I want to add that common shells (here under Linux) can do different
things if a match fails, and this may even depend on configuration.

[using bash in an empty dir]
$ perl -e 'print shift' *
*
$ shopt -s nullglob
$ perl -e 'print shift' *
$

[using tcsh in an empty dir]

Quote:
> perl -e 'print shift' *
perl: No match.
> set nonomatch=1
> perl -e 'print shift' *

*

(Some newlines inserted for readability.)
So, bash will (per default) happily hand over a non-matching asterisk to
the called program, while the tcsh (per default) issues an error.

Well, I prefer the second behaviour in interactive context, but YMMV.

Ciao,
        Harald
--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Interesting Error Messages #6:
USER ERROR: replace user and press any key to continue.



Sat, 02 Jul 2005 04:58:55 GMT  
 Perl command line processing, Windows/dos style ?


Quote:


> > I'm trying to get a perl script to behave more like other windows
> > command line tools, and it is driving me NUTS that I cannot get perl
> > to simply give me the command line as-is.

> When you says 'foo.pl *' to a shell on Unix the shell will expand the
> '*' because it's a shell metacharacter [note: there are many shells,
and
> they all potentially glob things differently and have different
> metacharacters. you could write a shell that did no globbing, if you
> wanted.] So, _before_ the perl binary is exec()'d the '*' has been
> changed to, most likely, all things in the current directory. That's
the
> shell doing it. Perl doesn't even _get_ the '*'. It has no idea that's
> what the user typed. I don't _know_ what happens in the windows shell
> but it appears to be the same sort of deal.

I believe that you have to do the globbing yourself in windows.


prints the '*' when run in a dos window of ME.

Bill



Sat, 02 Jul 2005 05:26:56 GMT  
 Perl command line processing, Windows/dos style ?

Quote:


>>Hi,

>>I'm trying to get a perl script to behave more like other windows
>>command line tools, and it is driving me NUTS that I cannot get perl
>>to simply give me the command line as-is.

>>As is normal under unix, perl expands the command line automatically.
>>For instance, when invoking  'scipt.pl'  with as option '*', you'll
>>get a list of all files in the current directory as arguments.

>>So I already got used to enclose the arguments with double quotes to
>>prevent expansion. Not too bad, because if you want to pass paths with
>>embedded spaces, you have to enclose these with double quotes anyway
>>to keep the parts together.
>>But you forget you're dealing with a perl script, and forget the
>>double quotes, well, anything can happen, as your script gets
>>arguments that he does not expect.

>>So you try to be carefull, and use double quotes. But then you try to
>>pass the argument C:\ as an argument  enclosed by double quotes, so as
>>"C:\". Doesn't work. The sequence \" is replaced by single quote, and
>>the argument is concatenated with the next argument: the \" is a way
>>to include a double quote in a double quoted String. AAARRRGGGGHHHH

>>I JUST WANT THE COMMANDLINE THE WAY THE USER ENTERS IT!!!!

>Might I ask why? :)
>I believe that the expansion of *->filenames (etc.) is not done by perl per se
>but by the startup code in the CRT it uses. This means there's not much you
>can do about it, unless a batch file of the form


>perl.exe script.pl "%*"

>will work. Your perl script should then get one argument only, with the entire
>command line on; which you can then deal with any way you please.

Hmm, I knew this was messy wehen I wrote it :)

It fails on embedded ", of course.

The right answer is to use Win32::API to get at GetCommandLine out of
kernel32.dll, which will return your command line, un{*filter*}eated.

Ben



Sat, 02 Jul 2005 16:56:34 GMT  
 Perl command line processing, Windows/dos style ?
On Tue, 14 Jan 2003 04:58:55 +0100, "Harald H.-J. Bongartz"

Quote:

>I want to add that common shells (here under Linux) can do different
>things if a match fails, and this may even depend on configuration.

[...]

Quote:
>So, bash will (per default) happily hand over a non-matching asterisk to
>the called program, while the tcsh (per default) issues an error.

I want to add that it depends on an option too. Bash can be instructed
to "expand" a non matching pattern to an empty string instead...

Michele
--

Quote:
>It's because the universe was programmed in C++.

No, no, it was programmed in Forth.  See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel on sci.math, thread "Why numbers?"


Sat, 02 Jul 2005 23:32:20 GMT  
 Perl command line processing, Windows/dos style ?
Quote:

> On Tue, 14 Jan 2003 04:58:55 +0100, "Harald H.-J. Bongartz"

> I want to add that common shells (here under Linux) can do different
> things if a match fails, and this may even depend on configuration.

                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]

Quote:
> I want to add that it depends on an option too. Bash can be instructed
> to "expand" a non matching pattern to an empty string instead...

Read my posting again and see the (empty) result when setting
"shopt -s nullglob". ;-)

Ciao,
        Harald
--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
++$sheep while !$asleep;



Sat, 02 Jul 2005 23:48:17 GMT  
 Perl command line processing, Windows/dos style ?


Quote:


> > shell doing it. Perl doesn't even _get_ the '*'. It has no idea that's
> > what the user typed. I don't _know_ what happens in the windows shell
> > but it appears to be the same sort of deal.

> I believe that you have to do the globbing yourself in windows.


> prints the '*' when run in a dos window of ME.

Ah, we have Win 200 Pro at work and the globbing seems to be done by the
shell under that system. It was one of the things I checked in the User
Acceptance Tests, IIRC.

P

--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply



Sun, 03 Jul 2005 03:20:03 GMT  
 Perl command line processing, Windows/dos style ?
On Tue, 14 Jan 2003 23:48:17 +0100, "Harald H.-J. Bongartz"

Quote:

>Read my posting again and see the (empty) result when setting
>"shopt -s nullglob". ;-)

Sorry, you're right: I just missed that; no pun intended anyway, and
probably no harm done stressing the point...

Michele
--

Quote:
>It's because the universe was programmed in C++.

No, no, it was programmed in Forth.  See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel on sci.math, thread "Why numbers?"


Sun, 03 Jul 2005 10:27:02 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Any examples of assembly line style processing?

2. command-line args style flags from a file

3. Help: perl for DOS variable=something on command line

4. Using Perl in Windows Command Line

5. Command Line Switches in Windows Perl??

6. basic query about command line processing in Perl

7. Question: Perl for Windows command line args?

8. UNIX fix_cr command exits something in DOS / Windows ?

9. Nixing the DOS/Command Window under Windows ?

10. Nixing the DOS/Command Window under Windows ?

11. Using perl5 with Win95/dos command line.

12. DOS: command line wildcards

 

 
Powered by phpBB® Forum Software