[2025-03-07 17:28:15+0100] Alejandro Colomar via austin-group-l at The Open 
Group:
Hi Eric,
On Fri, Mar 07, 2025 at 09:19:34AM -0600, Eric Blake wrote:
On Thu, Mar 06, 2025 at 07:31:56PM +0100, Alejandro C via austin-group-l at The 
Open Group wrote:
> Do we really need the -q option?

The original reporter (Mark Lundblad - illiliti) recommended it and
argued that it is fairly commonly implemented.  The example also shows
it in use:

1. Create and use a temporary file, ignoring failure.
<tt>file=$(mktemp -q file.XXXXXX) && {
  echo ... > "$file" # Use $file within this block
  rm "$file"
}</tt>

But I acknowledge that the same can be accomplished with:

file=$(mktemp file.XXXXXX 2>/dev/null) && {
  ...
  rm "$file"
}

at which point you are right that -q does not buy much functionality,
other than happening to be something to standardize because it is
common among implementations.

I think we shouldn't standardize it.  If one wants to write a small
POSIX system from scratch, aiming minimalism, this flag is absolutely
useless, having the better 2>/dev/null which is useful for every
command.

As a user, I also think it's easier to read the code with 2>/dev/null,
since I don't need to read any documentation to check what flag X to
command Y means.

For systems that already have that flag, it's useful to keep it working
for scripts that already exist, but we don't need to standardize it for
that.

Have a lovely day!
Alex

--
<https://www.alejandro-colomar.es/>

There might be a useful difference between -q and 2>/dev/null
if it's changed to only silence creation errors as seen in some
implementations manuals from note 0006166:
<https://www.austingroupbugs.net/view.php?id=1616#c6166>

While 2>/dev/null would also hide at least:
- name generation errors when custom, like getrandom() failure
- badly formed template errors, for which mkstemp()/mkdtemp() uses EINVAL

On a mote personal note, I found it easy enough to implement this kind of -q,
while if it would be all errors then I'd feel like it would be purely
redundant with 2>/dev/null.

Best Regards

  • [Issue 8 d... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group
      • R... Alejandro C via austin-group-l at The Open Group
        • ... Eric Blake via austin-group-l at The Open Group
          • ... Alejandro Colomar via austin-group-l at The Open Group
            • ... Haelwenn lanodan Monnier via austin-group-l at The Open Group
              • ... Alejandro Colomar via austin-group-l at The Open Group
                • ... 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
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [Issu... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to