groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: MSVC Port--Behavior of spawn and exec functions


From: MARSHALL Keith
Subject: Re: [Groff] Re: MSVC Port--Behavior of spawn and exec functions
Date: Thu, 15 Jan 2004 16:38:38 +0000

Hi Jeff,

You asked:
> 1.  Do other shells require that commands given with the 'c' option 
consist
>     of a single string?
>

This is a requirement of all *nix Bourne shell implementations, (and their
derivatives, e.g. ksh and bash), AFAIK.  It is *not* a requirement of 
'cmd.exe'
or of 'command.com', which will treat *everything* after '/c' as the 
command
line to execute.

> 2.  Do Win32 builds other than with MSVC have the same behavior of the 
exec
>    and spawn functions?
>

MinGW uses the MSVC runtime, and exhibits the same behaviour; Cygwin has 
its
own (POSIX compliant) runtime, and behaves like *nix. Specifically:

   spawnlp( _P_WAIT, "sh", "sh", "-c", "ls -l", NULL )

when compiled with MinGW produces just basic "ls" output, ("-l" is 
ignored),
while the same code compiled with Cygwin or with GCC on Linux, (using an
implementation of 'spawnlp' which I wrote several months ago, when porting
a collection of old MS-DOS programs to Linux), produces the long form of 
the
'ls -l' output, as we would expect.  To get the long form output with the
MinGW compilation, I need to write one of the following four variants:

   spawnlp( _P_WAIT, "sh", "sh", "-c", "'ls -l'", NULL )
   spawnlp( _P_WAIT, "sh", "sh", "-c", "'ls -l", NULL )
   spawnlp( _P_WAIT, "sh", "sh", "-c", "\"ls -l\"", NULL )
   spawnlp( _P_WAIT, "sh", "sh", "-c", "\"ls -l", NULL )

or alternatively, I can use 'cmd.exe' in place of 'sh.exe':

   spawnlp( _P_WAIT, "cmd", "cmd", "/c", "ls -l", NULL )
   spawnlp( _P_WAIT, "cmd", "sh", "/c", "ls -l", NULL )

(note that I do not even need to be consistent about specifying "cmd" for
argv[0], but I *do* need to use "/c" in place of "-c", to conform with the
'cmd.exe' syntax rules).

Actually, it is surprising that the "sh" variants omitting the closing
quote to the "'ls -l" and "\"ls -l" forms *do* work! AIUI, when any 
Windows
program is started, it is simply handed a single string of arguments, and
left to parse it itself. In this case, the program is 'sh.exe', and it
normally complains if it runs out of arguments with mismatched quotes,
when it is running non-interactively; (my Cygwin test case says
"Syntax error: Unterminated quoted string", while on Linux I see
"Error: unexpected EOF while looking for matching `''"). So ...
why does the MSYS implementation of 'sh.exe' not do the same?
I agree with you, that relying on this quirky behaviour could cause
problems in future; perhaps it would be safer to use 'cmd.exe', with '/c',
as the spawned CLI on the Windows platform.

> 3.  Do other Win32 builds (e.g., MinGW) of groff exhibit the specific
>     problems I've mentioned?

Probably.  I've not encountered them myself, but I have never tried to
make groff send output direct to a print spooler; (neither MSYS/MinGW nor
Cygwin provide one that works in a *nix fashion, so getting hard copy
is usually achieved by redirecting the binary output stream to a
Windows print queue, using shell level output redirection).

HTH

Best regards,
Keith.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]