Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001534 [Issue 8 drafts] Shell and Utilities Comment Clarification Requested 2021-11-09 08:14 2021-11-18 16:32
Reporter oguzismailuysal View Status public  
Assigned To
Priority normal Resolution Duplicate  
Status Closed   Product Version Draft 2.1
Name oguz
Organization
User Reference
Section XCU Chapter 3, hash, EXIT STATUS
Page Number 2808
Line Number 93436
Final Accepted Text
Summary 0001534: exit status of hash needs clarification
Description The standard is unclear on what constitutes a 'successful completion' or an 'error' for the hash utility, and there seems to be no consensus among implementations as of yet; for example, on bash, bosh, ash-clones except netbsd sh, yash, and zsh, the command:

hash command_that_does_not_exist

returns 1, whereas the same command returns 0 on netbsd sh, ksh88, ksh93, and pdksh-clones. Given existing behavior, it's hard to tell if a failure to find the named utility is an error or not, or if the shells that return 0 when that happens are broken.


And although the language used in XCU 2.9.1.4 suggests that remembrance of utility locations is an optional feature, the spec. for the hash utility does not take (hypothetical) implementations that choose not to support this feature into account. It's unclear whether such an implementation should still perform a PATH search for `hash command_name' and return a value indicating whether `command_name' is found or not, or implement the hash utility at all.
Desired Action Clarify what exactly 'successful completion' means for the hash utility (and preferably also how shells that don't remember utility locations should implement it).
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0001460Applied 1003.1(2016/18)/Issue7+TC2 hash implementations differ when a utility is not found 

-  Notes
(0005520)
kre (reporter)
2021-11-09 15:02

 I believe the NetBSD sh to be broken here, and I will fix it, but I
am not yet sure what the fix will be.

Not broken because hash does exit(0) when a utility is not found,
but broken because it writes an error to stderr in that case, and
still does exit(0), which is a combination that should not exist.

So, either I have it exit(1) or stop issuing the error message.

The "reference shell" (ie: ksh88 - and all other ksh variants) do it
the latter way, no error message, & exit(0), with nothing added to the
hash table in the case of utility not found. Since the standard does
not say that failing to locate the utility is an error, that's a reasonable
position.

So is issuing an error, and doing exit(1) the way that all the other non-ksh
shells behave.

At this point, given this divergence, I believe that all the standard can
say is that it is unspecified whether failing to locate a utility is an
error or simply results in nothing happening.

Errors that can orrur, which should definitely cause exit(>0) are usage
errors (unknown option) and (if we believe all the noise about this kind
of thing in another context) write errors to stdout in the case where no
utility names (and no -r option) are given.
(0005521)
oguzismailuysal (reporter)
2021-11-10 05:20

 Re Note: 0005520
I tend to favor the bash behavior here, failing to locate the utility does feel like an error. Besides, `hash progname 2>/dev/null' for testing if a program is installed seems to have already made its way into supposedly portable bootstrap scripts (probably because it's shorter than `command -v progname >/dev/null 2>&1', and works on some bourne variants that don't support the latter).
(0005522)
geoffclare (manager)
2021-11-11 15:05

 This is a dup of bug 0001460

- Issue History
Date Modified Username Field Change
2021-11-09 08:14 oguzismailuysal New Issue
2021-11-09 08:14 oguzismailuysal Name => oguz
2021-11-09 08:14 oguzismailuysal Section => XCU Chapter 3, hash, EXIT STATUS
2021-11-09 08:14 oguzismailuysal Page Number => 2808
2021-11-09 08:14 oguzismailuysal Line Number => 93436
2021-11-09 15:02 kre Note Added: 0005520
2021-11-10 05:20 oguzismailuysal Note Added: 0005521
2021-11-11 15:05 geoffclare Note Added: 0005522
2021-11-11 15:05 geoffclare Relationship added duplicate of 0001460
2021-11-18 16:32 Don Cragun Status New => Closed
2021-11-18 16:32 Don Cragun Resolution Open => Duplicate

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