Mailing List Archive

Tim Bunce writes:
> Since:
>
> 1. There is such a lot of code written to use `pwd`
> (including in the standard library modules)
> 2. Plus we have have the DOS vs UNC path format issue
> 3. Plus we have the \ vs / issue
>
> I think the best solution is to:
>
> 1. Trap and fake `pwd` internally to return the UNC path with /'s
> 2. Implement Cwd::getcwd and ::fastcwd for NT as (the faked) `pwd`
>
> That seems to be the best compromise.
>
> Rational:
>
> 1. Widespread usage of `pwd` forces either trapping or an external program
> 2. To consistently get a UNC path with /'s would require special external code
> 3. Larry is content with `pwd` as a good approach for UNIX
> 4. A trap&fake is very much faster than running an external program on NT
>

I would vote against trapping.
a) Bad precedent;
b) A good incentive to `use Cwd;' will disappear;
c) anyone can write/get a pwd.??? batch file with
cd
in it.
Having pwd in your path + using Cwd beats any argument of yours.

Ilya

On Thu, 26 Oct 1995, Tim Bunce wrote:

> > From: Stuart Poulin <stuart@amc.com>
> >
> > ...
> > How about also a switch to have the paths returned with 'lean to the right' "/"
> > slashes instead of 'lean to the left' "\" slashes. Thus making it easier to
> > universally break the string apart.
> > $Cwd::pathsep="/"
>
> I think one behaviour should be adopted. The OS/2 port translates \ to / with
> good effect. I'd strongly recommend it (see below).

Most Perl scripts will be expecting '/' as the separator, and (if NT is
anything like DOS in this respect) it shouldn't hurt to have '/' where
'\' would normally be used. I strongly recommend only returning '/' as
the path separator.

In addition, using a global variable for this is naughty, as (as Tim has
also pointed out) different parts of a program could stomp on each other
by accident if they change it.

Ideally, I'd suggest that _all_ perl variants receive a new Config.pm
variable that gives the most likely path separator. Most systems get '/',
and Mac gets ':'. (VMS gets screwed, unfortunately, as its paths can't be
described this easily.)

> > > How many people think that we should supply a pwd.cmd with the distribution?
> >
> > I vote for a fixed up Cwd.pm for NT. It seems to me the only real way a program
> > can know where it's at is to track the chdirs. If I write a perl program on
> > Unix I always use the Cwd.pm.

Cwd.pm is part of the "standard" Perl cannon that scripts can rely on. It
seems necessary to provide as much "standard" functionality as possible,
and Cwd falls squarely into that category.

> Since:
>
> 1. There is such a lot of code written to use `pwd`
> (including in the standard library modules)
> 2. Plus we have have the DOS vs UNC path format issue
> 3. Plus we have the \ vs / issue
>
> I think the best solution is to:
>
> 1. Trap and fake `pwd` internally to return the UNC path with /'s
> 2. Implement Cwd::getcwd and ::fastcwd for NT as (the faked) `pwd`
>
> That seems to be the best compromise.

Definite agreement on #2. #1 seems reasonable, although I wonder if any
better solutions present themselves.

> Rational:
>
> 1. Widespread usage of `pwd` forces either trapping or an external program
> 2. To consistently get a UNC path with /'s would require special external code
> 3. Larry is content with `pwd` as a good approach for UNIX
> 4. A trap&fake is very much faster than running an external program on NT
>
> Comments?

Looks accurate to me.

> Tim.
>

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

On Thu, 26 Oct 1995, Ilya Zakharevich wrote:

> I would vote against trapping.
> a) Bad precedent;
> b) A good incentive to `use Cwd;' will disappear;
> c) anyone can write/get a pwd.??? batch file with
> cd
> in it.

Apparently process creating is quite slow under NT, and furthermore the
include shell doesn't always provide useful output on "cd".

> Having pwd in your path + using Cwd beats any argument of yours.
>
> Ilya
>

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

>
> Since:
>
> 1. There is such a lot of code written to use `pwd`
> (including in the standard library modules)
> 2. Plus we have have the DOS vs UNC path format issue
> 3. Plus we have the \ vs / issue
>
> I think the best solution is to:
>
> 1. Trap and fake `pwd` internally to return the UNC path with /'s

Some perl I'd write would be targeted only for NT environment. It seems
unfortunate that still many of the other apps I use still can't use
UNC paths. If pwd only returned UNC paths I'd have to convert it
to S:\tupid\drive\letters. Beats me how you ask NT to tell you
what drive letter a UNC path is on.
I suppose I could call `pwd.bat` as long as the trap didn't catch this.

> 2. Implement Cwd::getcwd and ::fastcwd for NT as (the faked) `pwd`
>
> That seems to be the best compromise.
>
> Rational:
>
> 1. Widespread usage of `pwd` forces either trapping or an external program
> 2. To consistently get a UNC path with /'s would require special external code

Maybe we need a pwd.pm module or extend the Cwd.pm to include
special external code for NT.

> 3. Larry is content with `pwd` as a good approach for UNIX

