New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
system() on Win32 tries to launch bogus paths+bad cmd parsing #13614
Comments
From @bulk88Created by @bulk88While investigating why re/subst.t and other subst*.t tests take 300 For testing my script is The callstack on blead generally looks like
lpApplicationName's MS docs are Obviously c string "C:\perl519\src\t\perl.exe -I../lib -e Perl Info
|
From @ikegamiOn Thu, Feb 20, 2014 at 12:46 AM, bulk88 <perlbug-followup@perl.org> wrote:
It means "if we can easily execute the shell command without invoking a |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88ideas from IRC [16:14] <@xdg> bulk88, I'd suggest avoiding the quoted single quote, too -- |
From @Smylersbulk88 via RT writes:
If there's consensus on system's current behaviour on Windows being IPC::System::Simple aims to be compatible with built-in system. That If built-in system is going to change, then IPC::System::Simple needs to (Also, it may be worth looking at IPC::System::Simple's current Cheers Smylers |
From @janduboisSorry, I don't have time to look at this in detail right now, but I would recommend to start by extending these tests first to cover the Cheers, |
From @steve-m-haySorry if this has already been mentioned. I had a skim read of the above and didn't see it, so I thought I'd record it here for future reference: The cmd.exe that unexpectedly gets launched to launch the perl.exe (instead of perl.exe getting launched directly) sometimes doesn't happen when using system("$perl ...") rather than system(1, "$perl ..."). (The discussion so far has been regarding the latter form, specifically a case in t/test.pl's watchdog().) The example I've just stumbled across is that this: perl -le "system(1, qq[$^X -e sleep(10)])" launches a cmd.exe which launches a perl.exe which sleeps for 10 seconds, which can be clearly seen in the tree view of Process Explorer: the cmd.exe->perl.exe pair are separated from the cmd.exe in which I ran the above command because the system(1, ...) form doesn't wait for the command to complete so the perl.exe than I ran from my cmd.exe immediately exits, leaving just the cmd.exe->perl.exe that it launched, now separated from my cmd.exe. You can see this more clearly by running: perl -le "system(1, qq[$^X -e sleep(10)]); sleep(5)" in which the perl.exe that I ran from my cmd.exe sticks around for 5 seconds with the cmd.exe->perl.exe underneath it before exiting. Whereas this: perl -le "system(qq[$^X -e sleep(10)])" does NOT launch the unexpected cmd.exe, which can again be clearly seen in Process Explorer: the perl.exe than I ran from my cmd.exe only has another perl.exe underneath it. I don't know if that's a useful observation or not; I just thought I'd mention it since it surprised me. Another thing I noticed is that shortly after this ticket appeared, there was another discussion on p5p (see the thread beginning here: http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.html) which wound up in commit http://perl5.git.perl.org/perl.git/commit/94d4006a6d, which noted that, "On Windows, only the system PROGRAM LIST syntax will reliably avoid using the shell; system LIST, even with more than one element, will fall back to the shell if the first spawn fails." That suggests to me that changing perl -le "system(1, qq[$^X -e sleep(10)])" to perl -le "system({$^X} 1, qq[$^X -e sleep(10)])" should workaround the problem. Indeed, it does, but seems to reveal some other new problem?! -- the perl.exe that I ran from my cmd.exe does indeed now run the other perl.exe directly, without an intermediate cmd.exe, but the second perl.exe (with the -e sleep(10) arguments) hangs indefinitely instead of exiting after 10 seconds. I wondered if the indirect object part was causing some confusion with the special leading "1", but this: perl -le "system({$^X} qq[$^X -e sleep(10)])" (which works around the unexpected cmd.exe problem itself by omitting that leading "1", of course, as noted earlier) also still hangs indefinitely. In this case, the system LIST form avoids the unwanted cmd.exe anyway, i.e. this behaves as expected: perl -le "system($^X, '-e', 'sleep(10)')" and with this multi-element LIST form, the indirect object syntax no longer hangs indefinitely either, i.e. this also behaves as expected: perl -le "system({$^X} $^X, '-e', 'sleep(10)')" In fact, both of these forms also work as expected with the leading "1" too, i.e.: perl -le "system(1, $^X, '-e', 'sleep(10)')" perl -le "system({$^X} 1, $^X, '-e', 'sleep(10)')" So to summarize all this: perl -le "system(1, qq[$^X -e sleep(10)])" perl -le "system(qq[$^X -e sleep(10)])" perl -le "system({$^X} 1, qq[$^X -e sleep(10)])" perl -le "system({$^X} qq[$^X -e sleep(10)])" perl -le "system(1, $^X, '-e', 'sleep(10)')" perl -le "system($^X, '-e', 'sleep(10)')" perl -le "system({$^X} 1, $^X, '-e', 'sleep(10)')" perl -le "system({$^X} $^X, '-e', 'sleep(10)')" |
This comment has been minimized.
This comment has been minimized.
@steve-m-hay @bulk88 this case has been idle for 5 years. I assume nothing has changed on this problem. Can you suggest what we might want to do to move this forward? |
Migrated from rt.perl.org#121283 (status was 'open')
Searchable as RT121283$
The text was updated successfully, but these errors were encountered: