0001460: hash implementations differ when a utility is not found

Notes
(0005277) joerg (reporter) 2021-03-16 18:22	Do you have other shells than ksh and mksh in mind? There is a problem anyway since hash on these shells is a builtin alias instead of a builtin command.

(0005278) shware_systems (reporter) 2021-03-16 19:01	What type of error report is it, an exit code unequal to zero or just text to stdout/err? If the latter, and they still add remaining found operands, I'd think that's more an App Usage note, that some are silent, some not.

(0005279) kre (reporter) 2021-03-17 03:05	All shells I have tested do the "text to stderr" (not stdout) thing on "hash garbage", all add "ls" in addition to that on "hash garbage ls". The difference is the exit code, the various ksh versions and the NetBSD sh exit 0 (always), bash, zsh, bosh, the FreeBSD sh, dash, yash all exit 1 when something failed to be added.

(0005280) geoffclare (manager) 2021-03-18 09:38	Which version of ksh93 did you test? With 93u+ I get no message on stderr: $ ksh -c 'echo ${.sh.version}; hash garbage; echo status $?' Version AJM 93u+ 2012-08-01 status 0 Tested on Solaris 11.4 and Debian Buster. This matches how ksh88 (/usr/xpg4/bin/sh) behaves on 11.4 (I checked with "type garbage" that neither system has a "garbage" utility to find.) If a later ksh93 has started writing a message to stderr without changing the exit status, that's a new non-conformance (violating 1.4 Utility Description Defaults under STDERR).

(0005284) kre (reporter) 2021-03-18 18:29 edited on: 2021-03-18 18:32	You're right, I didn't look closely enough at that, I got no message from it (or the other ksh variants I tested), and just didn't notice... Apologies.

(0005285) kre (reporter) 2021-03-18 18:52 edited on: 2021-03-18 19:00	I also just noticed, that in the Application Usage section of hash, it says (Lines 92140-2 of Issue 8 draft 1.1 - it is also in older versions) The effects of hash -r can also be achieved portably by resetting the value of PATH; in the simplest form, this can be: PATH="$PATH" That isn't true, at least of the NetBSD sh - for a very long time it has optimised PATH setting wrt the hash table ... rather than invalidate the whole thing, it looks to find the first changed element of the new PATH compared to the old, and only invalidates hash table entries from that point down, so if we had PATH=/a:/b:/c and then changed it to PATH=/a:/x:/b then anything found in /a that was in the hash table remains and remains used, things from /c are removed (obviously) and sp are those from /b. as we don't know that they aren't overridden by what's in /x In particular that means that PATH=${PATH} is a no-op when it comes to what happens to the hash table. If one were to insist on manipulating PATH for this purpose, the way to do it would be x=$PATH; PATH=; PATH=$x; unset x (where 'x' is any variable name that isn't used anywhere else). I see no point in this note in this section, hash -r is the way to remove everything from the hash table, it is less costly than assigning to PATH (even in the simple case given in the current text). Can we just delete it?

(0005287) geoffclare (manager) 2021-03-19 10:57 edited on: 2021-03-19 10:57	Re Note: 0005285, that statement about PATH is pointing out a normative requirement from XCU 2.9.1. In Issue 8 draft 1.1 it's on page 2292 line 74177: Once a utility has been searched for and found (either as a result of this specific search or as part of an unspecified shell start-up activity), an implementation may remember its location and need not search for the utility again unless the PATH variable has been the subject of an assignment. If you think this needs to change please submit a separate bug.

(0005292) kre (reporter) 2021-03-19 16:03	Re Note: 0005287: No I don't think 2.9.1 about this needs to change, but why is not a topic for here, so I will discuss that on the mailing list. However I still believe the relevant text in the hash command application usage section, even if you were right and it follows directly from 2.9.1 (with which I disagree) is inappropriate and should be deleted. One would add an application usage hint like that if there were some defect in the command being described, but an alternative, known working, method was available. Eg: if it were unspecified whether "hash -r" worked or not for clearing the hash table, but assigning to PATH always did, then it would be reasonable to have a note like that. It would also be reasonable if the alternative method were cumbersone, or could have other side effects But "hash -r" is not unspecified, is simple, it does work to clear the hash table. But what is a new reader to believe when reading this Application Usage section and seeing an alternative portable method to clear the hash table? Perhaps "hash -r" is not portable? Better not use that then. The note, even if it were correct, sends entirely the wrong message. It isn't needed. Doing PATH=$PATH is the wrong way even if it worked (in addition to clearing the hash table it also needs to expand $PATH and then do a variable assignment, which also means (as PATH is usually exported) perhaps rebuilding the exported environment for no good reason. Just delete it. On procedural issues, if you'd prefer a new bug, rather than a tack on to this one, for this specific issue, I can do that, but in that case, please indicate whether you would prefer it filed against 7 TC2 or 8 D1.1 (or something else).

(0005296) geoffclare (manager) 2021-03-22 09:40	Re Note: 0005292, since you emphasised portable, I think I now see how we arrived at the current situation. In Issue 6, hash was part of the XSI option. That text in APPLICATION USAGE was put there to advise users of shells that do not have a hash built-in how to achieve the same thing as hash -r without it. In Issue 7, hash was made mandatory and this advice became out-of-date and should have been modified at the time (as should 2.9.1 and/or the description of PATH to mention the hash table). Since this issue is not related to the issue raised in this bug, it should be dealt with in a separate bug (against Issue7+TC2), alongside any related change to 2.9.1 and/or PATH that comes out of the mailing list discussion.

Issue History
Date Modified	Username	Field	Change
2021-03-16 16:53	geoffclare	New Issue
2021-03-16 16:53	geoffclare	Name	=> Geoff Clare
2021-03-16 16:53	geoffclare	Organization	=> The Open Group
2021-03-16 16:53	geoffclare	Section	=> hash
2021-03-16 16:53	geoffclare	Page Number	=> 2847
2021-03-16 16:53	geoffclare	Line Number	=> 93806
2021-03-16 16:53	geoffclare	Interp Status	=> ---
2021-03-16 18:22	joerg	Note Added: 0005277
2021-03-16 19:01	shware_systems	Note Added: 0005278
2021-03-17 03:05	kre	Note Added: 0005279
2021-03-18 09:38	geoffclare	Note Added: 0005280
2021-03-18 18:29	kre	Note Added: 0005284
2021-03-18 18:32	kre	Note Edited: 0005284
2021-03-18 18:52	kre	Note Added: 0005285
2021-03-18 19:00	kre	Note Edited: 0005285
2021-03-19 10:57	geoffclare	Note Added: 0005287
2021-03-19 10:57	geoffclare	Note Edited: 0005287
2021-03-19 16:03	kre	Note Added: 0005292
2021-03-22 09:40	geoffclare	Note Added: 0005296
2021-11-11 15:05	geoffclare	Relationship added	has duplicate 0001534
2021-11-18 16:30	Don Cragun	Status	New => Resolved
2021-11-18 16:30	Don Cragun	Resolution	Open => Accepted
2021-11-18 16:31	Don Cragun	Tag Attached: tc3-2008
2021-12-13 15:00	geoffclare	Status	Resolved => Applied
2024-06-11 09:08	agadmin	Status	Applied => Closed

Aardvark Mark IV