On a Unix if I run:
chdir("/u20/stuart");
print `pwd`;
I get:
/tmp_mnt/u20/stuart
Without going into a long discussion - this is no good.
Other situations where symbolic links are used also confuse `pwd`.
But if I use Cwd.pl and relying on chdir tracking in $ENV{'pwd'}
I don't have this problem.
NT doesn't have symbolic links now - but maybe sometime.

> 4. A trap&fake is very much faster than running an external program on NT

>
> Comments?
>
> Tim.
>

-Stuart

In message <9510261945.AA21531@toad>, Tim Bunce writes:
>
>
> 1. Trap and fake `pwd` internally to return the UNC path with /'s
> 2. Implement Cwd::getcwd and ::fastcwd for NT as (the faked) `pwd`
>
> That seems to be the best compromise.
>
> Rational:
>
> 1. Widespread usage of `pwd` forces either trapping or an external program
> 2. To consistently get a UNC path with /'s would require special external c
> ode
> 3. Larry is content with `pwd` as a good approach for UNIX
> 4. A trap&fake is very much faster than running an external program on NT
>
> Comments?
>

trap&fake is certainly preferable to an external command which would be
dependent on the ordering of a user's path. I'm still hoping for general
perl builtin though. Maybe perl6? :-)
-----
Wayne Berke

Stuart Poulin wrote :
||
|| On a Unix if I run:
|| chdir("/u20/stuart");
|| print `pwd`;
|| I get:
|| /tmp_mnt/u20/stuart
|| Without going into a long discussion - this is no good.
|| Other situations where symbolic links are used also confuse `pwd`.
|| But if I use Cwd.pl and relying on chdir tracking in $ENV{'pwd'}
|| I don't have this problem.
|| NT doesn't have symbolic links now - but maybe sometime.

I find this to be a feature!

Nine times out of ten, when I run pwd, I want to know where
I really am, not how some program thinks I happened to get
there. Whenever I'm using a "helpful" shell, I end up
having to run /bin/pwd explicitly and I don't always remember
to do so.

I don't really approve of trapping and mangling.

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

> From: stuart@amc.com (Stuart Poulin)
>
> > Since:
> >
> > 1. There is such a lot of code written to use `pwd`
> > (including in the standard library modules)
> > 2. Plus we have have the DOS vs UNC path format issue
> > 3. Plus we have the \ vs / issue
> >
> > I think the best solution is to:
> >
> > 1. Trap and fake `pwd` internally to return the UNC path with /'s
>
> Some perl I'd write would be targeted only for NT environment. It seems
> unfortunate that still many of the other apps I use still can't use
> UNC paths. If pwd only returned UNC paths I'd have to convert it
> to S:\tupid\drive\letters. Beats me how you ask NT to tell you
> what drive letter a UNC path is on.

