From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28671 invoked by alias); 17 Aug 2016 16:31:50 -0000 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-Seq: 39051 Received: (qmail 836 invoked from network); 17 Aug 2016 16:31:50 -0000 X-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.211.11.3):SA:0(-0.5/5.0):. Processed in 0.253288 secs); 17 Aug 2016 16:31:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at apache.org does not designate permitted sender hosts) Date: Wed, 17 Aug 2016 16:31:41 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] New :P history modifier. Message-ID: <20160817163141.GB9003@tarsus.local2> References: <1471391679-9604-1-git-send-email-danielsh@tarsus.local2> <160817000240.ZM19759@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160817000240.ZM19759@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Wed, Aug 17, 2016 at 00:02:40 -0700: > On Aug 16, 11:54pm, Daniel Shahaf wrote: > } > } WDYT? > > The code changes are essentially OK; my only thought is, maybe we > should just remove the dependency on the POSIX realpath() call even > from :A, and use xsymlink() everywhere? > Two thoughts: - Does anyone actually build zsh on a system that doesn't have realpath()? - xsymlink() is not a drop-in replacement: it tolerates trailing non-existing path components. The single callsite in current master wouldn't care, though. > Picking at the docs ... > > Given that we went to the trouble of hashing it out, it is probably > worth noting that :a is intended to result in the path to along which > "cd" would change under the default setopts (no_chase_dots), 38945 made such a change; do you think further changes are needed? > and :A is meant to result in the physical directory at the end of that > path. No wording comes to mind, here. > > } + "a:absolute path, resolve '..' logically" > } + "A:same, then resolve symlinks" > } + "P:realpath, resolve '..' physically" > > I'm not sure "logical" and "physical" > are the right words here, but "by text replacement" and "by filesystem > reference" seem a bit too verbose, so I don't have a suggestion, just > calling attention. They might work as parentheticals: "a:... logically (by text replacement)" and "P:... physically (by filesystem lookup)"? Some other options: - :a syntactically / lexically / "like 'cd'" - :P semantically / "like stat(2)" (yes, "like 'cd'" is inaccurate if CHASE_* are set) > You should spell out what "same" means, because the two descriptions > may not always appear together. I'll change "same" to "as ':a'". I wonder if there's a way to make the :A completion text convey "Unless you're trying to predict what 'cd' is about to do, you probably want :P, not :A"... > } +The new word modifier ':P' computes the realpath() of the argument. > } +It is different from the existing ':a' modifier which does not resolve > } +symlinks, and from the existing ':A' modifier which always resolves > ^^^^^^^^ > > If you're going to compare to both :a and :A, symlinks aren't the largest > difference vs. :a -- following ".." is. In fact I'd say following ".." > is more important to the distinction than symlinks are. > > } +/before/here/../after to /before/after --- even if /before/here is > } +a symbolic link. It is recommended to review uses of ':A' and, if > } +appropriate, convert them to ':P' as soon as compatibility with 5.2 is > } +no longer a requirement. > > So how about e.g.: > > The new word modifier ':P' computes the physical path of the argument. > it is different from the existing ':a' modifier which does always > resolves /before/here/../after to /before/after, and differs from the > existing ':A' modifier which resolves symlinks only after here/.. is > removed even when /before/here is itself a symbolic link. > Looks good to me. What about the "It is recommended [to audit uses of :A and change them to :P]" sentence that the original patch had, should it be kept or removed? > That's all. Thanks for the review! Daniel