zsh-users
 help / color / mirror / code / Atom feed
From: Roman Neuhauser <neuhauser@sigpipe.cz>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-users@zsh.org
Subject: Re: Next release (5.3)
Date: Wed, 13 Jul 2016 09:41:51 +0200	[thread overview]
Message-ID: <20160713074151.GH1537@isis.sigpipe.cz> (raw)
In-Reply-To: <160712094017.ZM17395@torch.brasslantern.com>

# 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


  parent reply	other threads:[~2016-07-13  7:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05  4:57 realpath(3), symlinks, '..' components, and the ':A' word modifier Daniel Shahaf
2016-07-05 12:54 ` Roland Eggner
2016-07-05 13:24 ` Vadim Zeitlin
2016-07-06 15:15   ` Filipe
     [not found] ` <20160705125430.GA29959__3886.85245202414$1467723835$gmane$org@mobil.systemanalysen.net>
2016-07-07  2:00   ` Daniel Shahaf
2016-07-07 17:20     ` Bart Schaefer
     [not found]       ` <20160705093321.79d7c4bc@pwslap01u.europe.root.pri>
2016-07-12  7:58         ` Next release (5.3) Roman Neuhauser
2016-07-12 16:40           ` Bart Schaefer
2016-07-12 20:23             ` Oliver Kiddle
2016-07-13  2:56               ` Filipe Silva
2016-07-13  4:45                 ` Bart Schaefer
2016-07-13  5:09                   ` Filipe Silva
2016-07-13  9:32               ` Peter Stephenson
2016-07-13  9:59                 ` Peter Stephenson
2016-07-13 16:35                   ` Bart Schaefer
2016-07-13 16:59                     ` Peter Stephenson
2016-07-13 17:50                       ` Bart Schaefer
     [not found]                 ` <20160713105910.2b33701c__17004.846657119$1468404086$gmane$org@pwslap01u.europe.root.pri>
2016-07-17 14:59                   ` Daniel Shahaf
     [not found]               ` <20160713103233.14bfd05a__26126.9551389434$1468402471$gmane$org@pwslap01u.europe.root.pri>
2016-07-17 14:59                 ` [PATCH] improve :A docs (was: Re: Next release (5.3)) Daniel Shahaf
     [not found]                 ` <20160717145931.GA4859__10178.6871244714$1468767679$gmane$org@tarsus.local2>
2016-07-20  6:54                   ` Daniel Shahaf
2016-07-13  7:41             ` Roman Neuhauser [this message]
2016-07-13 17:36               ` Next release (5.3) Bart Schaefer
2016-07-20 13:05             ` Vincent Lefevre
2016-07-20 14:00               ` Vincent Lefevre
2016-07-20 14:15                 ` Peter Stephenson
2016-07-20 14:19                   ` Peter Stephenson
     [not found]                 ` <20160720151517.6a833f2c__37436.2382958227$1469024822$gmane$org@pwslap01u.europe.root.pri>
2016-07-21  5:40                   ` Daniel Shahaf
2016-07-21  9:19                     ` Peter Stephenson
2016-07-21  3:50               ` Bart Schaefer
     [not found]           ` <160712094017.ZM17395__33553.1437922784$1468341719$gmane$org@torch.brasslantern.com>
2016-07-13  5:00             ` Daniel Shahaf
     [not found]       ` <20160712075849.GG1537__20664.8654224866$1468310440$gmane$org@isis.sigpipe.cz>
2016-07-13  5:01         ` Daniel Shahaf
2016-07-20 12:44       ` realpath(3), symlinks, '..' components, and the ':A' word modifier Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160713074151.GH1537@isis.sigpipe.cz \
    --to=neuhauser@sigpipe.cz \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).