(I guess the idea is that you shouldn't care :-)

> I suppose I could call `pwd.bat` as long as the trap didn't catch this.

That seems like a reasonable approach. Only exactly `pwd` would be trapped.

> > 2. Implement Cwd::getcwd and ::fastcwd for NT as (the faked) `pwd`
> >
> > That seems to be the best compromise.
> >
> > Rational:
> >
> > 1. Widespread usage of `pwd` forces either trapping or an external program
> > 2. To consistently get a UNC path with /'s would require special external code
>
> Maybe we need a pwd.pm module or extend the Cwd.pm to include
> special external code for NT.

But that won't address point 1, widespread usage of `pwd`.

> > 3. Larry is content with `pwd` as a good approach for UNIX

> On a Unix if I run:
> chdir("/u20/stuart");
> print `pwd`;
> I get:
> /tmp_mnt/u20/stuart
> Without going into a long discussion - this is no good.

'no good' for you perhaps but it is how it works on unix and,
as you said later, NT may get symbolic links one day.

> Other situations where symbolic links are used also confuse `pwd`.
> But if I use Cwd.pl and relying on chdir tracking in $ENV{'pwd'}
> I don't have this problem.

So it's not a problem. Great.

From: jmm@elegant.com (John Macdonald)
>
> I find this to be a feature!
>
> Nine times out of ten, when I run pwd, I want to know where
> I really am, not how some program thinks I happened to get
> there. Whenever I'm using a "helpful" shell, I end up
> having to run /bin/pwd explicitly and I don't always remember
> to do so.

So, again, it's not a problem. Great.

> I don't really approve of trapping and mangling.

Care to be more constructive John? I don't particularly like it either
but I believe it is the best answer to a difficult issue. Nothing I've
heard so far has changed my mind.

Tim.

Tim Bunce wrote :
|| From: jmm@elegant.com (John Macdonald)
|| > I don't really approve of trapping and mangling.
||
|| Care to be more constructive John? I don't particularly like it either
|| but I believe it is the best answer to a difficult issue. Nothing I've
|| heard so far has changed my mind.

Whoa, I'm not objecting to trapping by itself - just when it is
combined with mangling.

Any scheme that did what Stuart was asking for - "correcting"
the result of `pwd` to match some symlink view of the file
system rather than the underlying reality - *that* is what I
would classify as mangling. Using an internal function to
implement `pwd` is fine, as long as it does the right thing.

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

Tim Bunce wrote :
|| From: jmm@elegant.com (John Macdonald)
|| > I don't really approve of trapping and mangling.
||
|| Care to be more constructive John? I don't particularly like it either
|| but I believe it is the best answer to a difficult issue. Nothing I've
|| heard so far has changed my mind.

Whoa, I'm not objecting to trapping by itself - just when it is
combined with mangling.

Any scheme that did what Stuart was asking for - "correcting"
the result of `pwd` to match some symlink view of the file
system rather than the underlying reality - *that* is what I
would classify as mangling. Using an internal function to
implement `pwd` is fine, as long as it does the right thing.

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

[ Tim Bunce writes: ]
>
> > From: stuart@amc.com (Stuart Poulin)
> >
> > I don't really approve of trapping and mangling.
>
> Care to be more constructive John? I don't particularly like it either
> but I believe it is the best answer to a difficult issue. Nothing I've
> heard so far has changed my mind.

I guess it's time for me to enter the fray. I think "trapping and
mangling" sets a bad precedent. The fact that bigperl did that doesn't
lend any credibility to the argument for it. It was a hack then and will
be a hack now. Non-obvious semantics of otherwise normal syntax only
adds to confusion and discredits the language and the port.

As for the argument that supplying an external pwd (preferably a
pwd.exe) being dependent on the user's PATH, what about perlglob.exe?
There's already a means (in the registry) to know where perl executables
(helpers) live. The precedent for helpers has already been set and has a
(relatively) long history.

I think the right solution is to supply a helper program, e.g.
perlpwd.exe, in the same vein as perlglob.exe, call it from the
Cwd module and encourage use of that module (primarily by using it
throughout the rest of the library, including the Unix version).
No hacks and special semantics needed. If anyone makes a copy of
perlpwd.exe named pwd.exe and expects to use it as `pwd`, then caveat
user.

--
Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598

> From: Dave Wolfe <dwolfe@risc.sps.mot.com>
>
> [ Tim Bunce writes: ]
> >
> > > From: stuart@amc.com (Stuart Poulin)
> > >
> > > I don't really approve of trapping and mangling.
> >
> > Care to be more constructive John? I don't particularly like it either
> > but I believe it is the best answer to a difficult issue. Nothing I've
> > heard so far has changed my mind.
>
> I guess it's time for me to enter the fray. I think "trapping and
> mangling" sets a bad precedent. The fact that bigperl did that doesn't
> lend any credibility to the argument for it. It was a hack then and will
> be a hack now. Non-obvious semantics of otherwise normal syntax only
> adds to confusion and discredits the language and the port.
>
> As for the argument that supplying an external pwd (preferably a
> pwd.exe) being dependent on the user's PATH, what about perlglob.exe?
> There's already a means (in the registry) to know where perl executables
> (helpers) live. The precedent for helpers has already been set and has a
> (relatively) long history.
>
> I think the right solution is to supply a helper program, e.g.
> perlpwd.exe, in the same vein as perlglob.exe, call it from the
> Cwd module and encourage use of that module (primarily by using it
> throughout the rest of the library, including the Unix version).
> No hacks and special semantics needed. If anyone makes a copy of
> perlpwd.exe named pwd.exe and expects to use it as `pwd`, then caveat
> user.

I agree in principle with what you're saying but life's not that simple...

`pwd` is used so widely that it would *have* to be supplied by default
otherwise the NT port would be 'broken as shiped'.

perlglob is a helper invoked internally by the <*.*> syntax. Since
it's invoked internally it can live anywhere the registry can point to.

`pwd` is a different problem. If you remove the option of trapping
then an executable called pwd *must* exist in the users path.
Calling it perlpwd won't work.

Yes Cwd does need changing and yes we should encourage everyone to
use it but since the widespread use of `pwd` forces a need for `pwd`
to work then Cwd can simply use whatever we agree for `pwd`.

I still believe that trap&fake is the best of a poor set of options.

The second best is to supply a pwd.exe which returns the UNC path
with forward slashes and then pray that no one deletes it.

Tim.

On Mon, 30 Oct 1995, Dave Wolfe wrote:
> [ Tim Bunce writes: ]
> > > From: stuart@amc.com (Stuart Poulin)
> > > I don't really approve of trapping and mangling.
> >
> > Care to be more constructive John? I don't particularly like it either
> > but I believe it is the best answer to a difficult issue. Nothing I've
> > heard so far has changed my mind.
>
> I guess it's time for me to enter the fray. I think "trapping and
> mangling" sets a bad precedent. The fact that bigperl did that doesn't
> lend any credibility to the argument for it. It was a hack then and will
> be a hack now. Non-obvious semantics of otherwise normal syntax only
> adds to confusion and discredits the language and the port.

Well said. Just because system('pwd') works in Unix, any reasonable
programmer should know that that isn't necessarily going to be a portable
construct. To bend over backwards for these folks when there *is* a
portable construct is wrong, and it will be used by detractors of Perl to
show what a hideous hack the language is.

Rob Lanphier
robla@eskimo.com
http://www.eskimo.com/~robla

This seems to be digressing into a RW, so let me just clarify my points
one last time (since I waited until Tim and others had ample opportunity
to establish their beachheads). I doubt that I will convert Tim and I
know he won't convert me. :-)

[ Tim Bunce writes: ]
>
> I agree in principle with what you're saying but life's not that simple...

Don't be seduced by the Dark Side, Tim. :-) Sure, a few scripts will
have to be changed, but you know in your heart of Perl that they were
wrong anyway.

> `pwd` is used so widely that it would *have* to be supplied by default
> otherwise the NT port would be 'broken as shiped'.

This is a specious argument. #! is even more widely used, but I see no
such arguments that it must be accommodated. `pwd` is a parochialism.
There are literally thousands of such throughout Perl scripts in general
because Perl was born and grew to maturity on Unix. First it's `pwd`,
but then what? `echo`? `ls`? It's unrealistic to expect Perl programs
with system dependencies, e.g. `pwd`, to drop into a foreign system with
no changes and no conflicts.

> perlglob is a helper invoked internally by the <*.*> syntax. Since
> it's invoked internally it can live anywhere the registry can point to.

But at the moment, as nearly as I can tell (and I may be wrong; Douglas,
help me out here) the registry isn't consulted for the path to helper
binaries. I think it should be so that helpers need not even be in the
users' PATH.

> `pwd` is a different problem. If you remove the option of trapping
> then an executable called pwd *must* exist in the users path.
> Calling it perlpwd won't work.

This argument assumes the truth of the first ("`pwd` is so widely
used..."). My assertion was intentionally vague, but involved the
perlpwd helper only being invoked in the Cwd module and all other
references to `pwd` being changed to use Cwd. An alternative would be to
use an extension to Perl, e.g. an intrinsic getcwd. Maybe the extension
wouldn't even need perlpwd.exe and maybe it'd get incorporated into
generic Perl some day. The point is, `pwd` would work exactly as every
logical Perl user expects and not perform any black magic.

> I still believe that trap&fake is the best of a poor set of options.

And I believe that it's the *worst* of a poor set of options. :-) I
think others do too. I hate to see a dirty fix to a problem that we'll
have to live with for a long time. If you don't have the time to do it
right, when will you have the time to fix it?

> The second best is to supply a pwd.exe which returns the UNC path
> with forward slashes and then pray that no one deletes it.

But at least Perl would work like one expects. It all goes back to the
principle of least surprise. Backticks invoke an external command.
Period. External commands are, by definition, system dependent. It seems
backwards to me to change the syntax of Perl to accommodate something
external to Perl. If we're going to change Perl, then let's make it an
extension a la registry and DDE functions.

--
Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598

> From: Rob Lanphier <robla@eskimo.com>
>
> On Mon, 30 Oct 1995, Dave Wolfe wrote:
> > [ Tim Bunce writes: ]
> > > > From: stuart@amc.com (Stuart Poulin)
> > > > I don't really approve of trapping and mangling.
> > >
> > > Care to be more constructive John? I don't particularly like it either
> > > but I believe it is the best answer to a difficult issue. Nothing I've
> > > heard so far has changed my mind.
> >
> > I guess it's time for me to enter the fray. I think "trapping and
> > mangling" sets a bad precedent. The fact that bigperl did that doesn't
> > lend any credibility to the argument for it. It was a hack then and will
> > be a hack now. Non-obvious semantics of otherwise normal syntax only
> > adds to confusion and discredits the language and the port.
>
> Well said. Just because system('pwd') works in Unix, any reasonable
> programmer should know that that isn't necessarily going to be a portable
> construct.

Hey, if it works for MacPerl ... ;-)

> To bend over backwards for these folks when there *is* a
> portable construct is wrong, and it will be used by detractors of Perl to
> show what a hideous hack the language is.

Sigh.

I trust you're volunteering to rework all the scripts and modules in
the CPAN archive to remove all traces of `pwd` in favor of Cwd. I also
look forward to the (much easier) patch which will do the same for the
standard distribution. And I presume you'll answer all the messages
in comp.lang.perl.misc asking why some scripts don't work on NT.

The sins of the fathers should not be visited on the sons and daughters.
Let's be pragmatic about this. Remember, there's more than one way to do it.

Cwd is the way to go for new code and code that can be edited.
Let's not break old code for the sake of dogmatism. Please.

Tim.

> From: Dave Wolfe <dwolfe@risc.sps.mot.com>
>
> This seems to be digressing into a RW, so let me just clarify my points
> one last time (since I waited until Tim and others had ample opportunity
> to establish their beachheads). I doubt that I will convert Tim and I
> know he won't convert me. :-)

:-)

