From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 31402 invoked from network); 15 Apr 2020 00:45:00 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with UTF8ESMTPZ; 15 Apr 2020 00:45:00 -0000 Received: (qmail 6306 invoked by alias); 15 Apr 2020 00:44:49 -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: List-Unsubscribe: X-Seq: 45699 Received: (qmail 23582 invoked by uid 1010); 15 Apr 2020 00:44:49 -0000 X-Qmail-Scanner-Diagnostics: from wout4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25779. spamassassin: 3.4.4. Clear:RC:0(64.147.123.20):SA:0(-2.6/5.0):. Processed in 4.611677 secs); 15 Apr 2020 00:44:49 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfgjfhfogggtgfesthhqtd dtredtjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgv lhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudejjedruddugedrudegleenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegu rghnihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Date: Wed, 15 Apr 2020 00:44:03 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks Message-ID: <20200415004403.7a974d63@tarpaulin.shahaf.local2> In-Reply-To: <20200414123803.2ps5p475l4kiyfmp@chazelas.org> References: <20200412012155.7954a35f@tarpaulin.shahaf.local2> <20200412021722.GA1748686@zira.vinc17.org> <20200412070930.etfzj6j2qvd5em7b@chazelas.org> <20200412142544.GA1783815@zira.vinc17.org> <20200412173448.rl3wttigdx5t5wcn@chazelas.org> <20200412233845.GB1831017@zira.vinc17.org> <20200413142257.orwzb4jrgmf7gpoi@chazelas.org> <20200413214149.GA2644627@zira.vinc17.org> <20200414061816.5qfbjyc6w3x34wcz@chazelas.org> <20200414120241.3d8d7246@tarpaulin.shahaf.local2> <20200414123803.2ps5p475l4kiyfmp@chazelas.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephane Chazelas wrote on Tue, 14 Apr 2020 13:38 +0100: > 2020-04-14 12:02:41 +0000, Daniel Shahaf: > [...] > > Counter-argument: since an ENOMEM during symlink resolution causes > > =C2=AB(-@)=C2=BB to presume the symlink is broken, the zsh language is > > non-deterministic: what =C2=ABintact-symlink(N-@)=C2=BB will expand to = will > > depend on whether there is enough memory at runtime. > >=20 > > Shouldn't an ENOMEM during expansion of =C2=ABintact-symlink(N-@)=C2=BB= result in > > an error? "In the face of ambiguity, refuse the temptation to guess." > >=20 > > That is: I think there's a qualitative difference between ENOENT and EN= OMEM. =20 > [...] >=20 > ENOMEM/EFAULT/EINVAL are the kind of pathological errors for > which I'd say you can't do much more than best effort. >=20 > If you run out of kernel memory to the point that stat() in your > shell fails, or if bits start to randomly flip causing > EFAULT/EINVAL, more things are going to fail and an inaccurate > glob expansion is probably the least of your concerns. >=20 I'm sure you can imagine other transient failure modes, e.g., a network error with a network-based filesystem. > And what can you do? Check errno after each and every system > call? I am talking about a specific stat(2) syscall in glob.c. > And what's the list of errno values we should consider? > And how should we handle them? If there is agreement that not all errno values should be treated the same way, then we can move on to answering these questions. > How likely is it to happen? Filesystems do get corrupt or go offline from time to time. > What's the worst that can happen if it's not handled "properly"? Depends on how we handle it, obviously. If we handle it by returning an error and aborting the current command line, the worst that can happen is that a command line (or script) would be aborted, whereas currently it would silently continue execution with wrong data. > Can that be exploited? That's a question for the script author. > Say you're the sysadmin that needs to fix that low kernel memory > situation, it's probably better to keep your shell running as > long as possible. No one proposed to kill the shell. An error in an interactive shell just aborts the current command-line and drops the user back to the prompt. > That's a narrow ridge to walk on there. I agree that letting the user > know of that pathological condition is useful, but we need to be > careful the cure be not worse than the disease. >=20 > In any case, I would imagine this kind of consideration has > already been discussed at length here and elsewhere. In anycase, > I'm no expert at all on that.