Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from <danielsh@apache.org>, 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 <d.s@daniel.shahaf.name>
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)
X-Seq: zsh-workers 39051

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