> [ Tim Bunce writes: ]
> >
> > I agree in principle with what you're saying but life's not that simple...
>
> Don't be seduced by the Dark Side, Tim. :-) Sure, a few scripts will
> have to be changed, but you know in your heart of Perl that they were
> wrong anyway.

Umm.

> > `pwd` is used so widely that it would *have* to be supplied by default
> > otherwise the NT port would be 'broken as shiped'.
>
> This is a specious argument. #! is even more widely used, but I see no
> such arguments that it must be accommodated. `pwd` is a parochialism.
> There are literally thousands of such throughout Perl scripts in general
> because Perl was born and grew to maturity on Unix. First it's `pwd`,
> but then what? `echo`? `ls`? It's unrealistic to expect Perl programs
> with system dependencies, e.g. `pwd`, to drop into a foreign system with
> no changes and no conflicts.

Sure, in general. I believe `pwd` to be a special case.

> > perlglob is a helper invoked internally by the <*.*> syntax. Since
> > it's invoked internally it can live anywhere the registry can point to.
>
> But at the moment, as nearly as I can tell (and I may be wrong; Douglas,
> help me out here) the registry isn't consulted for the path to helper
> binaries. I think it should be so that helpers need not even be in the
> users' PATH.

That would be a step forward.

> > `pwd` is a different problem. If you remove the option of trapping
> > then an executable called pwd *must* exist in the users path.
> > Calling it perlpwd won't work.
>
> This argument assumes the truth of the first ("`pwd` is so widely
> used...").

Easily proven.

> My assertion was intentionally vague, but involved the
> perlpwd helper only being invoked in the Cwd module and all other
> references to `pwd` being changed to use Cwd.

Fine, for Cwd.

> An alternative would be to
> use an extension to Perl, e.g. an intrinsic getcwd. Maybe the extension
> wouldn't even need perlpwd.exe and maybe it'd get incorporated into
> generic Perl some day.

In other words make Cwd an extension. I've go no fundamental problem with that.

> The point is, `pwd` would work exactly as every
> logical Perl user expects and not perform any black magic.

See below.

> > I still believe that trap&fake is the best of a poor set of options.
>
> And I believe that it's the *worst* of a poor set of options. :-) I
> think others do too. I hate to see a dirty fix to a problem that we'll
> have to live with for a long time. If you don't have the time to do it
> right, when will you have the time to fix it?

Personally I wouldn't view it as broken. I'm sure MacPerl users don't.

> > The second best is to supply a pwd.exe which returns the UNC path
> > with forward slashes and then pray that no one deletes it.
>
> But at least Perl would work like one expects. It all goes back to the
> principle of least surprise. Backticks invoke an external command. Period.

Fine. Supply an pwd.exe that does the right thing and we'll both be happy.

> External commands are, by definition, system dependent. It seems
> backwards to me to change the syntax of Perl to accommodate something
> external to Perl.

The trape&fake I was suggesting is a change to implementation, not
syntax and, in some respects, not even semantics.

> If we're going to change Perl, then let's make it an
> extension a la registry and DDE functions.
>
> --
> Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246
> Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598

My bottom line: `pwd` must work - by whatever means.

I hope we are agreed that Cwd::getcwd() should return the UNC path with
forward slashes.

Prediction: if `pwd` does not work then almost all NT perl users will
implement a pwd.bat. If they do it'll almost certainly not return
the UNC path with forward slashes in which case we'll have `pwd` and
Cwd::getcwd() giving different results and we'll be in a worse mess.

Okay, can we move the debate on to these sugestions:

1. Implement a pwd.exe which returns the UNC path with forward slashes.

2. Follow Tom Horsley's 'path prefix' suggestion:

: One possibility might be to have a registry entry for a perl script "PATH
: prefix". The first thing perl would do is modify it's PATH environment to
: stick the magic prefix in front of it, then a perl version of pwd could live
: there, along with perlglob, and any other utilities that seem useful but
: might not want to go in everyone's regular PATH.

3. Modify Cwd getcwd and fastcwd to work on NT and encourage its use.

Tim.

On Mon, 30 Oct 1995, Tim Bunce wrote:
> > From: Rob Lanphier <robla@eskimo.com>
> > On Mon, 30 Oct 1995, Dave Wolfe wrote:
> > > I guess it's time for me to enter the fray. I think "trapping and
> > > mangling" sets a bad precedent. The fact that bigperl did that doesn't
> > > lend any credibility to the argument for it. It was a hack then and will
> > > be a hack now. Non-obvious semantics of otherwise normal syntax only
> > > adds to confusion and discredits the language and the port.
> >
> > Well said. Just because system('pwd') works in Unix, any reasonable
> > programmer should know that that isn't necessarily going to be a portable
> > construct.
>
> Hey, if it works for MacPerl ... ;-)

