Detecting Bourne (or csh) shell from Perl

[Ilya Zakharevich]

C::Scan module uses this construct

my $cmd = qq(echo '#include "$filename"' | $Cpp->{cppstdin} $Defines $addincludes $Cpp->{cppflags} $Cpp->{cppminus} |);

Obviously, is supposes Bourne (or C) shell; so this breaks on ports
which use DOSISH shells.

a) is $^O =~ /win32/i a fool-proof way to detect such ports?

b) if so, where is it documented? (I want to comment this edit in details)

Thanks,
Ilya

P.S. I grepped through ./pod/* of 5.8.8, and did not find any info...

 

[Ilya Zakharevich]

DOS itself ($^O eq "dos") is dead. I presume you know better than I what
shell is available on OS/2. NetWare, however, also sets $^O = "Win32",
but looking at ExtUtils::MM_NW5 suggests that it has (or can have?
$ENV{EMXSHELL} seems to be important) a shish shell.

As for other shells, MacOS Classic and RISC OS are dead, and the Symbian
port is no longer maintained, so I believe that leaves VMS.

Thanks for this info. However, I do not see what is the relationship
of this list of dead platforms (whatever this means) to my question...

Reiterating again: is there a way to distinguish (e.g., a Windows)
port which uses "native" shell vs Korn-syntax shell.

that's an OS matter, and outside the remit of the perl docs.

This, of course, has nothing to do with OS. Just what the creator of
a particular port decided to use as a shell. (And, repeating myself:
IMO, if people would listen to me a decade ago, one would not have
this mess at all - all shells would use Bourne syntax...)

And having docs mentioning how to write portable code would be nice,
would not it?

Thanks,
Ilya

 

[Martin Str|mberg]

my $cmd = qq(echo '#include "$filename"' | $Cpp->{cppstdin} $Defines $addincludes $Cpp->{cppflags} $Cpp->{cppminus} |);

Obviously, is supposes Bourne (or C) shell; so this breaks on ports
which use DOSISH shells.

a) is $^O =~ /win32/i a fool-proof way to detect such ports?

If you still support dos, this isn't fool-proof.

 

[Ilya Zakharevich]

Sorry, I thought your question was 'which platforms use DOSish shells'
not 'are there any Win32 ports which don't'. There is presently only one
Win32 port, the one in the core, and that uses $ENV{PERL5SHELL} to
decide which shell to use, falling back to command.com/cmd.exe if it's
empty.

I know many Windows ports: AS, Strawberry (several flavors, judging by
bug reports for my modules), cygwin... I expect cygwin uses Bourne...

Meh. IMHO a perl which doesn't use the same shell as used by system(3)
in the standard C library is somewhat broken.

I would guess that your understanding of non-Unix architechture is
kinda blurred. There are probably tens of different C libraries, none
of them "standard"...

So you would have Win32 perl ship with a sh.exe,
Yes.

and use that for system and exec?

Yes (by default). Using (e.g.) Win32::system would switch to using
%COMSPEC%.

I suspect that would have made Win32 people coming to perl
rather unhappy.

How would having more scripts working "out of the box" make them unhappy?

The docs repeatedly suggest avoiding the shell wherever possible, and
doing things in Perl instead.

Definitely, this does not cover the situations when using the shell is
the answer...

Yours,
Ilya

 

[Ilya Zakharevich]

AS and Strawberry (all the various flavours) apply no more than minor
patches to the core. (This wasn't true once, as I'm sure you remember,
but ActiveState haven't had their own port for a long time.) Cygwin (and
Interix and UWin) don't set $^O = "Win32"; as far as Perl is concerned,
they're mostly a different OS from Win32.

I strongly oppose this misuse of the word "OS"; an OS is an OS - a
port is a port.

Otherwise - a lot of thanks for bringing my attention to Interix and
UWin (this is VERY CLOSE to the kind of info I was asking for). In
other message of this thread, you advocate looking in perlport; but I
find very scarce info about these ports there...

The end result is that I do not know what shell they do use... I'm
afraid one would need to run something like

system qq(echo "1" | $^X -wne "exit 1 unless /\\x22/")
and print "no quote passed through"

each time C::Scan is loaded...

I'm aware of that. However, TTBOMK there aren't any C libraries for
Win32 which don't use command.com/cmd.exe for system(3).

Are you sure about cygwin one?

You would at least need to ship with a reasonable set of utilities, as
well

Not according to my experience. Having a descriptive error message
(such as mv.exe not found, etc) makes more than half of the way.

[Moreover, it is trivial to modify pdksh to load Perl substitutes
for mv etc (in the case no native solution is found), which would
cover most of situationa with a very resource-cheap solution. But
I never needed anything like this for OS/2 port - it is so easy to
get ports of main utilities...]

Thanks,
Ilya

 

[Ilya Zakharevich]

then: TTBOMK there aren't any C libraries for native Win32 (without any
sort of Unix emulation layer) which don't use cmd.exe for system(3).

This statement is IMO an oxymoron; system() is ALREADY a part of
"unix-emulation layer". Moreover, IMO any relationship of Perl's
builtins to C library APIs of the same name is at most a coincidence.

When porting, there must be not a design goal to mimic a particular
implementation chosen by a particular C library; consistency with
behaviour on other architectures is a much more important goal.

But now this discussion reduced to the mode of counting angels on the
end of a needle. As a solution to the initial problem I'm currently
testing the horrible error-prone

my $cmd = qq($^X -e "print qq(#include \\x22).shift().qq(\\x22)"
"$filename" | $Cpp->{cppstdin} $Defines $addincludes
$Cpp->{cppflags} $Cpp->{cppminus} |);

....

Ilya

 

[Peter J. Holzer]

This statement is IMO an oxymoron; system() is ALREADY a part of
"unix-emulation layer".

Only if you count C itself as part of the "unix-emulation layer".

hp

 

[Ilya Zakharevich]

Only if you count C itself as part of the "unix-emulation layer".

No. system() is not a part of C.

BTW, let me clarify: I suspect what is a "Unix emulation layer" for
Ben is just "implementation of POSIX APIs on top of
`(the-given-)system'-calls" for me...

Yours,
Ilya

 

[Ilya Zakharevich]

BTW, let me clarify: I suspect what is a "Unix emulation layer" for
Ben is just "implementation of POSIX APIs on top of
`(the-given-)system'-calls" for me...

No. I consider Cygwin &c. emulation layers because they don't just
provide libc, they also remap the filesystem[0] and (attempt to) provide
Unixish kernel-level services like fork and ptys which aren't
implemented in NT.

You just confirm my statement: I do not care what is kernel-level and
what not (same as a Perl script - it would not care). You do.

From the point of view of an application program like
perl, Cygwin behaves a lot more like a rather strange Unix than it does
like some variant of Win32, which is why $^O is different.

IMO, any Perl port must be "just a strange flavor" of another port (as
far as possible). All significant differences must be triggered
explicitly, by pragmas.

Yours,
Ilya