On Thu, Apr 21, 2005 at 08:22:29AM +0200, Johan Vromans wrote:
: >From the perspective of 'current directory' there should also be a
: simple and elegant way that will do in most cases. Advanced tricks can
: be made possible using separate modules and such.
Yes, easy things should be easy, and har
Johan Vromans skribis 2005-04-21 8:22 (+0200):
> This is exactly the point (I think) Schwern is trying to make. There
> is 'open', that will do most of the time. If a novice user asks how to
> open a file, you can say "Well, just 'open $fh, $file'". If you want
> more than vanilla file access, th
Chip Salzenberg <[EMAIL PROTECTED]> writes:
> According to Michael G Schwern:
>> In the same way that we have open() not fopen, fdopen, freopen... we
>> can choose the safest and most sensible technique for determining
>> the cwd and use that.
>
> And there is more than one open. Perl does have f
Chip Salzenberg wrote:
As you know, under Unix, there's no such thing as "the current
directory" as a string. The only durable current directory is the
device and inode of C. It's not wise to conflate the
current directory with a name that at some point in the past could
have been used to reach i
According to Michael G Schwern:
> Yes, there are lots of ways to check the cwd each filling in one edge
> case or another. However I'd like to believe its possible to come up with
> one simple, safe cwd() that works for 99.9% of the cases and call that cwd().
Well, it's certainly possible ... and
On Saturday 16 April 2005 01:53, Michael G Schwern wrote:
> How cwd() is implemented is not so important as what happens when it hits
> an edge case. So maybe we can try to come up with a best fit cwd(). I'd
> start by listing out the edge cases and what the possible behaviors are.
> Maybe we
On Fri, Apr 15, 2005 at 09:32:23PM -0400, Chip Salzenberg wrote:
> > Perl 6 is going to have to decide on some sort of standard internal getcwd
> > technique, $CWD or not.
>
> I don't think Perl 6 "has" to do anything of the kind. It would
> be a mistake to try.
Sorry, I had assumed that having
According to Michael G Schwern:
> On Fri, Apr 15, 2005 at 08:31:57PM -0400, Chip Salzenberg wrote:
> > There are several methods to determine the current directory.
>
> Perl 6 is going to have to decide on some sort of standard internal getcwd
> technique, $CWD or not.
I don't think Perl 6 "has"
On Fri, Apr 15, 2005 at 08:31:57PM -0400, Chip Salzenberg wrote:
> According to Michael G Schwern:
> > And this is exactly what File::chdir does. $CWD is a tied scalar.
>
> I don't think current directory maps well on a variable. That won't
> stop people from using it, of course. :-(
>
> There
According to chromatic:
> On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
> > Well, after failure it can be cwd() but false without breaking any real
> > code, because normally, you'd never if (cwd) { ... }, simply because
> > there's ALWAYS a cwd.
>
> Not always -- try removing a directory that's
According to Michael G Schwern:
> And this is exactly what File::chdir does. $CWD is a tied scalar.
I don't think current directory maps well on a variable. That won't
stop people from using it, of course. :-(
There are several methods to determine the current directory. Each
one has its corn
On Fri, Apr 15, 2005 at 03:22:48PM -0700, Michael G Schwern wrote:
: On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
: > > becomes an unverifiable operation. You have to use chdir() if you want to
: > > error check and $CWD is reduced to a "scripting" feature.
: >
: > Well, after failure i
On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
> > becomes an unverifiable operation. You have to use chdir() if you want to
> > error check and $CWD is reduced to a "scripting" feature.
>
> Well, after failure it can be cwd() but false without breaking any real
> code, because normally,
chromatic skribis 2005-04-15 15:18 (-0700):
> > Well, after failure it can be cwd() but false without breaking any real
> > code, because normally, you'd never if (cwd) { ... }, simply because
> > there's ALWAYS a cwd.
> Not always -- try removing a directory that's the pwd of another
> process.
R
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
> Well, after failure it can be cwd() but false without breaking any real
> code, because normally, you'd never if (cwd) { ... }, simply because
> there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd of another
process.
-- c
On Fri, Apr 15, 2005 at 01:12:46PM -0700, Michael G Schwern wrote:
: Thus spake Larry Wall:
: > Offhand, I guess my main semantic problem with it is that if a chdir
: > fails, you aren't in an undefined location, which the new value of $CWD
: > would seem to indicate. You're just where you were.
Michael G Schwern skribis 2005-04-15 13:12 (-0700):
> To be clear: Only the store operation will return undef on failure.
> Additional fetches on $CWD will continue to return the cwd.
Still breaks
$ref = \($CWD = $foo);
I'm not sure this breakage matters, but if it breaks one thing, it's
Thus spake Larry Wall:
> Offhand, I guess my main semantic problem with it is that if a chdir
> fails, you aren't in an undefined location, which the new value of $CWD
> would seem to indicate. You're just where you were. Then the user
> either has to remember that, or there still has to be some
On Fri, Apr 15, 2005 at 03:11:59AM -0700, Michael G Schwern wrote:
: Error handling is simple, a failed chdir returns undef and sets errno.
:
: $CWD = $dir err die "Can't chdir to $dir: $!";
Offhand, I guess my main semantic problem with it is that if a chdir
fails, you aren't in an undefin
19 matches
Mail list logo
