Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001460 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Clarification Requested 2021-03-16 16:53 2021-12-13 15:00
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section hash
Page Number 2847
Line Number 93806
Interp Status ---
Final Accepted Text
Summary 0001460: hash implementations differ when a utility is not found
Description The behaviour of the hash builtin differs between shells as to whether they report an error when a utility specified as an operand is not found. For example, bash reports an error but ksh (88 and 93) does not.
Desired Action After:
The name of a utility to be searched for and added to the list of remembered locations.
add a new sentence:
If the search does not find utility, it is unspecified whether or not this is treated as an error.

Tags tc3-2008
Attached Files

- Relationships
has duplicate 0001534Closed Issue 8 drafts exit status of hash needs clarification 

-  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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker