Prev: Decimal sort
Next: FAQ 4.65 How can I get the unique keys from two hashes?
From: Ilya Zakharevich on 4 Mar 2010 15:44
On 2010-03-04, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> Reiterating again: is there a way to distinguish (e.g., a Windows)
>> port which uses "native" shell vs Korn-syntax shell.

> 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...

>> > 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.
>
> 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"...

>>> (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...)

> 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?

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

> 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
From: Ben Morrow on 4 Mar 2010 17:37

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-03-04, Ben Morrow <ben(a)morrow.me.uk> wrote:
> >> Reiterating again: is there a way to distinguish (e.g., a Windows)
> >> port which uses "native" shell vs Korn-syntax shell.
>
> > 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...

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.

> >> > 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.
> >
> > 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"...

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).

> >>> (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...)
>
> > 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?

You would at least need to ship with a reasonable set of utilities, as
well, which would turn perl-for-Win32 into something more like MinGW. I
don't think that's what the people porting perl to Win32 wanted.

> >> And having docs mentioning how to write portable code would be nice,
> >> would not it?
>
> > 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...

No, and I agree it's extremely hard to make such things portable.

Ben

From: Ilya Zakharevich on 5 Mar 2010 23:57
On 2010-03-04, Ben Morrow <ben(a)morrow.me.uk> wrote:
> 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 would guess that your understanding of non-Unix architechture is
>> kinda blurred. There are probably tens of different C libraries, none
>> of them "standard"...

> 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
From: Ben Morrow on 8 Mar 2010 05:36

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-03-04, Ben Morrow <ben(a)morrow.me.uk> wrote:
> > 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...

Cygwin, Interix and UWin all use some kind of sh-ish shell.

> >> 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"...
>
> > 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?

I don't consider Cygwin's libc to be a libc 'for Win32'. If you do,
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).

Ben

From: Ilya Zakharevich on 8 Mar 2010 15:53
On 2010-03-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Decimal sort
Next: FAQ 4.65 How can I get the unique keys from two hashes?