A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1616 
====================================================================== 
Reported By:                illiliti
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1616
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Mark Lundblad 
Organization:                
User Reference:              
Section:                    Shell and Utilities 
Page Number:                - 
Line Number:                - 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2022-11-08 23:03 UTC
Last Modified:              2025-03-07 21:54 UTC
====================================================================== 
Summary:                    Standardize mktemp utility
====================================================================== 

---------------------------------------------------------------------- 
 (0007101) eblake (manager) - 2025-03-07 21:54
 https://www.austingroupbugs.net/view.php?id=1616#c7101 
---------------------------------------------------------------------- 
Responding to https://www.austingroupbugs.net/view.php?id=1616#c7100:
I'm ambivalent on whether -q should be standardized, since it is redundant with
2>/dev/null.  Even if we decide to exclude it from the next attempted revision
of text, it should at least be mentioned in the non-normative text, since it
does seem to be present in a number of implementations.

Tweaking the wording to emphasize that a NEW file / directory is created is
worthwhile. In fact, while we were reviewing the current proposed text, we noted
that "OUTPUT FILES None.", although consistent with some other utilities in the
standard (mkdir, sh, m4, ...), was misleading, and we will be opening a separate
bug to address that more uniformly in existing utilities.

I'm still trying to figure out how many implementations output relative names,
and if there is ever a case where an implementation outputs a relative name that
is NOT relative to the current working directory where mktemp was executed -
that would be undesirable.  But since more than just GNU Coreutils mktemp (where
I'm listed as one of the original authors, although it's been years since I last
touched that code) appear to have modes with relative outputs, it is very likely
that the next revision will allow relative output, and as such improve the
examples to use rm -- "$file" to match.

As for the </tt>, it turns out that Mantis recognizes <pre>&lt;pre&gt;</pre> but
not <pre>&ls;tt&gt;</tt>; I've updated that typo fix in-place.

The idea of a FUTURE DIRECTIONS adding support for templating in a suffix is
nice; in fact, we may want to standardize mkstemps(3) or mkostemps(3) in XSH (at
least GNU libc has those), at which point having mktemp(1) also do suffixing in
XCU is an obvious idea. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2022-11-08 23:03 illiliti       New Issue                                    
2022-11-08 23:03 illiliti       Name                      => Mark Lundblad   
2022-11-08 23:03 illiliti       Section                   => Shell and Utilities
2022-11-08 23:03 illiliti       Page Number               => -               
2022-11-08 23:03 illiliti       Line Number               => -               
2022-11-08 23:30 steffen        Note Added: 0006038                          
2022-11-09 13:18 illiliti       Note Added: 0006041                          
2023-02-22 13:30 ormaaj         Note Added: 0006166                          
2023-02-22 19:10 ormaaj         Note Edited: 0006166                         
2025-02-28 18:37 eblake         Note Added: 0007089                          
2025-03-06 11:09 geoffclare     Note Added: 0007093                          
2025-03-06 11:10 geoffclare     Note Edited: 0007093                         
2025-03-06 11:10 geoffclare     Note Edited: 0007093                         
2025-03-06 11:11 geoffclare     Note Edited: 0007093                         
2025-03-06 15:15 eblake         Note Edited: 0007093                         
2025-03-06 15:53 geoffclare     Note Edited: 0007093                         
2025-03-06 17:19 stephane       Note Added: 0007095                          
2025-03-06 18:02 lanodan        Note Added: 0007097                          
2025-03-06 18:04 lanodan        Note Edited: 0007097                         
2025-03-06 18:05 lanodan        Note Edited: 0007097                         
2025-03-07 15:11 eblake         Note Added: 0007098                          
2025-03-07 15:14 eblake         Note Added: 0007099                          
2025-03-07 20:41 dwheeler       Note Added: 0007100                          
2025-03-07 21:46 eblake         Note Edited: 0007093                         
2025-03-07 21:54 eblake         Note Added: 0007101                          
======================================================================


              • ... Haelwenn lanodan Monnier via austin-group-l at The Open Group
              • ... Alejandro Colomar via austin-group-l at The Open Group
              • ... Haelwenn Monnier via austin-group-l at The Open Group
              • ... Alejandro Colomar via austin-group-l at The Open Group
              • ... Lawrence Velázquez via austin-group-l at The Open Group
              • ... Alejandro Colomar via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
    • Re: [... Alejandro Colomar via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [Issue 8 d... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to