Lawrence Velázquez wrote, on 14 Jan 2025:
>
> On Tue, Jan 14, 2025, at 5:51 AM, Geoff Clare via austin-group-l at The Open 
> Group wrote:
> >
> > [...]
> >
> >     If any file descriptors with numbers greater than 2 are opened by
> >     those redirections, it is unspecified whether those file
> >     descriptors remain open when the shell invokes another utility.
> >
> > [...]
> >
> > So I think his specific use case is not a problem; however I think
> > his mail has brought to light a mismatch between the POSIX wording and
> > implementations.  As I understand it, in ksh this is implemented by
> > setting FD_CLOEXEC on file descriptors greater than 2 when opened by
> > "exec".  This means it would never affect built-in utilities, so I
> > think a better match would be:
> >
> >     ..., it is unspecified whether those file descriptors remain open
> >     when the shell invokes a non-built-in utility.
> >
> > I can't think of any built-ins in POSIX that have the ability to access
> > a specified fd, but it would matter if we ever want to add "read -u" to
> > the standard.
> 
> Does built-in "test -t" count?

I didn't intend "test" to count as one of the "built-ins in POSIX", by
which I meant utilities that are necessarily built-in in order to
conform to POSIX (such as read).

> Does this have unspecified behavior?
> 
>       exec 3>&1
>       test -t 3

Currently yes (because "test" is "another utility"), and with my my
suggested new wording, the answer would still be yes, absent any prior
knowledge that the shell being used has "test" as a built-in (e.g. some
code to use "command -v" to check).

We should perhaps address this particular case by adding a requirement
so that "test -t 3" is well defined.  It could be simply to require
that "test" is always implemented as a shell built-in (which I believe
is true in practice for all non-ancient Bourne-type shells).

-- 
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

  • exec redirec... Christoph Anton Mitterer via austin-group-l at The Open Group
    • Re: exe... Lawrence Velázquez via austin-group-l at The Open Group
      • Re:... Oğuz via austin-group-l at The Open Group
      • Re:... Chet Ramey via austin-group-l at The Open Group
        • ... Martijn Dekker via austin-group-l at The Open Group
          • ... Christoph Anton Mitterer via austin-group-l at The Open Group
            • ... Lawrence Velázquez via austin-group-l at The Open Group
    • Re: exe... Lawrence Velázquez via austin-group-l at The Open Group
      • Re:... Geoff Clare via austin-group-l at The Open Group
        • ... Lawrence Velázquez via austin-group-l at The Open Group
          • ... Geoff Clare via austin-group-l at The Open Group
        • ... Christoph Anton Mitterer via austin-group-l at The Open Group
          • ... Geoff Clare via austin-group-l at The Open Group
      • Re:... Christoph Anton Mitterer via austin-group-l at The Open Group
    • Re: exe... Harald van Dijk via austin-group-l at The Open Group
      • Re:... Christoph Anton Mitterer via austin-group-l at The Open Group
        • ... Oğuz via austin-group-l at The Open Group
      • Re:... Christoph Anton Mitterer via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
          • ... Geoff Clare via austin-group-l at The Open Group
          • ... Steffen Nurpmeso via austin-group-l at The Open Group

Reply via email to