A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1460 
====================================================================== 
Reported By:                geoffclare
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1460
Category:                   Shell and Utilities
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Geoff Clare 
Organization:               The Open Group 
User Reference:              
Section:                    hash 
Page Number:                2847 
Line Number:                93806 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2021-03-16 16:53 UTC
Last Modified:              2021-03-19 16:03 UTC
====================================================================== 
Summary:                    hash implementations differ when a utility is not
found
====================================================================== 

---------------------------------------------------------------------- 
 (0005292) kre (reporter) - 2021-03-19 16:03
 https://www.austingroupbugs.net/view.php?id=1460#c5292 
---------------------------------------------------------------------- 
Re https://www.austingroupbugs.net/view.php?id=1460#c5287: 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). 

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                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to