Re: read with redirected stdin

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Roman Perepelitsa wrote on Sun, Jan 08, 2023 at 14:48:24 +0100:
> On Sun, Jan 8, 2023 at 2:30 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Roman Perepelitsa wrote on Sat, Jan 07, 2023 at 18:31:30 +0100:
> > > On Sat, Jan 7, 2023 at 6:22 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
> > > >
> > > > Thanks, but i don't _always_ redirect stdin.
> > >
> > > The code will still work (except for the corner case I mentioned).
> > >
> > > Upon further thinking, the following should work in all cases:
> > >
> > >     if [[ -n $TTY ]]; then
> > >       # There is a terminal. Read from it.
> > >       read -k1
> > >     else
> > >       # There is no terminal. Read from stdin.
> > >       read -k1 -u0
> > >     fi
> >
> > Would it be useful to provide a ctermid(3) wrapper in zsh/system?
> 
> Where would it be useful?

In your code snippet quoted here?

> Doesn't $TTY already provide a better alternative?

$TTY could be unset or set to another value without affecting the
controlling terminal.

> IIRC, ctermid() always returns "/dev/tty" while $TTY points to the real device.

On FreeBSD:

    % perl -wMstrict -MPOSIX=ctermid -E 'say ctermid'
    /dev/pts/0

That's when there is a controlling tty.  Without one I do get
"/dev/tty".

You might be remembering GNU libc behaviour?

Anyway, I suppose I should revise my point to 'Can we determine at the C
level whether we have a controlling terminal more reliably than by
checking $TTY, and if so, should we expose that to scripts'.

Cheers,

Daniel

> Roman.
>