zsh-users
 help / color / mirror / code / Atom feed
* read with redirected stdin
@ 2023-01-07 13:31 Pier Paolo Grassi
  2023-01-07 13:44 ` Roman Perepelitsa
  0 siblings, 1 reply; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-07 13:31 UTC (permalink / raw)
  To: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Hello, I have a script that asks to create a target dir if it doesn't exist.
to that extend I inserted an
read -k1
in the script.
To be able to ask the user for confirm even when the script stdin is
connected to a pipe I did
read -k1 < /dev/tty
I now would like to be able to deactivate this behavior when the process
has no controlling terminal, eg when run from cron. To simulate this I
tried:

setsid zsh -c 'read -k1 < /dev/tty'

which gives:
zsh:1: no such device or address: /dev/tty

how can I prevent this error, so that I don't invoke read when there is no
controlling terminal for the current process?
thanks

Pier Paolo Grassi

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 13:31 read with redirected stdin Pier Paolo Grassi
@ 2023-01-07 13:44 ` Roman Perepelitsa
  2023-01-07 17:21   ` Pier Paolo Grassi
  0 siblings, 1 reply; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-07 13:44 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

On Sat, Jan 7, 2023 at 2:32 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> Hello, I have a script that asks to create a target dir if it doesn't exist.
> to that extend I inserted an
> read -k1
> in the script.
> To be able to ask the user for confirm even when the script stdin is connected to a pipe I did
> read -k1 < /dev/tty

Note that this redirect doesn't affect `read -k1`. It'll read from the
terminal either way.

You can do something like this in your script:

  if [[ -r $TTY ]]; then
    read -k1
  else
    read -k1 -u0
  fi

There is a corner case when you log in as root and then su to a
non-privileged user. $TTY won't be readable even though the process
has a TTY. Since you are redirecting stdin anyway, this corner case
shouldn't affect you.

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 13:44 ` Roman Perepelitsa
@ 2023-01-07 17:21   ` Pier Paolo Grassi
  2023-01-07 17:31     ` Roman Perepelitsa
                       ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-07 17:21 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Thanks, but i don't _always_ redirect stdin.
i wonder how is ps getting the tty (it displays an ? when there is no tty
for the process)
I suppose it uses /proc, but couldn't find a reference or the info
exploring the /proc fs by myself.
for now I am asking directly ps:
[[ "$(ps h -o tty $$)" != "?" ]] && ...

Pier Paolo Grassi


Il giorno sab 7 gen 2023 alle ore 14:44 Roman Perepelitsa <
roman.perepelitsa@gmail.com> ha scritto:

> On Sat, Jan 7, 2023 at 2:32 PM Pier Paolo Grassi <pierpaolog@gmail.com>
> wrote:
> >
> > Hello, I have a script that asks to create a target dir if it doesn't
> exist.
> > to that extend I inserted an
> > read -k1
> > in the script.
> > To be able to ask the user for confirm even when the script stdin is
> connected to a pipe I did
> > read -k1 < /dev/tty
>
> Note that this redirect doesn't affect `read -k1`. It'll read from the
> terminal either way.
>
> You can do something like this in your script:
>
>   if [[ -r $TTY ]]; then
>     read -k1
>   else
>     read -k1 -u0
>   fi
>
> There is a corner case when you log in as root and then su to a
> non-privileged user. $TTY won't be readable even though the process
> has a TTY. Since you are redirecting stdin anyway, this corner case
> shouldn't affect you.
>
> Roman.
>