It does?!?!?!?! Ick. All the more reason to deal with this problem now.

> > To bend over backwards for these folks when there *is* a
> > portable construct is wrong, and it will be used by detractors of Perl to
> > show what a hideous hack the language is.
>
> Sigh.
>
> I trust you're volunteering to rework all the scripts and modules in
> the CPAN archive to remove all traces of `pwd` in favor of Cwd. I also
> look forward to the (much easier) patch which will do the same for the
> standard distribution. And I presume you'll answer all the messages
> in comp.lang.perl.misc asking why some scripts don't work on NT.

I imagine if I get my way, I'll end up doing a few, most likely out of
necessity. But just because I'm not willing to make everyone else's code
portable, that doesn't mean that my input is not valid. You are using
this daunting task to bully your viewpoint into practice.

This same argument has been used for years to avoid conversion to the
metric system. Imagine how much better things would be today if 18th
century industrialists could have been convinced to make the switch to
metric two hundred years ago. It would have been expensive then, but
nowhere nearly as expensive as it is today.

With Microsoft distruting Perl 5 in the NT Resource Kit, Perl 5 is going
out to *thousands* of people who have never been exposed to Perl before.
Let's clean house *now*, before we have these people hooked to the hack,
too.

As to the traffic on comp.lang.perl.misc, you will get people asking "how
come `pwd` works even though I can't find `pwd` on my system anywhere?".
In trying to avoid problems, you may make them worse.

