cross is now running Foswiki 2.1.3 Beta 1. Please open a task for any issues.

Item1349: Sandbox executes "-" instead of requested program on Strawberry perl on Windows XP

Priority: Urgent
Current State: Closed
Released In: 1.0.5
Target Release: patch
Applies To: Engine
Reported By: GeorgeClark
Waiting For:
Last Change By: KennethLavrsen
Upgraded to Foswiki 1.0.4 by expanding upgrade zip file over the top of existing 1.0.0 installation. In testing, DirectedGraphPlugin stopped working.

Failure in Apache 2.2 Error log:

'-' is not recognized as an internal or external command,\r, 
operable program or batch file.\r, 

Tracked this to the following statement in

        my $pid = open( $handle, "-|" );

For some reason strawberry perl is interpreting the "-" as a command instead of causing it to fork itself.

Looks like the check for ActiveState perl that disables real pipe support also needs to detect Strawberry perl.

To validate this - changed "-|" do "dir|" and removed the error from apache logs. Then changed it back to "-|" and changed the pipe detection code to disable pipe support. After that change, DirectedGraphPlugin began working again.

-- GeorgeClark

Any good way to detect that we are in Strawberry so we can do the same as we do for Active State perl?

-- KennethLavrsen - 19 Apr 2009

Not that I know of - someone commented - maybe on IRC, I don't remember where - that Strawberry perl tries to make itself undetectable. I wonder if there is some way in the configure tool to test the environment and determine which type of pipe works if any and set a configure setting. Rather than try to figure out which perl is in use for each call to Sandbox, determine initially which to use. It also would provide an expert setting to override if the code gets it wrong.

-- GeorgeClark - 19 Apr 2009

it was on IRC, and i believe what was also said was that this bug should really be reported to the upstream source (strawberry perl).

-- WillNorris - 20 Apr 2009

update after talking with someone on irc://

[Sun Apr 19 2009] [20:57:45] <wbniv> any strawberry perl coders/experts here? we have a bug report ( ) about executing "-" (instead of taking from stdin, i presume, or forking)
[Sun Apr 19 2009] [20:57:47] <dipsy> [ Item1349: Sandbox executes "-" instead of requested program on Strawberry perl on Windows XP < Tasks < Foswiki ]
[Sun Apr 19 2009] [20:57:51] <wbniv> in this call: my $pid = open( $handle, "-|" );
[Sun Apr 19 2009] [21:01:53] <xdg> open with -| is not supported on Win32. See 'perldoc perlport'
[Sun Apr 19 2009] [21:02:02] <dipsy> [ perlport - ]
[Sun Apr 19 2009] [21:02:21] <xdg> Look in the alphabetical list of functions for 'open'
[Sun Apr 19 2009] [21:03:11] <wbniv> ok, thanks. can u suggest an alternative? or at least some way to identify that it is strawberry perl that we're running under. than we can use the same workaround that we use for AS
[Sun Apr 19 2009] [21:03:46] <xdg> It will be that way for any Windows perl: if ( $^O eq 'MSWin32' ) { ... }
[Sun Apr 19 2009] [21:04:14] <wbniv> ah, but i think under indigo perl it worked
[Sun Apr 19 2009] [21:05:13] <xdg> If you're trying to support Win32, you really should read perlport end-to-end.
[Sun Apr 19 2009] [21:05:36] <xdg> There are a lot of unix-y things you'll need to avoid or be aware of.
[Sun Apr 19 2009] [21:05:42] <wbniv> honestly, i have 0 personal interest in this. i haven't touched a windows box for over 10 years. but i'm trying to support others... :/
[Sun Apr 19 2009] [21:05:45] <xdg> See also 'perldoc perlfork'
[Sun Apr 19 2009] [21:05:54] <xdg> I understand entirely. :-)
[Sun Apr 19 2009] [21:05:58] <wbniv> heh
[Sun Apr 19 2009] [21:06:07] <wbniv> thx
[Sun Apr 19 2009] [21:06:10] <xdg> np
[Sun Apr 19 2009] [21:24:07] <wbniv> ah, maybe the trick is to detect cygwin perl and then assume any other windows perl doesn't have the fork stuff
[Sun Apr 19 2009] [21:25:43] <xdg> wbniv, cygwin will have $^O eq 'cygwin', not 'MSWin32', so it's enough to detect one or the other.

-- WillNorris - 20 Apr 2009

Further update - with some testing of the 3 sandbox pipe routines.

I don't believe that the 2nd routine EMULATED safe pipe - can ever be executed. The _assessPipeSupport routine either sets both REAL and EMULATED = 1, or if Active State detected, sets both to 0. I don't see how you can ever get REAL = 0 and EMULATED = 1, So the emulation routine cannot ever execute. Which is probably a good thing because it hangs. I've tried the emulated pipe on Linux, ActiveState, and Strawberry and in all cases it seems to hang in the I/O between threads. The child terminates but the parent seems to be blocked on the I/O.

For now I think that the best bet is to not differentiate between ActiveState and Strawberry and just let both of them pass through to the no pipe support routine which works fine. So in,
     # from the Activestate Docco this is _only_ defined on ActiveState Perl
    if ( defined(&Win32::BuildNumber) ) {

should be changed to use the if ( $^O eq 'MSWin32' ) { ... } code as recommended above.

(I did test that change on Windows with Strawberry and it appears to work - with a really quick test

-- GeorgeClark - 20 Apr 2009

It's been pointed out that safe pipes works on Cygwin on Windows. So probably the test should be:

   if ( $^O eq 'MSWin32' && $Foswiki::cfg{DetailedOS} ne 'cygwin') {
        $REAL_SAFE_PIPE_OPEN     = 0;

And to follow up - Cygwin perl does not return MSWin32 for $^O, It returns "cygwin" So the original fix will only impact Strawberry and ActiveState Perl.

I've committed the changes and tested - works okay with Strawberry Perl. This task does need some follow-up as the emulated safe pipes don't appear to work, but can't be accessed anyway.

ItemTemplate edit

Summary Sandbox executes "-" instead of requested program on Strawberry perl on Windows XP
ReportedBy GeorgeClark
Codebase 1.0.4
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Priority Urgent
CurrentState Closed
Checkins distro:00610ad41efe distro:520c4c4a4444
TargetRelease patch
ReleasedIn 1.0.5
Topic revision: r11 - 25 Apr 2009, KennethLavrsen - This page was cached on 19 Jan 2017 - 08:14.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License