Re: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

X-seq: zsh-workers 50288

From: Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx>

To: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>

Subject: Re: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

Date: Wed, 25 May 2022 10:22:00 +0000

Accept-language: en-US

Arc-authentication-results: i=2; mx.microsoft.com 1; spf=fail (sender ip is 199.20.13.32) smtp.rcpttodomain=ntlworld.com smtp.mailfrom=pdtpartners.com; dmarc=fail (p=none sp=none pct=100) action=none header.from=pdtpartners.com; dkim=fail (body hash did not verify) header.d=pdtpartners.com; arc=fail (47)

Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pdtpartners.com; dmarc=pass action=none header.from=pdtpartners.com; dkim=pass header.d=pdtpartners.com; arc=none

Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/Kj4uxO+Yuq8ZjjQabe1u4UnumNUwOxurBlkiRN7880=; b=UXwNyVUUAVQa+kve3rNGbqr6jynJgRXX02ZvlcO6QMypHJjBRb6AvKbMpMONBbxYb+O9spy5/MdeAsiCNz1LLxbkVPoEQL+VYB0e/EXz+WZc4u8mYTpOwqJo78hlubh76UUg6R16jeGW4h3Jlsec3wOhumly9Zewqojl4vuqAABNSjfEjNKE+mlFqpkNaq5Lq39A5Q52AA7KHQEYClNm1KzFdZYVkILo7N25Cz0Izkq/9PonxFDCLxqJbyshoxvk2+yBxU+r95CgkderKuNASvb1Vkmwh7vOYBU/a1lrwK22DA2uEUwOvhSB93Wq746Unc7g5GM/G5gO/lL2LeaiPA==

Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GYvKwZOixaW/6D2fC1Ul7PtUcQLGClWh92i+CCU9PWU=; b=lNSNy/kB7dQIhYO4CO917Ikm1zF2cq0cGzAtnGd/q4uaPj6nI1VxwyqfHuWNhwFvjIxnVxSpqml6ikyGXpqgs37fv942G8EAJLFEVhoWDK6/ERSkyMFawXmXvo2ne9D4Qjnab70mjN/3oMVevflk86Cdyhu4/E/eH5Zm5cCHFTd2za0GIUX3xOSEr+/EsPZ+DBiMPUPIASZ3jw6atcERc/VruuIilILSVsKXxU25PorF33ZlueI2Qa9KTTs1xpqCXGs5E+9dUbtZUwDYEjyJO1OOoEC5eHFtVXJV4X0DG19WrgmVR95mBUJVsawXlxtOG9TGJIUITOsRIOPIVJQG1Q==

Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=fail; b=cDlGbTYDk5oHesCvrb4+SM88W46Gie/rIzBVKSLQR+PHNpHgSR7ONSqMAFdkJQ0eZnNnlAgbQk5yTLFzAfb3lvu+6iTCOBzmkzyy3y+GsKfKc+RPm1DELrhtpuGybRd1aGLUbSxArTvUVQtFAa8Cjf14H5aUud3uHgBwCpBn8lOD3FRxXSQBEgGKprmyaswU9QTxqE4ZoD9QGUaQzEYEAdqhq3jFDcEzcfC53uk9khR839GLlrn8OvQcKNxFQIfp/0LaiTST3eAFtwOTRc93ujfYJo1ejBu1NGJYZVOMEzEUMXzWodZ2OciYLXyJMUxRlFD87wPqvkCJEuZ92nyUmw==

Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EL09167rg22+1MJS8UwCalMNiXadyPhs2qV4wRQDAWBeahAW13o+tmEwKp8UZJD+hPgY1XWhbpmwFo7eHYu1jNZCAKlGomrjYp7pmwS4NFyH/5X8p2rLOrzdxrBThRVCn7jaMk5nB0DgJkQRPJpmW98VDQ+vDKtxsOyeLYwkwoi0isLS6pOKD15I7CJGuo+PQi4UzXd9esJnRx4AHzKJRscmtkU2IuDVqjR1l6KWX5xdEMbc+0E90g9Xvgl/k1PGZQ4f/Sm4UVGu4huum/ziIH6GNjaZtTQmMVEwMIQdWpzksjjy04Gb8LgLWIF/1Grn/vriRrda/kUkOIyhzMqcDQ==

