From nmqrstx-18@yahoo.de

Hi,

Perl-Version

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 638 provided by ActiveState Corp. http​://www.ActiveState.com
ActiveState is a division of Sophos.
Built Apr 13 2004 19​:24​:21

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http​://www.perl.com/, the Perl Home Page.

OS​: Win32 XP 5.1 SP "

Issue​:

expecting​: die

my $fh = undef;
open $fh, "|/usr/sbin/sendmehl -t" or die "Fehler​: $!";
print "go on...."; # no die!?

No die() but a error-Message from OS​:
Der Befehl "/usr/sbin/sendmehl" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
go on....

Thats all, thank you!

Rolf

http​://rolfrost.de/

From @Abigail

5.6.1 is a very old Perl; released over a decade ago. 5.14 is the current
version, with 5.12 the only other major version that is still supported.

Having said that, I cannot reproduce this using 5.6.2 (but I'm using a
different platform).

Can you reproduce your error on 5.14?

Abigail

The RT System itself - Status changed from 'new' to 'open'

From @ikegami

On Sat, Jun 4, 2011 at 8​:16 PM, Abigail <abigail@​abigail.be> wrote​:

On Sat, Jun 04, 2011 at 11​:50​:47AM -0700, Rolf Rost wrote​:

# New Ticket Created by "Rolf Rost"
# Please include the string​: [perl #92220]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=92220 >

Hi,

Perl-Version

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 638 provided by ActiveState Corp.
http​://www.ActiveState.com
ActiveState is a division of Sophos.
Built Apr 13 2004 19​:24​:21

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to
the
Internet, point your browser at http​://www.perl.com/, the Perl Home
Page.

OS​: Win32 XP 5.1 SP "

Issue​:

expecting​: die

my $fh = undef;
open $fh, "|/usr/sbin/sendmehl -t" or die "Fehler​: $!";
print "go on...."; # no die!?

No die() but a error-Message from OS​:
Der Befehl "/usr/sbin/sendmehl" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
go on....

5.6.1 is a very old Perl; released over a decade ago. 5.14 is the current
version, with 5.12 the only other major version that is still supported.

Having said that, I cannot reproduce this using 5.6.2 (but I'm using a
different platform).

Can you reproduce your error on 5.14?

On Windows, the single-argument form of C<system> invokes the shell if the
program is not found, even if the command contains no special characters.

perl -E"system('inexistant'); say $?"
'inexistant' is not recognized as an internal or external command,
operable program or batch file.
256

This allows shell builtins (dir, copy) to be callable as executables.

perl -E"system('dir'); say $?"
Volume in drive C has no label.
Volume Serial Number is 080E-1D03
...
0

C<open> pipes appear to work the same way.

perl -E"open my $fh, 'nonexistant |' or die $!; print while <$fh>;
close($fh); say $?"
'nonexistant' is not recognized as an internal or external command,
operable program or batch file.
256

perl -E"open my $fh, 'dir |' or die $!; print while <$fh>; close($fh); say
$?"
Volume in drive C has no label.
Volume Serial Number is 080E-1D03
...
0

From @ikegami

On Sat, Jun 4, 2011 at 2​:50 PM, Rolf Rost <perlbug-followup@​perl.org> wrote​:

Issue​:

expecting​: die

my $fh = undef;
open $fh, "|/usr/sbin/sendmehl -t" or die "Fehler​: $!";
print "go on...."; # no die!?

No die() but a error-Message from OS​:

It didn't die because the child, a shell, was successfully launched.

You don't detect the error because you didn't check if the child succeeded
or not. (C<close($fh); die if $?;>).

From @ikegami

On Sat, Jun 4, 2011 at 8​:16 PM, Abigail <abigail@​abigail.be> wrote​:

Having said that, I cannot reproduce this using 5.6.2 (but I'm using a different platform).

Try running a command with C<"> in it.

$ perl -E'open(my $fh, q{|foo "bar"}) or die "open​: $!"; close($fh); die
"foo​: $?" if $?;'
sh​: ./foo​: Permission denied
foo​: 32256 at -e line 1.

From @cpansprout

On Sat Jun 04 21​:52​:50 2011, ikegami@​adaelis.com wrote​:

On Sat, Jun 4, 2011 at 8​:16 PM, Abigail <abigail@​abigail.be> wrote​:

Having said that, I cannot reproduce this using 5.6.2 (but I'm using a

different platform).

Try running a command with C<"> in it.

$ perl -E'open(my $fh, q{|foo "bar"}) or die "open​: $!"; close($fh); die
"foo​: $?" if $?;'
sh​: ./foo​: Permission denied
foo​: 32256 at -e line 1.

Does that mean this is not a bug?

From @ikegami

On Sun, Jun 5, 2011 at 4​:47 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

Does that mean this is not a bug?

This is a discrepancy with the docs. From C<exec>,

If there is only one scalar argument or an array with one element in it, the
argument is checked for shell metacharacters, and if there are any, the
entire argument is passed to the system's command shell for parsing (this is
C</bin/sh -c> on Unix platforms, but varies on other platforms). If there
are no shell metacharacters in the argument, it is split into words and
passed directly to C<execvp>, which is more efficient.

There is no shell meta characters in the OP's example, yet a shell is used.
This can be viewed as a documentation bug, in which case the docs could be
adjusted to read​:

If there is only one scalar argument or an array with one element in it, the
entire argument is passed to the system's command shell for parsing (this is
C</bin/sh -c> on Unix platforms, but varies on other platforms). If there
are no shell metacharacters in the argument, it may be split into words and
passed directly to C<execvp> instead, which is more efficient

But it could also be viewed as a code bug. Does anyone have an opinion? I
don't.

Note that the observed behaviour is probably a side-effect of the bug where
the shell can be invoked for multi-arg system calls.

# Executes 'dir' even though it shouldn't.
perl -e"system('dir', '/b');"

# At least this returns an error as it should
perl -e"system { 'dir' } 'dir', '/b';"

(Tested recently, but not on my Windows machine right now.)

I get this on linux

perl -E'open(my $fh, q{|foo "bar"}) or die "open: $!"; close($fh); die "foo: $?" if $?;'      
sh: foo: command not found
foo: 32512 at -e line 1.

Win 10, Strawb 5.30:

Executes 'dir' even though it shouldn't.
perl -e"system('dir', '/b');"

Doesn't exec 'dir' (or at least output any results) but doesn't return an error either
perl -e"system { 'dir' } 'dir', '/b';"

I get this on linux

perl -E'open(my $fh, q{|foo "bar"}) or die "open: $!"; close($fh); die "foo: $?" if $?;'      
sh: foo: command not found
foo: 32512 at -e line 1.

The matter at hand is 1) specific to Windows, and 2) specific to commands with no shell metacharacters.

The behaviour observed by the OP is intentional in order to make built-in shell commands like dir and copy appear to be utilities.

The only issue is perhaps one of documentation.

The docs for open "|..." and open "...|" are so vague as to not have any problems.

The docs for system address the issue by stating the following:

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.

This passage is missing from the docs for exec. But then again, exec doesn't really exist on Windows.

Options:

1. Copy the passage from the docs for system to the docs for exec.

2. Close the ticket with no change because exec is already subject to YMMV on Windows since it's emulated on Windows.

I vote for the latter.

I do too. If someone disagrees we can re-open it.