Mailing List Archive

> From: Mark Ingalls <marking@microsoft.com>
>
> | Anyway, the _correct_ answer to the problem is not to make an NT
> | specific change in the application (e.g., 'cd' without any arguments)
> | but to make a change that increases the portability of the application
> | e.g., add 'use Cwd;' and change `pwd` to getcwd().
> |
> | It is important that Cwd.pm is patched to work correctly on all
> | supported perl platforms, including NT.
>
> i agree. does this mean that find.pl (and any other libraries that use
> `pwd`) will be changed to use cwd.pm and getcwd() as well? it uses
>
> $cwd = chop(`pwd`);
>
> in its code now and i've had to modify find.pl to use the `cd` command in
> order to get some scripts (specifically weblint) to work with ntperl.

Don't do that. Change your script to 'use Cwd;' and call getcwd().
Then hack Cwd.pm to work - one day Cwd will do the right thing anyway.

Umm, this `pwd` issue is rather widespread:

./ext/POSIX/POSIX.pm: chop($cwd = `pwd`); <== this is POSIX::getcwd !
./lib/Cwd.pm: chop($ENV{'PWD'} = `pwd`);
./lib/Cwd.pm: chop($ENV{'PWD'} = `pwd`);
./lib/ExtUtils/xsubpp:chomp($pwd = `pwd`);
./lib/find.pl: chop($cwd = `pwd`);
./lib/finddepth.pl: chop($cwd = `pwd`);
./lib/pwd.pl: chop($ENV{'PWD'} = `pwd`);
./lib/pwd.pl: chop($ENV{'PWD'} = `pwd`);
./t/comp/cpp.aux:$pwd=`pwd`;
./t/io/fs.t:$wd = `pwd`;
./t/op/stat.t:chop($cwd = `pwd`);

I seem to recall that Larry gave a reason why the POSIX module
implemented getcwd that way but I can't remember what it was. Larry?

If the mood takes me I might just do a patch for find*.pl and pwd.pl.

Interestingly File::Find correctly uses the Cwd module and not a
bare `pwd`.

Tim.

Tim Bunce writes:
> Given that `pwd` figures highly when porting to new non-unix platforms
> Larry may consider it if someone submitted a clean patch. I've CC'd
> this to perl5-porters in case someone has the time to do it.
> (Ilya, what did you do for OS/2?)

My solution may well work with NT as well. I start command processor
(shell) and ask it:

$ENV{'PWD'} = `cmd /c cd`;
chop $ENV{'PWD'};
$ENV{'PWD'} =~ s:\\:/:g ;
return $ENV{'PWD'};

On the second thought having it fire `$ENV{COMSPEC} /c cd` may be
better, but I was afraid of some hostile shells. Which will work under
NT?

Ilya

./ext/POSIX/POSIX.pm: chop($cwd = `pwd`); <== this is POSIX::getcwd !

a lot of getcwd(3) calls are implimented the same way (!).

I seem to recall that Larry gave a reason why the POSIX module
implemented getcwd that way but I can't remember what it was. Larry?

i think it had to do with getwd() being a `better' function for getting
the actual cwd, but seeing it's suceptible to run-off-the-end-of-the-array
problems, we can't use it. getcwd() is often implimented with popen() and
pwd(1).

.mrg.

: ./ext/POSIX/POSIX.pm: chop($cwd = `pwd`); <== this is POSIX::getcwd !
:
: a lot of getcwd(3) calls are implimented the same way (!).
:
: I seem to recall that Larry gave a reason why the POSIX module
: implemented getcwd that way but I can't remember what it was. Larry?
:
: i think it had to do with getwd() being a `better' function for getting
: the actual cwd, but seeing it's suceptible to run-off-the-end-of-the-array
: problems, we can't use it. getcwd() is often implimented with popen() and
: pwd(1).

I suspect there are systems on which `pwd` will do better than getcwd,
particularly if pwd must be setuid root to traverse certain directories
or certain kinds of filesystems.

Larry

