pushdcycle and pushdignoredups

pushdcycle and pushdignoredups

[Bart Schaefer]

A while back, in his announcement of the test4 release I believe, Zoltan
remarked that he thought my pushdcycle patch still needed some work with
respect to pushdignoredups.

As far as I can tell, the patch already works exactly as it should (that
is, with pushdcycle unset, it works exactly as zsh did before the cyclic
pushd behavior was added).

Just what is it that is still needed?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: pushdcycle and pushdignoredups

[Zoltan Hidvegi]

Bart wrote:
> A while back, in his announcement of the test4 release I believe, Zoltan
> remarked that he thought my pushdcycle patch still needed some work with
> respect to pushdignoredups.
> 
> As far as I can tell, the patch already works exactly as it should (that
> is, with pushdcycle unset, it works exactly as zsh did before the cyclic
> pushd behavior was added).

Well, examining it again I confess that there seems to be no problem with
that patch.  But is it really necessary?  Isn't Functions/pushd enough for
those who prefer the old behaviour?  Generally I do not like to add a
feature which can be achieved using existing shell tools.  Since this
particular case adds so little extra code I am convicable that this feature
may be worth those extra few bytes but where is the border?

Also the number of options in zsh is already large enough to frighten an
average user.

Zoltan

Re: pushdcycle and pushdignoredups

[Bart Schaefer]

On Nov 2,  1:56am, Zoltan Hidvegi wrote:
} Subject: Re: pushdcycle and pushdignoredups
}
} Bart wrote:
} > As far as I can tell, the patch already works exactly as it should
} 
} Well, examining it again I confess that there seems to be no problem with
} that patch.  But is it really necessary?  Isn't Functions/pushd enough for
} those who prefer the old behaviour?

I don't have a strong opinion on that; others can speak up (Peter?).  I
note for your consideration that a function solution can't be put under
the control of the "emulate" command for purposes of other functions that
want to use "pushd" in a specific way.

(Aside:  Isn't there a bug in Functions/pushd ?  It says:

	setopt localoptions
	emulate -R zsh

but "emulate -R zsh" will unsetopt localoptions again.)

} Generally I do not like to add a
} feature which can be achieved using existing shell tools.  Since this
} particular case adds so little extra code I am convicable that this feature
} may be worth those extra few bytes but where is the border?

One place (though not the only one) where I'd draw a line is at adding a
new builtin.  When the existing-tools solution requires that a builtin be
redefined, as in this case, I'm a bit more inclined to add the feature so
that scripts and functions can use it without having to become dependent
on other scripts or functions.

(Aside #2:  Does anybody wish there were an equivalent of "localoptions"
that applied to functions and aliases, so that autoloads could blow away
all the possible screwy redefinitions of builtins from their environment,
yet have them magically restored when the function exits?)

Except for the magic ~1 ~2 etc. syntax, the entire functionality of the
directory stack and pushd/popd/dirs can be achieved with "echo", "cd" and
array assignment.  Down that road lies the "rc" shell, but we long ago
turned away from that.

} Also the number of options in zsh is already large enough to frighten an
} average user.

Which is why we changed `setopt` output to hide most of them most of the
time, right?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: pushdcycle and pushdignoredups

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Nov 2,  1:56am, Zoltan Hidvegi wrote:
> } Isn't Functions/pushd enough for those who prefer the old behaviour?
> 
> I don't have a strong opinion on that; others can speak up (Peter?).  I
> note for your consideration that a function solution can't be put under
> the control of the "emulate" command for purposes of other functions that
> want to use "pushd" in a specific way.

My view was simply that it was a bit rich to expect those who've been
happily using the old behaviour all along suddenly to clutter up their
directories with new functions, particularly since it's *simpler* than
the behaviour now programmed.  I don't have any problem using the
function myself, except of course I have to export it to every
computer I can find and I never do that consistently, but then I never
install new versions of zsh consistently anyway.

> (Aside #2:  Does anybody wish there were an equivalent of "localoptions"
> that applied to functions and aliases, so that autoloads could blow away
> all the possible screwy redefinitions of builtins from their environment,
> yet have them magically restored when the function exits?)

Yes, particularly aliases (I can put with `command ls', but `command
'ls'' is going too far), but as was pointed out not long ago that's
already rather heavily hard-wired into the lexical analyser.

> } Also the number of options in zsh is already large enough to frighten an
> } average user.

As I sort of hint at somewhere in the FAQ, it's a little late to worry
about this now.  It does mean getting the defaults right is important,
though (and I still suggest turning alwayslastprompt on by default
would be a good idea).

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: pushdcycle and pushdignoredups

[Bart Schaefer]

On Nov 4,  9:40am, Peter Stephenson wrote:
} Subject: Re: pushdcycle and pushdignoredups
}
} "Bart Schaefer" wrote:
} > (Aside #2:  Does anybody wish there were an equivalent of "localoptions"
} > that applied to functions and aliases, so that autoloads could blow away
} > all the possible screwy redefinitions of builtins from their environment,
} > yet have them magically restored when the function exits?)
} 
} Yes, particularly aliases (I can put with `command ls', but `command 'ls''
} is going too far)

When does that problem come up?  I can't seem to get it to happen to me,
unless I use "alias -g" in which case I'd *expect* it to happen.

zagzig[337] alias echo
zagzig[338] alias echo='echo x'
zagzig[339] echo
x
zagzig[340] command echo

zagzig[341] function blat() {
function> echo
function> }
zagzig[342] blat
x
zagzig[343] function blat() {
function> command echo
function> }
zagzig[344] blat

zagzig[345]


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: pushdcycle and pushdignoredups

[Peter Stephenson]

"Bart Schaefer" wrote:
> zagzig[338] alias echo='echo x'
> zagzig[343] function blat() {
> function> command echo
> function> }
> zagzig[344] blat
> 
> zagzig[345]

Hmm, something's changed without my noticing it.

% zsh.old
zsh: 17592 segmentation fault (core dumped)  zsh.old     # great, try again
% zsh.old -f
% echo $ZSH_VERSION
2.6-beta11-test10
% alias echo='echo x'
% fn() { command echo; }
% fn
x
% 

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

"alias" vs. "command"

[Bart Schaefer]

On Nov 5,  9:08am, Peter Stephenson wrote:
} Subject: Re: pushdcycle and pushdignoredups
}
} Hmm, something's changed without my noticing it.

What changed was that "command" became a builtin instead of a reserved
word, so the stuff that follows "command" is no longer in the position
to be expanded as an alias.

I think ...

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern