Hi Haelwenn,

On Sat, Mar 08, 2025 at 07:03:44AM +0100, Haelwenn (lanodan) Monnier wrote:
> > If -q should not be equivalent to 2>/dev/null, this should be well
> > documented in the standard.  The current text listed in
> > <https://www.austingroupbugs.net/view.php?id=1616> doesn't sound good to
> > me.  So, either the feature should be removed, or the specification
> > should be fixed.   And if we keep it, we should make sure that all
> > implementations behave like that (or that the implementations that
> > differ would be willing to adapt, or are going to EOL soon).
> 
> Only one noted in the ticket seems to be uutils's mktemp,
> which in theory is supposed to match GNU coreutils given it
> inherits it's testsuite.

Are they willing to adapt?  Did anyone ask them?

> And GNU coreutils documents -q as "suppress diagnostics about 
> file/dir-creation failure"

BTW, I don't have a BSD to try, but the BSD documentation doesn't
clarify that -q is about fs errors.

> 
> With checking both the code and behavior, it seems like uutils mktemp
> -q only hides creation errors.
> 
> <https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/src/mktemp.rs>
> 
> $ apk info -ev uutils
> uutils-0.0.29-r0
> $ uutils mktemp -q wrong_template
> mktemp: too few X's in template 'wrong_template'
> $ uutils mktemp -q too.XXXXXX many.XXXXXX templates.XXXXXX
> mktemp: too many templates
> Try 'uutils mktemp --help' for more information.
> $ uutils mktemp /root/no_perms.XXXXXX
> mktemp: Permission denied (os error 13) at path "/root/no_perms.uMejNY"
> $ uutils mktemp -q /root/no_perms.XXXXXX
> $ uutils mktemp -p /var/empty/enoent tmp.XXXXXX
> mktemp: failed to create file via template '/var/empty/enoent/tmp.XXXXXX': No 
> such file or directory
> $ uutils mktemp -q -p /var/empty/enoent tmp.XXXXXX
> $ TMPDIR=/var/empty/enoent uutils mktemp -t tmp.XXXXXX
> mktemp: failed to create file via template '/var/empty/enoent/tmp.XXXXXX': No 
> such file or directory
> $ TMPDIR=/var/empty/enoent uutils mktemp -q -t tmp.XXXXXX
> $

This sounds reasonable.  It's a real feature, and not just an alias for
2>/dev/null.  As long as it's well specified and all implementations
either already behave like that or are willing to move, I guess it's
fine.


Have a lovely day!
Alex

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

Attachment: signature.asc
Description: PGP signature

  • [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
    • [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