Larry Wall wrote :
|| : i think it had to do with getwd() being a `better' function for getting
|| : the actual cwd, but seeing it's suceptible to run-off-the-end-of-the-array
|| : problems, we can't use it. getcwd() is often implimented with popen() and
|| : pwd(1).
||
|| I suspect there are systems on which `pwd` will do better than getcwd,
|| particularly if pwd must be setuid root to traverse certain directories
|| or certain kinds of filesystems.
||
|| Larry

Of course, that can backfire. :-)

If you are in a NFS directory, then it is possible that
when you setuid to root, you *lose* the ability to
traverse upwards from where you are. (I.e. if the exporting
system is translating "root" to "nobody" but your current
account did have permission.)

--
Maybe we can fix reality one of these days. | John Macdonald
<- Larry Wall Carl Dichter -> | jmm@Elegant.COM
I'd be happy if we could just index it. |

On Wed, 25 Oct 1995, John Macdonald wrote:

> Of course, that can backfire. :-)
>
> If you are in a NFS directory, then it is possible that
> when you setuid to root, you *lose* the ability to
> traverse upwards from where you are. (I.e. if the exporting
> system is translating "root" to "nobody" but your current
> account did have permission.)

Thanks, I'll make sure to note that one down in my "NFS litany of woe". ;-)

> --
> Maybe we can fix reality one of these days. | John Macdonald
> <- Larry Wall Carl Dichter -> | jmm@Elegant.COM
> I'd be happy if we could just index it. |
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> From: "John M. Dlugosz" <jdlugosz@objectspace.com>
>
> >Sadly we must assume something that's always available. Either CMD.EXE or
> >ship something with NT perl.
>
> I disagree. Assume something with _at_least_ those abilities, but don't
> prevent people from using something better.

I'm not suggesting that anybody be prevented from anything, see below.

> >NT perl should ignore COMSPEC.
>
> Depends on what you are doing. Using CD for a side-effect, sure, I want to
> bypass aliases. But using something else, perhaps the user will expect his
> own version to be called and be mad that it isn't.

A c-shell user on unix might be 'mad' that csh commands don't work in `...`
but there is a *very* good reason for it.

The c-shell user soon calms down when it's pointed out that they can
simple say

`csh -c ...`

instead. The NT situation is a parallel one and is solved in the same way.

The default shell for `` *must* be fixed otherwise scripts will break
between systems.

Anyone needing to rely on a specific command interpreter simply
specifies it as part of the command.


> >I assume that `cd` will always give long names. Are you saying that
> >
> > cd
> > some_dos_prog
> > cd
> >
> >may print two different paths (one long, the other a truncated alias) ?
>
> Exactly. Behold:
>
> [e:\apps\netscapenavigator]cmd
> Microsoft(R) Windows NT(TM)
> (C) Copyright 1985-1994 Microsoft Corp.
>
> E:\apps\NetscapeNavigator>cd
> E:\apps\NetscapeNavigator
>
> E:\apps\NetscapeNavigator>edit
>
> E:\apps\NETSCA~1>cd
> E:\apps\NETSCA~1
>
> E:\apps\NETSCA~1>

Sigh. That's very sad.

Oh well, that strengthens my argument (expounded at length in another message)
that `pwd` needs to be trapped and faked.

Tim.

On Thu, 26 Oct 1995, Tim Bunce wrote:

>
> > From: "John M. Dlugosz" <jdlugosz@objectspace.com>

Well, hello there John. I should have realized I'd run into you here.
G'day!

> > [...]
> > Exactly. Behold:
> >
> > [e:\apps\netscapenavigator]cmd
> > Microsoft(R) Windows NT(TM)
> > (C) Copyright 1985-1994 Microsoft Corp.
> >
> > E:\apps\NetscapeNavigator>cd
> > E:\apps\NetscapeNavigator
> >
> > E:\apps\NetscapeNavigator>edit
> >
> > E:\apps\NETSCA~1>cd
> > E:\apps\NETSCA~1
> >
> > E:\apps\NETSCA~1>
>
> Sigh. That's very sad.

Agreed.

> Oh well, that strengthens my argument (expounded at length in another message)
> that `pwd` needs to be trapped and faked.

I'm coming in at the tail end of this, so please forgive me for obvious
blunders: is there any reason why `pwd` can't refer to a "pwd.exe" that is
shipped with NTPerl? [.Oh. Reading Tim's other message implies speed is the
major problem.] The only other solution seems to be, as Tim suggested,
trapping `pwd`.

Needless to say, a decent Cwd.pm should _also_ be provided, but handling
`pwd` should make porting perl scripts to NT just a little more pleasent.

> Tim.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

Tim bunce writes:
>> From: Wayne Berke <berke@panix.com>
>> In message <9510201143.aa03091@relay-3.mail.demon.net>, Tim Bunce writes:
>> > `pwd` is such a common idiom in old code that I think it should be
>> > supported. Either by supplying a pwd command or catching this
>> > particular case inside NT perl.
>>
>> Just out of curiosity, why should a perl user have to 'use' a custom
>> module just to print out the working directory?

>Given that `pwd` figures highly when porting to new non-unix platforms
>Larry may consider it if someone submitted a clean patch. I've CC'd
>this to perl5-porters in case someone has the time to do it.
>(Ilya, what did you do for OS/2?)

In case anybody wonders about the Mac, MacPerl handles this by trapping
`pwd` and `hostname` (The other case of a frequently used Un*x idiom for
which no convenient Perl workaround exists). Trapping is always somewhat
ugly, but trying to get rid of these idioms in existing code is hopeless.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
"And that's why I am going to turn this world upside down, and make
of it a fire so *bright* that someone real will notice"
-- Vernor Vinge, _Tatja Grimm's World_

I'm forwarding this to ntperl since you hadn't CC'd it to them.

> From: Matthias Neeracher <neeri@iis.ee.ethz.ch>
>
> Tim bunce writes:
> >> From: Wayne Berke <berke@panix.com>
> >> In message <9510201143.aa03091@relay-3.mail.demon.net>, Tim Bunce writes:
> >> > `pwd` is such a common idiom in old code that I think it should be
> >> > supported. Either by supplying a pwd command or catching this
> >> > particular case inside NT perl.
> >>
> >> Just out of curiosity, why should a perl user have to 'use' a custom
> >> module just to print out the working directory?
>
> >Given that `pwd` figures highly when porting to new non-unix platforms
> >Larry may consider it if someone submitted a clean patch. I've CC'd
> >this to perl5-porters in case someone has the time to do it.
> >(Ilya, what did you do for OS/2?)
>
> In case anybody wonders about the Mac, MacPerl handles this by trapping
> `pwd` and `hostname` (The other case of a frequently used Un*x idiom for
> which no convenient Perl workaround exists). Trapping is always somewhat
> ugly, but trying to get rid of these idioms in existing code is hopeless.
>
> Matthias
>
> -----
> Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
> "And that's why I am going to turn this world upside down, and make
> of it a fire so *bright* that someone real will notice"
> -- Vernor Vinge, _Tatja Grimm's World_

Thanks Matthias.

Tim.