Andy Bach wrote:
> :> Due to odd quoting rules, I suggest using "" on Windows, and '' on
> UNIX. Choose to use qq() or q() instead of escaping for either.
> Well, not trying to inflame the winx v *nix wars soYMMV but I've
> always had troubles getting command line scripts to run in cmd.exe
> C:\Documents and Settings\andy>perl -e 'print("Hello world.\n");'
The rules are different. Even on UNIX, CSH vs SH is different. Try
adding ! into your command line from CSH and see confusing results... :-)
csh> perl -e 'print !1'
1: Event not found.
It isn't UNIX vs Windows as much as knowing the rules of the shell you
are using.
For Windows, the rules are pretty simple. The only recognized quotes are
double quotes (""). Backslashes within quotes are passed through unless
an odd number of backslashes precede the closing double quote, in which
case, the double quote is considered escaped. If a %VARIABLE% occurs
anywhere in the string it is substituted with the environment variable
that it matches.
I'm too tired right now to describe the UNIX rules. CSH vs SH vs KSH vs
ZSH vs ... they are all slightly different.
Storing the script to a file is definitely best.
> A different issue on *nix is '$' interpolation. This works on winx
> (note dbl quotes script surrounders):
> perl -e "$hi = qq(Hello world.\n); print $hi"
Try:
C:\> perl -e "print %PATH%, qq(\n)"
Granted, %PATH% is less likely to be used in a Perl command line - but
the point remains that interpolation is a problem no matter which shell
you use. :-)
> That one gets a different error on winx
> C:\Documents and Settings\andy>perl -e '$hi = qq(Hello world.\n);
> print $hi'
> Can't find string terminator "'" anywhere before EOF at -e line 1.
> I think the semicolon acts as a line ending or comment, maybe? But
> this is the sort of error that made me give up on winx cmd lines
> scripting.
The history here is that cmd.exe has odd interpretation rules. First
off, cmd.exe does not know much about quotes, and definately knows
nothing about single quotes (''). As far as cmd.exe is concerned, you
are calling:
perl -e "'$hi" "=" "qq(Hello" "world.\n)"; print "$hi'"
On Windows, however, the calling shell (cmd.exe) does not break the
arguments up into argv. Instead, it passes the entire command line (up
to the newline or semicolon or a few other characters) to the program as
a single string. It is then up the program to break up the arguments as
it sees fit. Perl is based on Windows libc which emulates argv splitting
according to UNIX rules.
The effect of this is that you have cmd.exe using one set of rules, and
then perl.exe using a different set of rules. Where the rules are
compatible, behaviour is "expected". Where the rules are incompatible,
people can easily become confused if they do not know both rules.
Places where this can be a problem? Try doing shell globbing on Windows
and be confused as to why:
C:\> perl test.pl *.txt
Does not always work. CMD.EXE doesn't expand *.txt. This is up to the
program - perl.exe. If perl.exe does not expand it? It doesn't get expanded.
Some fun information for people to think about... :-)
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