> The sins of the fathers should not be visited on the sons and daughters.
> Let's be pragmatic about this. Remember, there's more than one way to do it.

Yes, let's not punish our sons and daughters by putting this hideous hack
in the code. There have been several good suggestions on the ntperl list
for how to deal with this. Let's not go for the easy hack.

Backticks and system calls should behave consistantly. Period. Unless
you plan to build a command interpreter into Perl, there is no reason why
Perl should be trapping anything. If it does, it is a *hack*. I don't
think I can use the word "hack" enough here. Hack hack hack hack hack
hack hack ;)

*ahem*

> Cwd is the way to go for new code and code that can be edited.
> Let's not break old code for the sake of dogmatism. Please.

It's for the sake of cleaning up the language. I thought the whole
reason why Larry put out Perl 5 was to clean up the internals and make
what would hopefully be the last of the changes that break backwards
compatibility. A system call hack would be a giant step backwards and
not in the spirit of Perl 5 at all.

If a function is added to NT Perl that is not added to core Perl for
performance reasons, I suggest it be something very unwieldy in order to
encourage people to use the Cwd module. Something like
"This_is_a_HACKHACKHACK_so_that_pwdless_OSs_can_get_pwd_for_the_Cwd_module()"
would be alright ;)

Rob Lanphier
robla@eskimo.com
http://www.eskimo.com/~robla

> From: Nick Ing-Simmons <nik@tiuk.ti.com>
>
> In <9510301726.AA18443@miaow.sps.mot.com>
> On Mon, 30 Oct 1995 11:26:13 -0600 (CST)
> Dave Wolfe <david_wolfe@risc.sps.mot.com> writes:
> >
> >But at least Perl would work like one expects. It all goes back to the
> >principle of least surprise. Backticks invoke an external command.
> >Period. External commands are, by definition, system dependent. It seems
> >backwards to me to change the syntax of Perl to accommodate something
> >external to Perl. If we're going to change Perl, then let's make it an
> >extension a la registry and DDE functions.
> >
> Supose user of NT-perl has a command (her boss wrote) called pwd.exe
> which that she *really* wants to use from perl - if you trap `pwd`
> how does she do that?

`pwd.exe`

Tim.

> From: Nick Ing-Simmons <nik@tiuk.ti.com>
>
> In <9510301726.AA18443@miaow.sps.mot.com>
> On Mon, 30 Oct 1995 11:26:13 -0600 (CST)
> Dave Wolfe <david_wolfe@risc.sps.mot.com> writes:
> >
> >But at least Perl would work like one expects. It all goes back to the
> >principle of least surprise. Backticks invoke an external command.
> >Period. External commands are, by definition, system dependent. It seems
> >backwards to me to change the syntax of Perl to accommodate something
> >external to Perl. If we're going to change Perl, then let's make it an
> >extension a la registry and DDE functions.
> >
> Supose user of NT-perl has a command (her boss wrote) called pwd.exe
> which that she *really* wants to use from perl - if you trap `pwd`
> how does she do that?

`pwd.exe`

Tim.

> `pwd` is used so widely that it would *have* to be supplied by default
> otherwise the NT port would be 'broken as shiped'.
>
> perlglob is a helper invoked internally by the <*.*> syntax. Since
> it's invoked internally it can live anywhere the registry can point to.
>
> `pwd` is a different problem. If you remove the option of trapping
> then an executable called pwd *must* exist in the users path.
> Calling it perlpwd won't work.

One possibility might be to have a registry entry for a perl script "PATH
prefix". The first thing perl would do is modify it's PATH environment to
stick the magic prefix in front of it, then a perl version of pwd could live
there, along with perlglob, and any other utilities that seem useful but
might not want to go in everyone's regular PATH. (Although, I've been
writing or getting off the net unix-like command line utilities as fast
as possible in order to have them in my path because I want them there, but
not everyone feels the same I guess. All the NT utilities I write (not many
yet) have registry entries you can set to control what kinds of path names
they accept and/or print).

--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)

> `pwd` is used so widely that it would *have* to be supplied by default
> otherwise the NT port would be 'broken as shiped'.
>
> perlglob is a helper invoked internally by the <*.*> syntax. Since
> it's invoked internally it can live anywhere the registry can point to.
>
> `pwd` is a different problem. If you remove the option of trapping
> then an executable called pwd *must* exist in the users path.
> Calling it perlpwd won't work.

