Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Fri, 01 Jul 2016 05:11:06 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH v2 2/3] Fix the ':A' word modifier on paths with '..' components. Message-ID: <20160701051106.GA31422@tarsus.local2> References: <20160613085218.GA9572@tarsus.local2> <1466474004-4669-1-git-send-email-danielsh@tarsus.local2> <1466474004-4669-2-git-send-email-danielsh@tarsus.local2> <20160625162807.GA9840@tarsus.local2> <20160627002031.GA20366@tarsus.local2> <160628074851.ZM26955@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <160628074851.ZM26955@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Seq: zsh-workers 38774 Bart Schaefer wrote on Tue, Jun 28, 2016 at 07:48:51 -0700: > Therefore I think the only reasonable solutions are: > (1) keep the current default and respect CHASE_DOTS to get the function > Daniel wants, or > (2) change the default and use :a:A to get the old behavior. > > I lean slightly towards (1) but only because the doc has explicitly > called out the "resolve .. first" behavior for the past 7 years. What's the use-case for the "resolve '..' before symlinks" behaviour? There doesn't seem to be a C stdlib function for it. That behaviour (and the :A modifier) was added in 26731, but that thread doesn't answer this question. Was it an intentional design feature, or simply a documented bug? (Honest question.) > I floated the idea of testing CHASE_DOTS so that there would be a way > to globally revert to the old behavior without having to update a lot > of scripts, but I hadn't considered the "backward" semantics, and I'm > not in favor of introducing a new option specifically for :A control. (Perhaps instead of a new option, a new syntax; e.g., have $foo:A retain its meaning and $foo:A:A have the new meaning. Or make :A take an optional argument.) I get that a multitude of options is undesirable, and that making the new behaviour conditional on an unset-by-default option helps compatibility, but I'm wary of making a single option have two distinct effects. Each knob should do one thing and do it well. Making chasedots affect both 'cd' and :A will cause one of two things: either scripts that 'emulate -L zsh && setopt chasedots' for the setopt's effect on 'cd' will get the new :A behaviour without explicitly opting in to it [which seems to be your goal here], or people who wish :A to behave like realpath(3) will have to use the chasedots version of 'cd'. > However, with the current implementation there is NO way to obtain the > semantics Daniel wants. Thanks, Daniel