Archived-at: <https://zsh.org/workers/50288>

In-reply-to: <1126442111.366927.1653472386462@mail2.virginmedia.com>

List-id: <zsh-workers.zsh.org>

References: <CY5PR20MB4843E231D8BA513A209C6541C1D39@CY5PR20MB4843.namprd20.prod.outlook.com> <200084252.242457.1653041722599@mail2.virginmedia.com> <1126442111.366927.1653472386462@mail2.virginmedia.com>

Thread-index: AQHYbDEPYF0J/kRF40qfVUNFCmBzxq0njKUAgAfVbwCAAAaZRg==

Thread-topic: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

> Will it be worth seeing what effects the following has?

This resolves the issue for me -- verified with strace. Thanks.

From: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Date: Wednesday, May 25, 2022 at 10:53 AM
To: Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx>, zsh-workers@xxxxxxx <zsh-workers@xxxxxxx>
Subject: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

> On 20 May 2022 at 11:15 Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
> On 20 May 2022 at 11:08 Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx> wrote:
> > I have looked through some threads in the mailing list to find out why
> > zgetdir > is being used over getcwd in the first place. It seems it was
> > implemented this way in the 1990s to work around a bug in some implementations
> > of getcwd, which should not be a concern on modern systems.
> >
> > I was wondering if zgetdir is still the right way to do this? Are there
> > use cases where it is preferred over getcwd? Maybe zgetcwd could simply
> > use getcwd primarily (i.e. not as fallback), or perhaps USE_GETCWD could
> > be enabled by default (currently it is only enabled on QNX builds).
>
> The best bet would probably be to try that by default once we're sure the
> release is out of the way --- as you say there's a good chance that's the
> right way to go now and I don't think we're going to find out the problems
> any other way.

Will it be worth seeing what effects the following has?

pws

diff --git a/configure.ac b/configure.ac
index c72148d06..77e381f50 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2021,11 +2021,15 @@ if test x$zsh_cv_sys_superroot = xyes; then
fi

dnl CHECK FOR SYSTEMS REQUIRING GETCWD
+dnl This is now turned on by default, as we expect modern getcwd
+dnl implementations to work correctly. Any exceptions should be added
+dnl to the first case. Currently there are none, hence it is forced
+dnl not to match.
AC_CACHE_CHECK(whether we should use the native getcwd,
zsh_cv_use_getcwd,
[case "${host_cpu}-${host_vendor}-${host_os}" in
-    *QNX*) zsh_cv_use_getcwd=yes ;;
-    *) zsh_cv_use_getcwd=no ;;
+    *NOMATCH*) zsh_cv_use_getcwd=no ;;
+    *) zsh_cv_use_getcwd=yes ;;
esac])
AH_TEMPLATE([USE_GETCWD],
[Define to 1 if you need to use the native getcwd.])

This communication is intended only for the addressee(s), may contain confidential, privileged or proprietary information, and may be protected by US and other laws. Your acceptance of this communication constitutes your agreement to keep confidential all the confidential information contained in this communication, as well as any information derived by you from the confidential information contained in this communication. We do not waive any confidentiality by misdelivery.

If you receive this communication in error, any use, dissemination, printing or copying is strictly prohibited; please destroy all electronic and paper copies and notify the sender immediately. Nothing in this email is intended to constitute (1) investment or trading advice or recommendations or any advertisement or (2) a solicitation of an investment in any jurisdiction in which such a solicitation would be unlawful.

Please note that PDT Partners UK, LLP, including its affiliates, reserves the right to intercept, archive, monitor and review all communications to and from its network.

Reverse Date

Date

Thread

Author