One possibility might be to have a registry entry for a perl script "PATH
prefix". The first thing perl would do is modify it's PATH environment to
stick the magic prefix in front of it, then a perl version of pwd could live
there, along with perlglob, and any other utilities that seem useful but
might not want to go in everyone's regular PATH. (Although, I've been
writing or getting off the net unix-like command line utilities as fast
as possible in order to have them in my path because I want them there, but
not everyone feels the same I guess. All the NT utilities I write (not many
yet) have registry entries you can set to control what kinds of path names
they accept and/or print).

--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)

> Precedence: bulk
> Status: R

> On Mon, 30 Oct 1995, Tim Bunce wrote:
> > > From: Rob Lanphier <robla@eskimo.com>
> > > On Mon, 30 Oct 1995, Dave Wolfe wrote:
> > > > I guess it's time for me to enter the fray. I think "trapping and
> > > > mangling" sets a bad precedent. The fact that bigperl did that doesn't
> > > > lend any credibility to the argument for it. It was a hack then and will
> > > > be a hack now. Non-obvious semantics of otherwise normal syntax only
> > > > adds to confusion and discredits the language and the port.
> > >
> > > Well said. Just because system('pwd') works in Unix, any reasonable
> > > programmer should know that that isn't necessarily going to be a portable
> > > construct.
> >
> > Hey, if it works for MacPerl ... ;-)

> It does?!?!?!?! Ick. All the more reason to deal with this problem now.

> > > To bend over backwards for these folks when there *is* a
> > > portable construct is wrong, and it will be used by detractors of Perl to
> > > show what a hideous hack the language is.
> >
> > Sigh.
> >
> > I trust you're volunteering to rework all the scripts and modules in
> > the CPAN archive to remove all traces of `pwd` in favor of Cwd. I also
> > look forward to the (much easier) patch which will do the same for the
> > standard distribution. And I presume you'll answer all the messages
> > in comp.lang.perl.misc asking why some scripts don't work on NT.

> I imagine if I get my way, I'll end up doing a few, most likely out of
> necessity. But just because I'm not willing to make everyone else's code
> portable, that doesn't mean that my input is not valid. You are using
> this daunting task to bully your viewpoint into practice.

> This same argument has been used for years to avoid conversion to the
> metric system. Imagine how much better things would be today if 18th
> century industrialists could have been convinced to make the switch to
> metric two hundred years ago. It would have been expensive then, but
> nowhere nearly as expensive as it is today.

> With Microsoft distruting Perl 5 in the NT Resource Kit, Perl 5 is going
> out to *thousands* of people who have never been exposed to Perl before.
> Let's clean house *now*, before we have these people hooked to the hack,
> too.

> As to the traffic on comp.lang.perl.misc, you will get people asking "how
> come `pwd` works even though I can't find `pwd` on my system anywhere?".
> In trying to avoid problems, you may make them worse.

> > The sins of the fathers should not be visited on the sons and daughters.
> > Let's be pragmatic about this. Remember, there's more than one way to do it.

> Yes, let's not punish our sons and daughters by putting this hideous hack
> in the code. There have been several good suggestions on the ntperl list
> for how to deal with this. Let's not go for the easy hack.

> Backticks and system calls should behave consistantly. Period. Unless
> you plan to build a command interpreter into Perl, there is no reason why
> Perl should be trapping anything. If it does, it is a *hack*. I don't
> think I can use the word "hack" enough here. Hack hack hack hack hack
> hack hack ;)

> *ahem*

> > Cwd is the way to go for new code and code that can be edited.
> > Let's not break old code for the sake of dogmatism. Please.

> It's for the sake of cleaning up the language. I thought the whole
> reason why Larry put out Perl 5 was to clean up the internals and make
> what would hopefully be the last of the changes that break backwards
> compatibility. A system call hack would be a giant step backwards and
> not in the spirit of Perl 5 at all.

> If a function is added to NT Perl that is not added to core Perl for
> performance reasons, I suggest it be something very unwieldy in order to
> encourage people to use the Cwd module. Something like
> "This_is_a_HACKHACKHACK_so_that_pwdless_OSs_can_get_pwd_for_the_Cwd_module()"
> would be alright ;)

> Rob Lanphier
> robla@eskimo.com
> http://www.eskimo.com/~robla


Anything which is O.S. dependant should be moved to a system dependant module.
system(`pwd`) should translate to NT::system(`pwd`) (substitute your OS in
front, where appropriate). The Unix module would just pass most commands on
to the underlying functions, and other O.S.'es could filename munge, execute
their version of the command and fix the return codes, refuse to execute, etc.
Let's get the core of Perl VERY portable and take advantage of Perl5's
object-oriented design to push off the system dependant stuff into the hands
of the experts. This should also simplify development of a perl-based
Java killer by externalizing all system-level functions.

BTW, Malcolm, how is Safe-Perl coming along? I really, really dislike Java
(AKA C--), and would love to use a real language for distributing applications.

tog

Terry Greenlaw (on-site @ Lockheed Martin) Encompass Technologies
z50816@mip.lasc.lockheed.com terry@encompass.is.net

