Re: [PATCH] Add option like tcsh's dextract

[Tim Eliseo <tre-zsh@xxxxxxxxxxxxxx>]

I posted a patch back in 51958 about which I haven’t seen any new 
comments or commit activity, making me think it got forgotten. Does it 
need further clarification? Maybe the one comment it did receive, which 
inferred that it was redundant, caused it to be dropped by the people 
who do merges? As my sample workaround script illustrates (which, BTW, I 
don’t intend as part of the patch), achieving the original tcsh behavior 
without a builtin option is non-trivial. The takeaway from my 
long-winded introduction is that sometimes it can be small things that 
prevent people from jumping over to zsh.

My previously posted patch still merges cleanly with current master. If 
it was actually just still in the merge queue and not forgotten, and I 
didn't wait long enough, I apologize for the bump.

Tim

On 2023-07-18 02:54:11, Tim Eliseo wrote:
> Hi all!
>
> This is my first post to the group. I’d been using tcsh as an 
> interactive shell since way back when it was still cool, before zsh or 
> bash even existed. Zsh is the first shell that’s a worthy successor. 
> One of the small things that kept me from jumping to bash (along with 
> everyone else in the Linux world) is that it doesn’t have a proper 
> implementation of asynchronous notify of job completion (-b), which 
> zsh does. Another thing that bugged me about bash was that there is no 
> clean way to emulate tcsh’s dextract option, which rearranges the 
> pushd stack differently. I eventually discovered that zsh can do the 
> basic function through the cd/chdir builtin with the auto_pushd option 
> set, but coding a pushd replacement function was complicated to get 
> right for all option cases (see attached).
>
> However, I found that adding this pushd mode to zsh natively was 
> trivial (simply testing for the new option in one place), and I’m 
> still baffled why it wasn’t included a long time ago while someone was 
> looking for ways to increase compatibility with other shells. The 
> attached patch (based on the current master branch) does just that, 
> and I hope you see fit to merge it into the codebase. I believe I’ve 
> done all the appropriate option handling, documentation, and unit test 
> to make this painless. I didn’t write a ChangeLog entry since I wasn’t 
> sure of the appropriate format, or how to derive the number. (Is that 
> an SVN revision number?)
>
> Tim