From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20947 invoked by alias); 13 Jul 2016 07:41:57 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21757 Received: (qmail 21103 invoked from network); 13 Jul 2016 07:41:57 -0000 X-Qmail-Scanner-Diagnostics: from fw.sigpipe.cz 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(213.192.55.98):SA:0(-1.3/5.0):. Processed in 0.22607 secs); 13 Jul 2016 07:41:57 -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=-1.3 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: neuhauser@sigpipe.cz X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at sigpipe.cz does not designate permitted sender hosts) Date: Wed, 13 Jul 2016 09:41:51 +0200 From: Roman Neuhauser To: Bart Schaefer Cc: zsh-users@zsh.org Subject: Re: Next release (5.3) Message-ID: <20160713074151.GH1537@isis.sigpipe.cz> References: <20160712075849.GG1537@isis.sigpipe.cz> <160712094017.ZM17395@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160712094017.ZM17395@torch.brasslantern.com> User-Agent: Mutt/1.6.1 (2016-04-27) # schaefer@brasslantern.com / 2016-07-12 09:40:17 -0700: > On Jul 12, 9:58am, Roman Neuhauser wrote: > } I understand the issue is that although zshexpn(1) claims... > } > } This call is equivalent to `a` unless your system has the realpath > } system call (modern systems do). > } > } ... this is not the case. Correct? Well, I use it for this > } exact purpose. > > Your statement is going to require some clarification. By "exact purpose" > do you mean "as a replacement for realpath"? yes. > The documentation says: > > 1. resolution of `..' occurs _before_ resolution of symbolic links > 2. equivalent to a unless your system has the realpath system call > > These are not contraditory but they explicitly do NOT mean that :A > is a replacement for realpath. All that (2) means is :A does NOT > follow symbolic links unless realpath is available to do that work. alright. i gotta admit that i misunderstood the manpage as saying that if :A is equivalent to realpath(3) if i have it, and :a otherwise. i know, i should have known better and read the manpage with my lawyer hat on. sloppy reading on my part. however, re "explicit": the :A description is anything but! : A As `a', but also resolve use of symbolic links where possible. : Note that resolution of `..' occurs before resolution of : symbolic links. This call is equivalent to a unless your : system has the realpath system call (modern systems do). so what exactly does it do if i *do* have realpath(3)? > You go on to say: > > } > [...] "$foo" and "$foo:a" might also denote different > } > files, so why is *that* a useful transformation? > } > } It's not, and I don't use it. > > Per my two points above, on any system that lacks realpath, you DO use > :a implicitly, because :A does not differ from :a when there is no > realpath underneath. yes in principle, not in practice. i may be lucky but it's all relatively modern GNU/Linux or *BSD around me. my scripts have no users on systems without realpath(3), and wouldn't work on such systems for other reasons anyway. > } > > (1) Daniel's suggested change to :A [care to offer an opinion?] > } > > } > I'd be vaguely inclined to make sure it does what the doc currently > } > says and leave it at that. > } > } I'd prefer (it would *fix* my scripts) this to happen. > > You'd prefer what? :A presently DOES what the doc currently says. > PWS's comment in effect means he's inclined to change nothing. right, i was writing that based on my misunderstanding of the manpage (see above). > If what you mean is that you'd prefer that :A is a replacement for > realpath with all the same semantics as realpath, then you're now > requesting something that wasn't previously being discussed. right, sorry for that. i'll crawl back under my rock shortly. :) > The present situation is: > > 1. :a performs a string-manipulation on the path to remove any > relative path segments. > 2. :A does (1) and then calls realpath on the result. > > This matches the documentation. > > Daniel is arguing that (1) is essentially useless and calling realpath > after that may give a different result than realpath on the original > path string. His suggestion is: > > 1. :a is as before > 2. :A calls realpath, and does (1) only if there is no realpath i agree with Daniel regarding limited utility of :a, and i already (mis)use :A as if it was doing 2. i don't care about the fallback to :a since systems where that happens are outside my universe. > The emerging consensus seems to be for: > > 1. :a is as before > 2. :A is as before > 3. new modifier calls realpath and does (1) if no realpath re "does (1) if no realpath": really (1), not (2)? > Is there one of those three cases with which you agree, or are you in > fact asking for zsh to re-implement realpath internally? in order of decreasing preference: 1 change the meaning of :A so that it is equivalent to realpath(3) where it exists and to :a on systems without realpath(3) 2 new modifier that calls realpath(3) with fallback to :A 3 new modifier that calls realpath(3) with fallback to :a if i could have a pony then the most favorable solution would be 0 change the meaning of :A so that it is always equivalent to realpath(3), using an implementation bundled with Zsh where necessary -- roman