In message <9510280038.AA22762@toad>, Tim Bunce writes:
> > From: stuart@amc.com (Stuart Poulin)
> >
> > > Since:
> > >
> > > 1. There is such a lot of code written to use `pwd`
> > > (including in the standard library modules)
> > > 2. Plus we have have the DOS vs UNC path format issue
> > > 3. Plus we have the \ vs / issue
> > >
> > > I think the best solution is to:
> > >
> > > 1. Trap and fake `pwd` internally to return the UNC path with /'s
> >
> > Some perl I'd write would be targeted only for NT environment. It seems
> > unfortunate that still many of the other apps I use still can't use
> > UNC paths. If pwd only returned UNC paths I'd have to convert it
> > to S:\tupid\drive\letters. Beats me how you ask NT to tell you
> > what drive letter a UNC path is on.
>
> (I guess the idea is that you shouldn't care :-)

Problem is that you cannot chdir into a UNC path although the hot rumor
is that at some later date you should be able to.

-----
Wayne Berke

[ Tim Bunce == tim ]
[ Dave Wolfe == dw ]
[ Tom Horsley ==tom ]

tim> `pwd` is a different problem. If you remove the option of trapping
tim> then an executable called pwd *must* exist in the users path.
tim> Calling it perlpwd won't work.
dw>
dw> This argument assumes the truth of the first ("`pwd` is so widely
dw> used...").
tim>
tim> Easily proven.

A point of order here: The assertion was "`pwd` is used so widely
that" and the argument was "it would *have* to be supplied by default
otherwise the NT port would be 'broken as shiped'." While the assertion
can probably be established to most everyone's satisfaction, I don't
think the argument is easily proven until the indicated action has taken
place.

On to new business:

tim> My bottom line: `pwd` must work - by whatever means.

But that's the entire basis of this discussion. Should it work according
to the semantics of the backtick operator or as a whole expression? I.e.
is the string "pwd" external to Perl and therefore system dependent or
is `pwd` a syntactical aberration that must be taken as a whole term.

tim> I hope we are agreed that Cwd::getcwd() should return the UNC path with
tim> forward slashes.

I'm not so sure about that either. How does one describe a non-shared
directory on a disk? If I have C:\dir, D:\dir, and F:\dir (and none
of C:\, D:\, or F:\ are shared), doing a 'dir \\camel\dir' says "The
network name cannot be found." If I share one of them as "dir", then it
lists the shared directory. Of course, only one of them can be shared as
"dir" at any given time. While it's true that there's always the default
share (C$, D$, and F$ here), are the default share permissions going to
be suitable? (I don't think so, but I'll have to go create a non-admin
logon to try it.) What about stand-alone systems without networking?

tim> Prediction: if `pwd` does not work then almost all NT perl users will
tim> implement a pwd.bat. If they do it'll almost certainly not return
tim> the UNC path with forward slashes in which case we'll have `pwd` and
tim> Cwd::getcwd() giving different results and we'll be in a worse mess.

Counter prediction: if they write a pwd.* that doesn't return a
completely Unix compatible path (*), whatever they were trying to work
around still won't work. System dependencies cannot be so easily swept
under the rug.

* //host/share/dir is *not* a completely Unix compatible path. "//" will
break some things and just try doing something with "//host".

tim> Okay, can we move the debate on to these sugestions:
tim>
tim> 1. Implement a pwd.exe which returns the UNC path with forward slashes.

See above.

tim> 2. Follow Tom Horsley's 'path prefix' suggestion:

tom> One possibility might be to have a registry entry for a perl script
tom> "PATH prefix". The first thing perl would do is modify it's PATH
tom> environment to stick the magic prefix in front of it, then a perl
tom> version of pwd could live there, along with perlglob, and any other
tom> utilities that seem useful but might not want to go in everyone's
tom> regular PATH.

Sure. For some reason I thought that's what the stuff in the registry
was already doing, but when I looked, it didn't seem to be used for
anything but setting up the @INC list.

tim> 3. Modify Cwd getcwd and fastcwd to work on NT and encourage its use.

This must be done anyway.

--
Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598

> From: Wayne Berke <berke@dpw.com>
>
> In message <9510280038.AA22762@toad>, Tim Bunce writes:
> > > From: stuart@amc.com (Stuart Poulin)
> > >
> > > > Since:
> > > >
> > > > 1. There is such a lot of code written to use `pwd`
> > > > (including in the standard library modules)
> > > > 2. Plus we have have the DOS vs UNC path format issue
> > > > 3. Plus we have the \ vs / issue
> > > >
> > > > I think the best solution is to:
> > > >
> > > > 1. Trap and fake `pwd` internally to return the UNC path with /'s
> > >
> > > Some perl I'd write would be targeted only for NT environment. It seems
> > > unfortunate that still many of the other apps I use still can't use
> > > UNC paths. If pwd only returned UNC paths I'd have to convert it
> > > to S:\tupid\drive\letters. Beats me how you ask NT to tell you
> > > what drive letter a UNC path is on.
> >
> > (I guess the idea is that you shouldn't care :-)
>
> Problem is that you cannot chdir into a UNC path although the hot rumor
> is that at some later date you should be able to.

Sigh.

Okay, can someone who knows for sure tell us if it's possible to convert
a local UNC path into a traditional DOS drive+path.

Tim.