develooper Front page | perl.perl5.porters | Postings from September 2001

Re: [PATCH op.c op.h pp_sys.c t/op/local.t pod/perlfunc.pod] local chdir()

Thread Previous | Thread Next
Benjamin Goldberg
September 4, 2001 22:50
Re: [PATCH op.c op.h pp_sys.c t/op/local.t pod/perlfunc.pod] local chdir()
Message ID:
Bryan C . Warnock wrote:
> It seems, if you wanted to strive for consistency (which you are
> usually a champion of), you'd implement this by fixing the original
> inconsistency - having a description of a program's system state (in
> this case, the current working directory, although, as you mention,
> the umask would also be a good candidate) implemented by a magic
> global, instead of a function.  (Such as uid, gid, program name, etc.)
> [2]  Of course, we're a little short on punctuation characters, and
> $/, besides being taken, would be considered too Unix-centric for some
> folks.

It doesn't need to be a punctuation variable, it can be a ${^FOO} type

We would have ${^CWD}, ${^SELECTED}, and ${^UMASK}

So we could replace:
	select( ( select(FOO), $| = 1 )[0] );
	{ local ${^SELECTED} = *FOO; $| = 1; }

Not to mention, it would be possible to find out what's currently
selected without having to select something else and then restore it.

Plus [and this is more important, IMHO], if we select a filehandle for a
block, and something within the block die()s, local() will restore the
previously selected filehandle -- something the old behavior doesn't do.

> You could do $CWD, or some such, which is exactly what Abigail's
> solution provided (save a name change and the necessity to 'use').
> [1] Of course, 'my' wouldn't make sense, and many of the globals can't
> be lexically scoped, either.
> [2] And given [1], it would make it that much more consistent with the
> other program state variables.

"I think not," said Descartes, and promptly disappeared.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About