At 11:30 AM 1/31/01 -0500, John Porter wrote:
>Huh? exec() works! At least on some versions of Windows.
It "works" in the sense that it passes the arguments to the exec() in the
Windows CRTL. Unfortunately the underlying Windows exec has
non-traditional, to put it politely, semantics. It behaves sort of like a
fork/exec sequence without the wait; i.e. it starts a new process in the
background and returns control immediately to the calling process.
This gets down to Perl's "mission statement" - does it aspire to provide a
portability abstraction a la Java or just call through to OS interfaces
like C? I've never seen anything explicit on the mission anywhere in the
docs. The reality on the ground, at least vis-a-vis UNIX/Windows, appears
to be that where same-named system calls don't exist on Windows (eg unlink)
Perl isn't too proud to fake them up, but where there is an entry point of
the same name Perl will not attempt to improve on its semantics in the name
of portability. This, as I say, is my conclusion and not based on anything
but observation, and certainly not on expertise with the Win32 API.
> > though since Perl's system()
> > always exposes its argument to the shell...
>
>Are you sure that's a fact on Windows?
>It's definitely not true for unix.
>The docs for exec() clearly state this.
Yes, the docs state this unequivocally, and have from time immemorial, and
they are just as unequivocally wrong with respect to Windows. My (again
unsupported) impression is that this doc bug is being deliberately
overlooked: as long as the doc is clear-but-wrong there's an opportunity to
fix Win32 Perl some day but if the doc is fixed to tell the truth it will
become part of the API. In any case, the plain fact is that 'system @cmd'
and 'system "@cmd"' are indistinguishable on Windows despite what the doc
so plainly says.
-David Boyce