[-- Attachment #2: Type: text/html, Size: 2040 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:21   ` Pier Paolo Grassi
@ 2023-01-07 17:31     ` Roman Perepelitsa
  2023-01-07 17:36       ` Pier Paolo Grassi
  2023-01-08 13:23       ` Daniel Shahaf
  2023-01-07 17:33     ` Pier Paolo Grassi
  2023-01-08  4:28     ` Jim
  2 siblings, 2 replies; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-07 17:31 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

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

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:21   ` Pier Paolo Grassi
  2023-01-07 17:31     ` Roman Perepelitsa
@ 2023-01-07 17:33     ` Pier Paolo Grassi
  2023-01-08  4:28     ` Jim
  2 siblings, 0 replies; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-07 17:33 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

I think I got something wrong in my code to reproduce the cron problem:

true | setsid zsh -c 'ps -o tty $$; read -k1 && echo 1'

ps does not shows a tty, but read works correctly...

Pier Paolo Grassi


Il giorno sab 7 gen 2023 alle ore 18:21 Pier Paolo Grassi <
pierpaolog@gmail.com> ha scritto:

> Thanks, but i don't _always_ redirect stdin.
> i wonder how is ps getting the tty (it displays an ? when there is no tty
> for the process)
> I suppose it uses /proc, but couldn't find a reference or the info
> exploring the /proc fs by myself.
> for now I am asking directly ps:
> [[ "$(ps h -o tty $$)" != "?" ]] && ...
>
> Pier Paolo Grassi
>
>
> Il giorno sab 7 gen 2023 alle ore 14:44 Roman Perepelitsa <
> roman.perepelitsa@gmail.com> ha scritto:
>
>> On Sat, Jan 7, 2023 at 2:32 PM Pier Paolo Grassi <pierpaolog@gmail.com>
>> wrote:
>> >
>> > Hello, I have a script that asks to create a target dir if it doesn't
>> exist.
>> > to that extend I inserted an
>> > read -k1
>> > in the script.
>> > To be able to ask the user for confirm even when the script stdin is
>> connected to a pipe I did
>> > read -k1 < /dev/tty
>>
>> Note that this redirect doesn't affect `read -k1`. It'll read from the
>> terminal either way.
>>
>> You can do something like this in your script:
>>
>>   if [[ -r $TTY ]]; then
>>     read -k1
>>   else
>>     read -k1 -u0
>>   fi
>>
>> There is a corner case when you log in as root and then su to a
>> non-privileged user. $TTY won't be readable even though the process
>> has a TTY. Since you are redirecting stdin anyway, this corner case
>> shouldn't affect you.
>>
>> Roman.
>>
>

[-- Attachment #2: Type: text/html, Size: 2860 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:31     ` Roman Perepelitsa
@ 2023-01-07 17:36       ` Pier Paolo Grassi
  2023-01-07 17:52         ` Roman Perepelitsa
  2023-01-08 13:23       ` Daniel Shahaf
  1 sibling, 1 reply; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-07 17:36 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

oh ok, that seems what I want (except I don't want to read from stdin when
there is no tty, just assume a negative answer, but that's trivial).
I am still wondering,  what can be a way to simulate the situation of a
script launched by cron, where there is no tty and no other mean for read
to connect to a terminal?
thanks!

Pier Paolo Grassi


Il giorno sab 7 gen 2023 alle ore 18:31 Roman Perepelitsa <
roman.perepelitsa@gmail.com> ha scritto:

> 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
>
> Roman.
>

[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:36       ` Pier Paolo Grassi
@ 2023-01-07 17:52         ` Roman Perepelitsa
  0 siblings, 0 replies; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-07 17:52 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

On Sat, Jan 7, 2023 at 6:37 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> I am still wondering,  what can be a way to simulate the situation of a script launched by cron, where there is no tty and no other mean for read to connect to a terminal?

This should do it:

    at now <<\END
    echo hello from $0 >/tmp/log
    END

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:21   ` Pier Paolo Grassi
  2023-01-07 17:31     ` Roman Perepelitsa
  2023-01-07 17:33     ` Pier Paolo Grassi
@ 2023-01-08  4:28     ` Jim
  2023-01-08  4:44       ` Pier Paolo Grassi
  2023-01-08 14:44       ` Ray Andrews
  2 siblings, 2 replies; 21+ messages in thread
From: Jim @ 2023-01-08  4:28 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: zsh


[-- Attachment #1.1: Type: text/plain, Size: 1007 bytes --]

On Sat, Jan 7, 2023 at 11:23 AM Pier Paolo Grassi <pierpaolog@gmail.com>
wrote:

> Thanks, but i don't _always_ redirect stdin.
> i wonder how is ps getting the tty (it displays an ? when there is no tty
> for the process)
> I suppose it uses /proc, but couldn't find a reference or the info
> exploring the /proc fs by myself.
> for now I am asking directly ps:
> [[ "$(ps h -o tty $$)" != "?" ]] && ...
>
> Pier Paolo Grassi
>
> Hi,

Don't really have an answer how ps gets its info but the attached script is
something
I have been working on. It uses the /proc file system directly to get info.
It uses zstat
to look for the tty info.  If nothing is returned it substitutes '?".  Some
processes point to
/dev/null. The script is still a work in progress. I was trying to get the
same results as
"ps -eHo uid=,pid=,ppid=,tty=,comm=" via a zsh script.

This doesn't answer your original question, but may give you some insight
into the
/proc file system.

Hope the script is helpful.

Regards,

Jim Murphy

[-- Attachment #1.2: Type: text/html, Size: 1789 bytes --]

[-- Attachment #2: ps_eHo_via_zsh_script --]
[-- Type: application/octet-stream, Size: 1277 bytes --]

emulate -L zsh
setopt extendedglob
# Function:  ps_eHo_via_zsh_script
# WIP, still need to figure out how to make a tree(forest)
  [[ -v modules[zsh/stat] ]] || zmodload zstat
local     E L M N V
local -a  A B X Y Z Ps
local -A  proc_comm proc_tty proc_ppid proc_uid
Ps=(Pid: PPid: Name: Uid:) ; P="${(j.|.)Ps}"
# "ps -eHo uid=,pid=,ppid=,tty=,comm=" -- "ps"  vs  "ps via zsh shell"
# issue:  making a tree(forest) formatted output like the ps command
A=(/proc/<->(/DN)) ; A=(${A##*/})
for E ($A) {
  [[ ! -d /proc/$E ]] && { N=${A[(i)$E]} ; [[ $N -le $#A ]] && A[N]=() } }
for E ($A) B+=(${(f)"$(</proc/$E/comm)"}) ; M=${A[${B[(i)firefox-esr]}]}
for E ($A) {
  B=(${(M)${(f)"$(</proc/$E/status)"}:#($~P)*})
  Z=(${(z)B[${B[(i)Uid:*]}]}) ; [[ $Z[2] -ne 0 && $Z[2] -ne $UID ]] && continue
  Z=(${(z)B[${B[(i)PPid:*]}]}) # skip if ppid is 2
    [[ $Z[2] -eq 2 || $Z[2] == $M ]] && continue || proc_ppid[$E]=${Z[2]}
  Z=(${=B[${B[(i)Name:*]}]}) ; proc_comm[$E]=${Z[2,-1]}
  Z=(${(z)B[${B[(i)Uid:*]}]})  ; proc_uid[$E]=${Z[2]}
  V=$(zstat +link /proc/$E/fd/0 2>/dev/null) \
    proc_tty[$E]=${${${V:=\?}#/dev/}%:*}
}
L=${#${(O@v)proc_tty//?/X}[1]}
for E (${(onk)proc_comm}) {
  printf "%5s %5s %5s %-${L}s %s\n" $E \
    $proc_ppid[$E] $proc_uid[$E] $proc_tty[$E] $proc_comm[$E]
}

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08  4:28     ` Jim
@ 2023-01-08  4:44       ` Pier Paolo Grassi
  2023-01-08 21:18         ` Jim
  2023-01-08 14:44       ` Ray Andrews
  1 sibling, 1 reply; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-08  4:44 UTC (permalink / raw)
  To: linuxtechguy; +Cc: zsh

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Thanks, I'll check it out.

Il giorno dom 8 gen 2023 alle 05:29 Jim <linux.tech.guy@gmail.com> ha
scritto:

>
> On Sat, Jan 7, 2023 at 11:23 AM Pier Paolo Grassi <pierpaolog@gmail.com>
> wrote:
>
>> Thanks, but i don't _always_ redirect stdin.
>> i wonder how is ps getting the tty (it displays an ? when there is no tty
>> for the process)
>> I suppose it uses /proc, but couldn't find a reference or the info
>> exploring the /proc fs by myself.
>> for now I am asking directly ps:
>> [[ "$(ps h -o tty $$)" != "?" ]] && ...
>>
>> Pier Paolo Grassi
>>
>> Hi,
>
> Don't really have an answer how ps gets its info but the attached script
> is something
> I have been working on. It uses the /proc file system directly to get
> info. It uses zstat
> to look for the tty info.  If nothing is returned it substitutes '?".
> Some processes point to
> /dev/null. The script is still a work in progress. I was trying to get the
> same results as
> "ps -eHo uid=,pid=,ppid=,tty=,comm=" via a zsh script.
>
> This doesn't answer your original question, but may give you some insight
> into the
> /proc file system.
>
> Hope the script is helpful.
>
> Regards,
>
> Jim Murphy
>
> --
Pier Paolo Grassi

[-- Attachment #2: Type: text/html, Size: 2388 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-07 17:31     ` Roman Perepelitsa
  2023-01-07 17:36       ` Pier Paolo Grassi
@ 2023-01-08 13:23       ` Daniel Shahaf
  2023-01-08 13:48         ` Roman Perepelitsa
  1 sibling, 1 reply; 21+ messages in thread
From: Daniel Shahaf @ 2023-01-08 13:23 UTC (permalink / raw)
  To: Zsh-Users List; +Cc: Pier Paolo Grassi

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?  I'm
aware of tty(1), but that returns the name of the terminal _on stdin_,
which isn't necessarily the same thing as the controlling terminal.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 13:23       ` Daniel Shahaf
@ 2023-01-08 13:48         ` Roman Perepelitsa
  2023-01-08 14:21           ` Daniel Shahaf
  0 siblings, 1 reply; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-08 13:48 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh-Users List, Pier Paolo Grassi

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? Doesn't $TTY already provide a better alternative?

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

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 13:48         ` Roman Perepelitsa
@ 2023-01-08 14:21           ` Daniel Shahaf
  2023-01-08 14:42             ` Roman Perepelitsa
  0 siblings, 1 reply; 21+ messages in thread
From: Daniel Shahaf @ 2023-01-08 14:21 UTC (permalink / raw)
  To: Zsh-Users List; +Cc: Pier Paolo Grassi

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.
> 


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 14:21           ` Daniel Shahaf
@ 2023-01-08 14:42             ` Roman Perepelitsa
  0 siblings, 0 replies; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-08 14:42 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh-Users List, Pier Paolo Grassi

On Sun, Jan 8, 2023 at 3:22 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Roman Perepelitsa wrote on Sun, Jan 08, 2023 at 14:48:24 +0100:
> >
> > Doesn't $TTY already provide a better alternative?
>
> $TTY could be unset or set to another value without affecting the
> controlling terminal.

Paranoid scripts can do this:

    zsh -fc 'print -r -- $TTY'

However, if one is overriding TTY, then they perhaps want to affect
scripts that read it (similarly to overriding HOME or HOST). In any
case, scripts can decide whether to pick up $TTY that might have been
altered or use the paranoid construct from above.

> 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'.

Zsh already knows how to set TTY, so the answer to the first question
must be "yes".

For the second question it would be nice to have a use case that
cannot already be solved by $TTY.

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08  4:28     ` Jim
  2023-01-08  4:44       ` Pier Paolo Grassi
@ 2023-01-08 14:44       ` Ray Andrews
  2023-01-08 15:06         ` Roman Perepelitsa
  1 sibling, 1 reply; 21+ messages in thread
From: Ray Andrews @ 2023-01-08 14:44 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]


On 2023-01-07 20:28, Jim wrote:
> It uses zstat
> to look for the tty info.

No mention of zstat in zshbuiltins doc.



[-- Attachment #2: Type: text/html, Size: 662 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 14:44       ` Ray Andrews
@ 2023-01-08 15:06         ` Roman Perepelitsa
  2023-01-08 20:23           ` Ray Andrews
  0 siblings, 1 reply; 21+ messages in thread
From: Roman Perepelitsa @ 2023-01-08 15:06 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 8, 2023 at 3:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> No mention of zstat in zshbuiltins doc.

It's in zshmodules. I usually search in zshall if I don't know where
something is defined.

Roman.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 15:06         ` Roman Perepelitsa
@ 2023-01-08 20:23           ` Ray Andrews
  0 siblings, 0 replies; 21+ messages in thread
From: Ray Andrews @ 2023-01-08 20:23 UTC (permalink / raw)
  To: zsh-users


On 2023-01-08 07:06, Roman Perepelitsa wrote:
> On Sun, Jan 8, 2023 at 3:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> No mention of zstat in zshbuiltins doc.
> It's in zshmodules. I usually search in zshall if I don't know where
> something is defined.
>
> Roman.
>
Thanks.  whence reports it as a builtin so I didn't bother looking further.




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08  4:44       ` Pier Paolo Grassi
@ 2023-01-08 21:18         ` Jim
  2023-01-09 16:01           ` Pier Paolo Grassi
  0 siblings, 1 reply; 21+ messages in thread
From: Jim @ 2023-01-08 21:18 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: zsh

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Sat, Jan 7, 2023 at 10:44 PM Pier Paolo Grassi <pierpaolog@gmail.com>
wrote:

> Thanks, I'll check it out.
>
> Pier Paolo Grassi
>

Not sure this is what you are looking for but in re-reading your original
email you mention
checking for pipes. The script I attached  in the earlier email was
checking fd 0, so I also
tried checking fd 1.  The results are as follows looking at my /proc.

zstat +link /proc/<pid>/fd/0 2>/dev/null
25189 12199 17227 pts/40  man
25198 25189 17227 pipe    man
25199 25189 17227 pipe    less
zstat +link /proc/<pid>/fd/1 2>/dev/null
25189 12199 17227 pts/40  man
25198 25189 17227 pipe    man
25199 25189 17227 pts/40  less

Not sure if it will return what you are looking for in your case. The
script is also
collecting other info to output the above results.

Regards,

Jim

[-- Attachment #2: Type: text/html, Size: 1356 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-08 21:18         ` Jim
@ 2023-01-09 16:01           ` Pier Paolo Grassi
  2023-01-09 22:47             ` Jim
  0 siblings, 1 reply; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-09 16:01 UTC (permalink / raw)
  To: linuxtechguy; +Cc: zsh

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

hello Jim, your script reads the tty associated with the file descriptors,
while I am looking for a way to get the tty controlling a certain process.
I don't know much about this argument but it seems to me these are not
necessarily the same.
cheers

Il giorno dom 8 gen 2023 alle 22:18 Jim <linux.tech.guy@gmail.com> ha
scritto:

>
> On Sat, Jan 7, 2023 at 10:44 PM Pier Paolo Grassi <pierpaolog@gmail.com>
> wrote:
>
>> Thanks, I'll check it out.
>>
>> Pier Paolo Grassi
>>
>
> Not sure this is what you are looking for but in re-reading your original
> email you mention
> checking for pipes. The script I attached  in the earlier email was
> checking fd 0, so I also
> tried checking fd 1.  The results are as follows looking at my /proc.
>
> zstat +link /proc/<pid>/fd/0 2>/dev/null
> 25189 12199 17227 pts/40  man
> 25198 25189 17227 pipe    man
> 25199 25189 17227 pipe    less
> zstat +link /proc/<pid>/fd/1 2>/dev/null
> 25189 12199 17227 pts/40  man
> 25198 25189 17227 pipe    man
> 25199 25189 17227 pts/40  less
>
> Not sure if it will return what you are looking for in your case. The
> script is also
> collecting other info to output the above results.
>
> Regards,
>
> Jim
>

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-09 16:01           ` Pier Paolo Grassi
@ 2023-01-09 22:47             ` Jim
  2023-01-10  2:46               ` Bart Schaefer
  0 siblings, 1 reply; 21+ messages in thread
From: Jim @ 2023-01-09 22:47 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: zsh

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Hi Pier,

On Mon, Jan 9, 2023 at 10:01 AM Pier Paolo Grassi <pierpaolog@gmail.com>
wrote:

> hello Jim, your script reads the tty associated with the file descriptors,
> while I am looking for a way to get the tty controlling a certain process.
> I don't know much about this argument but it seems to me these are not
> necessarily the same.
> cheers
>

Could you explain what you mean by " I am looking for a way to get the tty
controlling
a certain process". This seems backwards to me or am I misinterpreting what
you said?
I haven't seen anything that shows ttys pointing to a process. It may
exist, but I don't
know where you would find it if it does. I just know that processes attach
tty devices
via file descriptors on Linux and Unix systems. The read command, in
several shells,
supports this with the "-u N" option. Maybe I'm just looking at this from
the wrong
perspective(wouldn't  be the first time).

Regards,

Jim

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-09 22:47             ` Jim
@ 2023-01-10  2:46               ` Bart Schaefer
  2023-01-10  6:03                 ` Pier Paolo Grassi
  0 siblings, 1 reply; 21+ messages in thread
From: Bart Schaefer @ 2023-01-10  2:46 UTC (permalink / raw)
  To: linuxtechguy; +Cc: Pier Paolo Grassi, zsh

On Mon, Jan 9, 2023 at 2:47 PM Jim <linux.tech.guy@gmail.com> wrote:
>
> I haven't seen anything that shows ttys pointing to a process. It may exist, but I don't
> know where you would find it if it does. I just know that processes attach tty devices
> via file descriptors on Linux and Unix systems.

Although the foregoing is correct, once a process is attached to a tty
the corresponding descriptor can be closed or duplicated without
detaching the process from the tty again.  All descendants of that
process form a "process group" (unless one of them explicitly takes
over as a new "group leader") and all processes in a group are
eligible to receive signals such as INT and QUIT and TSTP generated by
the terminal (usually by keyboard interaction).

So Pier wants to know what tty is associated with the current
process's group, not what tty may be performing i/o with any of the
currently open descriptors.  The simplest way to do that is to use the
coreutils "tty" command:  tty < /dev/tty


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: read with redirected stdin
  2023-01-10  2:46               ` Bart Schaefer
@ 2023-01-10  6:03                 ` Pier Paolo Grassi
  0 siblings, 0 replies; 21+ messages in thread
From: Pier Paolo Grassi @ 2023-01-10  6:03 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: linuxtechguy, zsh

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

thanks Bart for this explanation and the solution, I wasn't so sure how to
explain what I was looking for because I was missing this mechanic.

Pier Paolo Grassi


Il giorno mar 10 gen 2023 alle ore 03:46 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Mon, Jan 9, 2023 at 2:47 PM Jim <linux.tech.guy@gmail.com> wrote:
> >
> > I haven't seen anything that shows ttys pointing to a process. It may
> exist, but I don't
> > know where you would find it if it does. I just know that processes
> attach tty devices
> > via file descriptors on Linux and Unix systems.
>
> Although the foregoing is correct, once a process is attached to a tty
> the corresponding descriptor can be closed or duplicated without
> detaching the process from the tty again.  All descendants of that
> process form a "process group" (unless one of them explicitly takes
> over as a new "group leader") and all processes in a group are
> eligible to receive signals such as INT and QUIT and TSTP generated by
> the terminal (usually by keyboard interaction).
>
> So Pier wants to know what tty is associated with the current
> process's group, not what tty may be performing i/o with any of the
> currently open descriptors.  The simplest way to do that is to use the
> coreutils "tty" command:  tty < /dev/tty
>

[-- Attachment #2: Type: text/html, Size: 1964 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2023-01-10  6:05 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-07 13:31 read with redirected stdin Pier Paolo Grassi
2023-01-07 13:44 ` Roman Perepelitsa
2023-01-07 17:21   ` Pier Paolo Grassi
2023-01-07 17:31     ` Roman Perepelitsa
2023-01-07 17:36       ` Pier Paolo Grassi
2023-01-07 17:52         ` Roman Perepelitsa
2023-01-08 13:23       ` Daniel Shahaf
2023-01-08 13:48         ` Roman Perepelitsa
2023-01-08 14:21           ` Daniel Shahaf
2023-01-08 14:42             ` Roman Perepelitsa
2023-01-07 17:33     ` Pier Paolo Grassi
2023-01-08  4:28     ` Jim
2023-01-08  4:44       ` Pier Paolo Grassi
2023-01-08 21:18         ` Jim
2023-01-09 16:01           ` Pier Paolo Grassi
2023-01-09 22:47             ` Jim
2023-01-10  2:46               ` Bart Schaefer
2023-01-10  6:03                 ` Pier Paolo Grassi
2023-01-08 14:44       ` Ray Andrews
2023-01-08 15:06         ` Roman Perepelitsa
2023-01-08 20:23           ` Ray Andrews

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).