在C中编写可移植的命令行包装器

Question

I'm writing a perl module called perl5i . Its aim is to fix a swath of common Perl problems in one module (using lots of other modules).

To invoke it on the command line for one liners you'd write: perl -Mperl5i -e 'say "Hello"' I think that's too wordy so I'd like to supply a perl5i wrapper so you can write perl5i -e 'say "Hello"' . I'd also like people to be able to write scripts with #!/usr/bin/perl5i so it must be a compiled C program.

I figured all I had to do was push "-Mperl5i" onto the front of the argument list and call perl. And that's what I tried.

#include <unistd.h>
#include <stdlib.h>

/*
 * Meant to mimic the shell command
 *     exec perl -Mperl5i "$@"
 *
 * This is a C program so it works in a #! line.
 */

int main (int argc, char* argv[]) {
    int i;
    /* This value is set by a program which generates this C file */
    const char* perl_cmd = "/usr/local/perl/5.10.0/bin/perl";
    char* perl_args[argc+1];
    perl_args[0] = argv[0];
    perl_args[1] = "-Mperl5i";

    for( i = 1;  i <= argc;  i++ ) {
        perl_args[i+1] = argv[i];
   }

   return execv( perl_cmd, perl_args );
}

Windows complicates this approach. Apparently programs in Windows are not passed an array of arguments, they are passed all the arguments as a single string and then do their own parsing! Thus something like perl5i -e "say 'Hello'" becomes perl -Mperl5i -e say 'Hello' and Windows can't deal with the lack of quoting.

So, how can I handle this? Wrap everything in quotes and escapes on Windows? Is there a library to handle this for me? Is there a better approach? Could I just not generate a C program on Windows and write it as a perl wrapper as it doesn't support #! anyway?

UPDATE: Do be more clear, this is shipped software so solutions that require using a certain shell or tweaking the shell configuration (for example, alias perl5i='perl -Mperl5i' ) aren't satisfactory.

Answer 1

For Windows, use a batch file.

perl5i.bat

@echo off
perl -Mperl5i %*

%* is all the command line parameters minus %0 .

On Unixy systems, a similar shell script will suffice.

Update:

I think this will work, but I'm no shell wizard and I don't have an *nix system handy to test.

perl5i

#!bash

perl -Mperl5i $@

Update Again:

DUH! Now I understood your #! comment correctly. My shell script will work from the CLI but not in a #! line, since #!foo requries that foo is a binary file.

Disregard previous update.

It seems like Windows complicates everything. I think your best there is to use a batch file.

You could use a file association , associate .p5i with perl -Mperl5i %* . Of course this means mucking about in the registry, which is best avoided IMO. Better to include instructions on how to manually add the association in your docs.

Yet another update

You might want to look at how parl does it.

Answer 2

I can't reproduce the behaviour your describe:

/* main.c */

#include <stdio.h>

int main(int argc, char *argv[]) {
    int i;
    for (i = 0; i < argc; i++) {
        printf("%s\n", argv[i]);
    }
    return 0;
}

C:\> ShellCmd.exe a b c
ShellCmd.exe
a
b
c

That's with Visual Studio 2005.

Answer 3

On Windows, at the system level, the command-line is passed to the launched program as a single UTF-16 string, so any quotes entered in the shell are passed as is. So the double quotes from your example are not removed. This is quite different from the POSIX world where the shell does the job of parsing and the launched program receives an array of strings.

I've described here the behavior at the system level. However, between your C (or your Perl) program there is usually the C standard library that is parsing the system command line string to give it to main() or wmain() as argv[] . This is done inside your process, but you can still access the original command line string with GetCommandLineW() if you really want to control how the parsing is done, or get the string in its full UTF-16 encoding.

To learn more about the Windows command-line parsing quirks, read the following:

• http://www.autohotkey.net/~deleyd/parameters/parameters.htm#WIN
• http://blogs.msdn.com/b/oldnewthing/archive/2006/05/15/597984.aspx

You may also be interested by the code of the wrapper I wrote for Padre on Win32: this is a GUI program (which means that it will not open a console if launched from the Start menu) called padre.exe that embeds perl to launch the padre Perl script. It also does a small trick: it changes argv[0] to point it to perl.exe so that $^X will be something usable to launch external perl scripts.

The execv you are using in your example code is just an emulation in the C library of the POSIX-like behavior. In particular it will not add quotes around your arguments so that the launched perl works as expected. You have to do that yourself.

Note that due to the fact that the client is responsible for parsing, each client client can do it the way it wants. Many let the libc do it, but not all. So generic command-line generation rules on Windows can not exist: the rule depend on the program launched. You may still be interested in "best effort" implementation such as Win32::ShellQuote .

Answer 4

Windows is always the odd case. Personally, I wouldn't try to code for the Windows environment exception. Some alternatives are using "bat wrappers" or ftype/assoc Registry hacks for a file extension.

Windows ignores the shebang line when running from a DOS command shell, but ironically uses it when CGI-ing Perl in Apache for Windows. I got tired of coding #!c:/perl/bin/perl.exe directly in my web programs because of portability issues when moving to a *nix environment. Instead I created ac:\\usr\\bin directory on my workstation and copied the perl.exe binary from its default location, typically c:\\perl\\bin for AS Perl and c:\\strawberry\\perl\\bin for Strawberry Perl. So in web development mode on Windows my programs wouldn't break when migrated to a Linux/UNIX webhost, and I could use a standard issue shebang line "#!/usr/bin/perl -w" without having to go SED crazy prior to deployment. :)

In the DOS command shell environment I just either set my PATH explicitly or create a ftype pointing to the actual perl.exe binary with embedded switch -Mperl5i. The shebang line is ignored.

ftype p5i=c:\strawberry\perl\bin\perl.exe -Mperl5i %1 %*
assoc .pl=p5i

Then from the DOS command line you can just call "program.pl" by itself instead of "perl -Mperl5i program.pl"

So the "say" statement worked in 5.10 without any additional coaxing just by entering the name of the Perl program itself, and it would accept a variable number of command line arguments as well.

Answer 5

Use CommandLineToArgvW to build your argv, or just pass your command line directly to CreateProcess .

Of couse, this requires a separate Windows-specific solution, but you said you're okay with that, this is relatively simple, and often coding key pieces specifically to the target system helps integration (from the users' POV) significantly. YMMV.

If you want to run the same program both with and without a console, you should read Raymond Chen on the topic.

Answer 6

If you were able to use C++ then perhaps Boost.Program_options would help:

http://www.boost.org/doc/libs/1_39_0/doc/html/program_options.html