zsh-users
 help / color / mirror / Atom feed
* less with subprocess
@ 2021-09-27 20:30 Pier Paolo Grassi
  2021-09-27 20:46 ` Roman Perepelitsa
                   ` (2 more replies)
  0 siblings, 3 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-27 20:30 UTC (permalink / raw)
  To: Zsh-Users List

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

Hello, I have something like this:

less -f <(sleep 100)

actually the sleep is a find which does not produce any output for a long
time at times, but the result is pretty much the same: less doesn't seem to
be able to initialize if it doesn't receive an input, so it can't respond
to sigint (ctrl-c), and I have to kill it from another shell
I use it like this so I am able to use ctrl-c and +F inside less to move
around in the output already received and receive the new input received in
the meantime (with +F), so I would rather not us something like:

sleep 100 | less

which doesn't have problems exiting, but when I hit ctrl-c for the first
time the pipe is closed and no more input is generated for less

thanks

Pier Paolo Grassi

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

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

* Re: less with subprocess
  2021-09-27 20:30 less with subprocess Pier Paolo Grassi
@ 2021-09-27 20:46 ` Roman Perepelitsa
  2021-09-27 21:38   ` Bart Schaefer
  2021-09-27 21:38 ` Dominik Vogt
  2021-09-29 12:24 ` Vincent Lefevre
  2 siblings, 1 reply; 41+ messages in thread
From: Roman Perepelitsa @ 2021-09-27 20:46 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

On Mon, Sep 27, 2021 at 10:31 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> I would rather not us something like:
>
> sleep 100 | less
>
> which doesn't have problems exiting, but when I hit ctrl-c for the first
> time the pipe is closed and no more input is generated for less

Looks like this:
https://unix.stackexchange.com/questions/26826/follow-a-pipe-using-less

Roman.


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

* Re: less with subprocess
  2021-09-27 20:46 ` Roman Perepelitsa
@ 2021-09-27 21:38   ` Bart Schaefer
  2021-09-27 21:48     ` Bart Schaefer
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-27 21:38 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Pier Paolo Grassi, Zsh-Users List

On Mon, Sep 27, 2021 at 1:47 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> Looks like this:
> https://unix.stackexchange.com/questions/26826/follow-a-pipe-using-less

Which in turn means that the (mostly) less-version-independent
workaround in zsh is

  less -f =(find ...)

unless the find output is so voluminous that you're concerned about
temp file space.


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

* Re: less with subprocess
  2021-09-27 20:30 less with subprocess Pier Paolo Grassi
  2021-09-27 20:46 ` Roman Perepelitsa
@ 2021-09-27 21:38 ` Dominik Vogt
  2021-09-27 22:35   ` Dominik Vogt
  2021-09-29 12:24 ` Vincent Lefevre
  2 siblings, 1 reply; 41+ messages in thread
From: Dominik Vogt @ 2021-09-27 21:38 UTC (permalink / raw)
  To: zsh-users

On Mon, Sep 27, 2021 at 10:30:08PM +0200, Pier Paolo Grassi wrote:
> Hello, I have something like this:
>
> less -f <(sleep 100)
>
> actually the sleep is a find which does not produce any output for a long
> time at times, but the result is pretty much the same: less doesn't seem to
> be able to initialize if it doesn't receive an input, so it can't respond
> to sigint (ctrl-c), and I have to kill it from another shell
> I use it like this so I am able to use ctrl-c and +F inside less to move
> around in the output already received and receive the new input received in
> the meantime (with +F), so I would rather not us something like:

I'm not sure I understand what your usability problem actually is,
but to kill a less without input you can hit "ctrl-z" to put it in
the background an kill it with "kill %".  This will also kill the
background pipe process if it's listening to signals. (I.e. a
sleep will survive, but normal command won't.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-27 21:38   ` Bart Schaefer
@ 2021-09-27 21:48     ` Bart Schaefer
  2021-09-27 22:57       ` Pier Paolo Grassi
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-27 21:48 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Pier Paolo Grassi, Zsh-Users List

On Mon, Sep 27, 2021 at 2:38 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
>   less -f =(find ...)

Hm, never mind, interrupt kills that subprocess as well so it only
solves half the probem.


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

* Re: less with subprocess
  2021-09-27 21:38 ` Dominik Vogt
@ 2021-09-27 22:35   ` Dominik Vogt
  2021-09-27 23:03     ` Bart Schaefer
  0 siblings, 1 reply; 41+ messages in thread
From: Dominik Vogt @ 2021-09-27 22:35 UTC (permalink / raw)
  To: zsh-users

Hm, why does this work in bash but not in zsh?

  ( trap "" INT; sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1; done ) | less

With bash, the ctrl-c is always only handles by less.  (But less
(version 487) won't react to it before it has received a full
terminal page of input.)

In zsh, pressing ctrl-c at any time kills the subshell.

It works fine with "normal" commands though:

  ( trap "" INT; ls -lR / 2> /dev/null ) | less

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-27 21:48     ` Bart Schaefer
@ 2021-09-27 22:57       ` Pier Paolo Grassi
  2021-09-27 23:05         ` Bart Schaefer
  2021-09-27 23:31         ` Dominik Vogt
  0 siblings, 2 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-27 22:57 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Roman Perepelitsa, Zsh-Users List

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

I am trying some variations based on suggestions from the page Roman linked:

(trap 'kill -PIPE 0' INT; less -f -+F <(eval "sleep 100" ))
/proc/self/fd/11 lines 1--1...skipping...
/proc/self/fd/11 lines 1--1...skipping...
/proc/self/fd/11 lines 1--1...skipping...
/proc/self/fd/11 lines 1--1...skipping...
/proc/self/fd/11 lines 1--1...skipping...
/proc/self/fd/11 lines 1--1...skipping...

the "skipping lines" is what is printed, I assume by less, when I press
ctrl-c
I can confirm that using ctrl-z and kill % is able to successfully get rid
of the process, but it seems kind of an emergency measure to me, not what I
would like to be my routine.
It seems to me that less is eating the ctrl-c, so the trap is never called,
because executing the kill -PIPE from another shell works, of course
replacing the 0 with the pid of one of the processes involved, sleep or
less doesn't matter.
So I'm starting to think this is something that can't be solved from the
shell because the shell is unable to do anything until less gives up the
control, am I right?

Pier Paolo Grassi


Il giorno lun 27 set 2021 alle ore 23:48 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Mon, Sep 27, 2021 at 2:38 PM Bart Schaefer <schaefer@brasslantern.com>
> wrote:
> >
> >   less -f =(find ...)
>
> Hm, never mind, interrupt kills that subprocess as well so it only
> solves half the probem.
>

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

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

* Re: less with subprocess
  2021-09-27 22:35   ` Dominik Vogt
@ 2021-09-27 23:03     ` Bart Schaefer
  0 siblings, 0 replies; 41+ messages in thread
From: Bart Schaefer @ 2021-09-27 23:03 UTC (permalink / raw)
  To: dominik.vogt, Zsh Users

On Mon, Sep 27, 2021 at 3:38 PM Dominik Vogt <dominik.vogt@gmx.de> wrote:
>
> Hm, why does this work in bash but not in zsh?
>
>   ( trap "" INT; sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1; done ) | less

This works for me on ubuntu using a build from the current git head.


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

* Re: less with subprocess
  2021-09-27 22:57       ` Pier Paolo Grassi
@ 2021-09-27 23:05         ` Bart Schaefer
  2021-09-27 23:28           ` Pier Paolo Grassi
  2021-09-27 23:31         ` Dominik Vogt
  1 sibling, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-27 23:05 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Roman Perepelitsa, Zsh-Users List

On Mon, Sep 27, 2021 at 3:57 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> So I'm starting to think this is something that can't be solved from the shell because the shell is unable to do anything until less gives up the control, am I right?

"less" is the foreground process controlling the terminal, so if it
traps the signal, that's pretty much the end of it, yes.


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

* Re: less with subprocess
  2021-09-27 23:05         ` Bart Schaefer
@ 2021-09-27 23:28           ` Pier Paolo Grassi
  0 siblings, 0 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-27 23:28 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Roman Perepelitsa, Zsh-Users List

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

in this case maybe the ctrl-z kill % isn't so bad a solution for the
occasions in which I want to interrupt the process before any output has
been provided
thanks

Il giorno mar 28 set 2021 alle 01:05 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Mon, Sep 27, 2021 at 3:57 PM Pier Paolo Grassi <pierpaolog@gmail.com>
> wrote:
> >
> > So I'm starting to think this is something that can't be solved from the
> shell because the shell is unable to do anything until less gives up the
> control, am I right?
>
> "less" is the foreground process controlling the terminal, so if it
> traps the signal, that's pretty much the end of it, yes.
>
-- 
Pier Paolo Grassi

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

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

* Re: less with subprocess
  2021-09-27 22:57       ` Pier Paolo Grassi
  2021-09-27 23:05         ` Bart Schaefer
@ 2021-09-27 23:31         ` Dominik Vogt
  2021-09-28  0:41           ` Bart Schaefer
  2021-09-28 19:50           ` Pier Paolo Grassi
  1 sibling, 2 replies; 41+ messages in thread
From: Dominik Vogt @ 2021-09-27 23:31 UTC (permalink / raw)
  To: zsh-users

On Tue, Sep 28, 2021 at 12:57:02AM +0200, Pier Paolo Grassi wrote:
> I am trying some variations based on suggestions from the page Roman linked:
>
> (trap 'kill -PIPE 0' INT; less -f -+F <(eval "sleep 100" ))
> /proc/self/fd/11 lines 1--1...skipping...
> /proc/self/fd/11 lines 1--1...skipping...
> /proc/self/fd/11 lines 1--1...skipping...
> /proc/self/fd/11 lines 1--1...skipping...
> /proc/self/fd/11 lines 1--1...skipping...
> /proc/self/fd/11 lines 1--1...skipping...
>
> the "skipping lines" is what is printed, I assume by less, when I press
> ctrl-c
> I can confirm that using ctrl-z and kill % is able to successfully get rid
> of the process, but it seems kind of an emergency measure to me, not what I
> would like to be my routine.
> It seems to me that less is eating the ctrl-c, so the trap is never called,

It's still not clear to me what you're trying to accomplish.  You
mentioned two issues:

1) less does not react to SIGINT before it receives any input.
   Actually, less (v487) does not react to SIGINT before it
   receives a full screen of input.  A workaround is to print some
   dummy input before the real command.  Something like

     less -f <( repeat $LINES; echo ""; ls -lR / )

2) You want "ctrl-c" to stop less from reading input and go into
   "view" mode, then press "F" to go back to "listening" mode?  If
   so, what are these experiments with "SIGPIPE" trying to do?

   If you want less to work on the command output like it would
   work on a growing file, why don't you just *write* that output
   to a file and run less on that?

     alias -g LF="> $HOME/tmp/less-input.$$ & less $HOME/tmp/less-input.$$; kill %; rm $HOME/tmp/less-input.$$"

   Run it with

     ls -lR / 2> /dev/null LF
                          ^^^^

   The global alias saves you the effort of typing all that stuff
   with the tempfile and less after the command.

   (You really want to use a private path for the tempfiles
   because the alias would be vulnerable to symlink attacks when used
   in a publicly writeable directory.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-27 23:31         ` Dominik Vogt
@ 2021-09-28  0:41           ` Bart Schaefer
  2021-09-28  0:53             ` Bart Schaefer
  2021-09-28 19:50           ` Pier Paolo Grassi
  1 sibling, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-28  0:41 UTC (permalink / raw)
  To: dominik.vogt, Zsh Users

On Mon, Sep 27, 2021 at 4:33 PM Dominik Vogt <dominik.vogt@gmx.de> wrote:
>
>      alias -g LF="> $HOME/tmp/less-input.$$ & less $HOME/tmp/less-input.$$; kill %; rm $HOME/tmp/less-input.$$"

Nice, but how about:

alias -g LF='| () { cat >$1 &! less $1 ; kill $! } =(:)'

The use of &! silently backgrounds and disassociates cat so that it
can't be terminal-interrupted, and the anonymous function re-uses the
automatically created (and automatically removed) file name from =(:).
When less exits, "kill $!" terminates cat.

>    (You really want to use a private path for the tempfiles
>    because the alias would be vulnerable to symlink attacks when used
>    in a publicly writeable directory.)

Not unreasonable advice, but using the =(...) substitution removes
much of the danger (and most people aren't on shared servers any
more).  If paranoid, TMPPREFIX can be set to a private path to assure
you're always using it with process substitutions.


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

* Re: less with subprocess
  2021-09-28  0:41           ` Bart Schaefer
@ 2021-09-28  0:53             ` Bart Schaefer
  2021-09-28 18:52               ` Dominik Vogt
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-28  0:53 UTC (permalink / raw)
  To: dominik.vogt, Zsh Users

On Mon, Sep 27, 2021 at 5:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> alias -g LF='| () { cat >$1 &! less $1 ; kill $! } =(:)'

On additional thought ... it's not really saving very much to make
this a global alias.  An actual function

LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }

is only two more characters to pipe into, and can also be redirected into.


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

* Re: less with subprocess
  2021-09-28  0:53             ` Bart Schaefer
@ 2021-09-28 18:52               ` Dominik Vogt
  2021-09-28 19:29                 ` Bart Schaefer
  2021-09-29 12:51                 ` Vincent Lefevre
  0 siblings, 2 replies; 41+ messages in thread
From: Dominik Vogt @ 2021-09-28 18:52 UTC (permalink / raw)
  To: Zsh Users

On Mon, Sep 27, 2021 at 05:53:33PM -0700, Bart Schaefer wrote:
> On Mon, Sep 27, 2021 at 5:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > alias -g LF='| () { cat >$1 &! less $1 ; kill $! } =(:)'
>
> On additional thought ... it's not really saving very much to make
> this a global alias.  An actual function
>
> LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
>
> is only two more characters to pipe into, and can also be redirected into.

Both do not work for me (zsh-5.7.1, less 487).  The generating
command is killed when ctrl-c is pressed for the first time:

  # using the alias
  { sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1; done } LF

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-28 18:52               ` Dominik Vogt
@ 2021-09-28 19:29                 ` Bart Schaefer
  2021-09-29 13:02                   ` Vincent Lefevre
  2021-09-29 12:51                 ` Vincent Lefevre
  1 sibling, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-28 19:29 UTC (permalink / raw)
  To: dominik.vogt, Zsh Users

> Both do not work for me (zsh-5.7.1, less 487).  The generating
> command is killed when ctrl-c is pressed for the first time

There have been a few changes to subprocess signal handling since
5.7.1.  Most likely involved here is workers/49029.


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

* Re: less with subprocess
  2021-09-27 23:31         ` Dominik Vogt
  2021-09-28  0:41           ` Bart Schaefer
@ 2021-09-28 19:50           ` Pier Paolo Grassi
  1 sibling, 0 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-28 19:50 UTC (permalink / raw)
  To: dominik.vogt, Zsh-Users List

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

Hello:

>2) You want "ctrl-c" to stop less from reading input and go into
>  "view" mode, then press "F" to go back to "listening" mode?  If
> so, what are these experiments with "SIGPIPE" trying to do?

this I have no problem obtaining with:

less -f <(long lived find command)

>1) less does not react to SIGINT before it receives any input.
>  Actually, less (v487) does not react to SIGINT before it
>  receives a full screen of input.

Yes I was looking for help about this issue. I understand now from
yesterday's experiments and the help from the ml that less is the reason I
can't kill the pipe when I press ctrl-c, since it eats the sigint before it
has a full screen of input, as you pointed out. I would have liked to be
able to trap the sigint and send a sigpipe to the session, thus killing
both less and the long lived no-ouput-still find command. But it seems to
me this is unachievable, since less must be the foreground process, and
thus, if it eats the sigint, nothing can be done about it.
One experiment seemed for a moment a good solution, using unbuffer from
expect package on less, but the less loses the ability to process
interactive input.
So it seems that ctrl-z, kill % is the only solution that can be applied
when less "hangs" waiting for more input and ignores ctrl-c, without
resorting to using kill from other terminals.
The solution mentioned with =() I do use sometimes, but this was more of a
"what about doing everything in memory" challenge; about the solutions with
a pipe instead of process substitution I already investigated and I wasn't
able to make it work, in particular I wasn't able to make the solutions
with the trap on the first command to work, such as:

( trap "" INT; sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1;
done ) | less

and the likes, I still get the
lines 1--1...skipping...

output and the need to use ctrl-z

Pier Paolo Grassi


Il giorno mar 28 set 2021 alle ore 01:34 Dominik Vogt <dominik.vogt@gmx.de>
ha scritto:

> On Tue, Sep 28, 2021 at 12:57:02AM +0200, Pier Paolo Grassi wrote:
> > I am trying some variations based on suggestions from the page Roman
> linked:
> >
> > (trap 'kill -PIPE 0' INT; less -f -+F <(eval "sleep 100" ))
> > /proc/self/fd/11 lines 1--1...skipping...
> > /proc/self/fd/11 lines 1--1...skipping...
> > /proc/self/fd/11 lines 1--1...skipping...
> > /proc/self/fd/11 lines 1--1...skipping...
> > /proc/self/fd/11 lines 1--1...skipping...
> > /proc/self/fd/11 lines 1--1...skipping...
> >
> > the "skipping lines" is what is printed, I assume by less, when I press
> > ctrl-c
> > I can confirm that using ctrl-z and kill % is able to successfully get
> rid
> > of the process, but it seems kind of an emergency measure to me, not
> what I
> > would like to be my routine.
> > It seems to me that less is eating the ctrl-c, so the trap is never
> called,
>
> It's still not clear to me what you're trying to accomplish.  You
> mentioned two issues:
>
> 1) less does not react to SIGINT before it receives any input.
>    Actually, less (v487) does not react to SIGINT before it
>    receives a full screen of input.  A workaround is to print some
>    dummy input before the real command.  Something like
>
>      less -f <( repeat $LINES; echo ""; ls -lR / )
>
> 2) You want "ctrl-c" to stop less from reading input and go into
>    "view" mode, then press "F" to go back to "listening" mode?  If
>    so, what are these experiments with "SIGPIPE" trying to do?
>
>    If you want less to work on the command output like it would
>    work on a growing file, why don't you just *write* that output
>    to a file and run less on that?
>
>      alias -g LF="> $HOME/tmp/less-input.$$ & less
> $HOME/tmp/less-input.$$; kill %; rm $HOME/tmp/less-input.$$"
>
>    Run it with
>
>      ls -lR / 2> /dev/null LF
>                           ^^^^
>
>    The global alias saves you the effort of typing all that stuff
>    with the tempfile and less after the command.
>
>    (You really want to use a private path for the tempfiles
>    because the alias would be vulnerable to symlink attacks when used
>    in a publicly writeable directory.)
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>
>

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

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

* Re: less with subprocess
  2021-09-27 20:30 less with subprocess Pier Paolo Grassi
  2021-09-27 20:46 ` Roman Perepelitsa
  2021-09-27 21:38 ` Dominik Vogt
@ 2021-09-29 12:24 ` Vincent Lefevre
  2 siblings, 0 replies; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-29 12:24 UTC (permalink / raw)
  To: zsh-users

On 2021-09-27 22:30:08 +0200, Pier Paolo Grassi wrote:
> Hello, I have something like this:
> 
> less -f <(sleep 100)
> 
> actually the sleep is a find which does not produce any output for a long
> time at times, but the result is pretty much the same: less doesn't seem to
> be able to initialize if it doesn't receive an input, so it can't respond
> to sigint (ctrl-c), and I have to kill it from another shell

This seems similar to this more general bug I reported in 2019:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931216

There is an issue with its signal handling. I had written a patch,
but it doesn't work well in some cases.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-28 18:52               ` Dominik Vogt
  2021-09-28 19:29                 ` Bart Schaefer
@ 2021-09-29 12:51                 ` Vincent Lefevre
  1 sibling, 0 replies; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-29 12:51 UTC (permalink / raw)
  To: Zsh Users

On 2021-09-28 19:52:30 +0100, Dominik Vogt wrote:
> On Mon, Sep 27, 2021 at 05:53:33PM -0700, Bart Schaefer wrote:
> > On Mon, Sep 27, 2021 at 5:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > > alias -g LF='| () { cat >$1 &! less $1 ; kill $! } =(:)'
> >
> > On additional thought ... it's not really saving very much to make
> > this a global alias.  An actual function
> >
> > LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> >
> > is only two more characters to pipe into, and can also be redirected into.
> 
> Both do not work for me (zsh-5.7.1, less 487).  The generating
> command is killed when ctrl-c is pressed for the first time:
> 
>   # using the alias
>   { sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1; done } LF

In case this can be useful, I've been using the following function
since 2019. Here, svn2log is a command that can take much time to
generate the output, so that I wanted to be about to do a Ctrl-C to
interrupt some "less" operation (e.g. after [End]) without killing
the command.

sll()
{
  # The issue with "svn2log ... | less" is that after quitting the pager,
  # svn2log may still take time after getting a broken pipe. One wants to
  # kill it immediately by using a subshell and "kill -PIPE 0" to kill the
  # process group; the PIPE signal is used instead of another one in order
  # to avoid failure/killed messages from svn and/or zsh.
  # The "trap '' INT" prevents Ctrl-C (useful in "less") from killing the
  # subshell and the other processes of the process group, and "less" is
  # run in a subshell so that the INT trap is reset. Note: avoiding the
  # subshell with just "trap - INT; less" does not work as zsh implements
  # WUE (but should work in shells that implement WCE).
  ( trap '' INT; svn2log --color ',bright_green,cyan,yellow' "$@" | \
      { (less); kill -PIPE 0 } )
  # And let's avoid SIGPIPE as the exit status code.
  local r=$?
  return $(( r == 128 + $(kill -l PIPE) ? 0 : r ))
}

Before that, I was using "less -f <(the_command ...)" as also
mentioned in this thread, but it had some issues.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-28 19:29                 ` Bart Schaefer
@ 2021-09-29 13:02                   ` Vincent Lefevre
  2021-09-29 13:13                     ` Pier Paolo Grassi
  2021-09-29 14:14                     ` Bart Schaefer
  0 siblings, 2 replies; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-29 13:02 UTC (permalink / raw)
  To: zsh-users

On 2021-09-28 12:29:31 -0700, Bart Schaefer wrote:
> > Both do not work for me (zsh-5.7.1, less 487).  The generating
> > command is killed when ctrl-c is pressed for the first time
> 
> There have been a few changes to subprocess signal handling since
> 5.7.1.  Most likely involved here is workers/49029.

Even with zsh 5.8, this doesn't work.

I get the following error:

cventin% LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
cventin% echo | LF
(anon):kill: kill 27684 failed: no such process

And

cventin% (sleep 1; echo foo) | LF

gives an empty file in "less", also with an error if I quit "less"
after 1 second.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-29 13:02                   ` Vincent Lefevre
@ 2021-09-29 13:13                     ` Pier Paolo Grassi
  2021-09-29 13:26                       ` Vincent Lefevre
  2021-09-29 14:14                     ` Bart Schaefer
  1 sibling, 1 reply; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-29 13:13 UTC (permalink / raw)
  To: Zsh-Users List

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

in this command:

LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }

what is the purpose of =(:)? It is a process substitution which executes
the noop command, but why?

Pier Paolo Grassi


Il giorno mer 29 set 2021 alle ore 15:03 Vincent Lefevre <vincent@vinc17.net>
ha scritto:

> On 2021-09-28 12:29:31 -0700, Bart Schaefer wrote:
> > > Both do not work for me (zsh-5.7.1, less 487).  The generating
> > > command is killed when ctrl-c is pressed for the first time
> >
> > There have been a few changes to subprocess signal handling since
> > 5.7.1.  Most likely involved here is workers/49029.
>
> Even with zsh 5.8, this doesn't work.
>
> I get the following error:
>
> cventin% LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> cventin% echo | LF
> (anon):kill: kill 27684 failed: no such process
>
> And
>
> cventin% (sleep 1; echo foo) | LF
>
> gives an empty file in "less", also with an error if I quit "less"
> after 1 second.
>
> --
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
>

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

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

* Re: less with subprocess
  2021-09-29 13:13                     ` Pier Paolo Grassi
@ 2021-09-29 13:26                       ` Vincent Lefevre
  0 siblings, 0 replies; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-29 13:26 UTC (permalink / raw)
  To: zsh-users

On 2021-09-29 15:13:14 +0200, Pier Paolo Grassi wrote:
> in this command:
> 
> LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> 
> what is the purpose of =(:)?

To create a temporary file (which will be removed as soon as the
function returns), AFAIK. It is referenced as $1 in the body of
the function.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-29 13:02                   ` Vincent Lefevre
  2021-09-29 13:13                     ` Pier Paolo Grassi
@ 2021-09-29 14:14                     ` Bart Schaefer
  2021-09-29 14:47                       ` Pier Paolo Grassi
  2021-09-30 19:17                       ` Vincent Lefevre
  1 sibling, 2 replies; 41+ messages in thread
From: Bart Schaefer @ 2021-09-29 14:14 UTC (permalink / raw)
  To: Zsh Users

On Wed, Sep 29, 2021 at 6:02 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> cventin% LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> cventin% echo | LF
> (anon):kill: kill 27684 failed: no such process

Yeah, if you use it with a process that produces very little output,
the kill will fail.  But there's no point in using it in that case.
Redirect stderr of kill if this bothers you.

> And
>
> cventin% (sleep 1; echo foo) | LF
>
> gives an empty file in "less"

Yes, you have to hit "F" in less to reload / wait for the file
contents.  I suppose "less +F" might be preferable.  There are still
some signal handling issues with having a subshell on the left side of
the pipe, which might very well indicate that there is still a zsh (or
"less"?) bug with signal propagation.


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

* Re: less with subprocess
  2021-09-29 14:14                     ` Bart Schaefer
@ 2021-09-29 14:47                       ` Pier Paolo Grassi
  2021-09-29 17:56                         ` Bart Schaefer
  2021-09-30 19:17                       ` Vincent Lefevre
  1 sibling, 1 reply; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-29 14:47 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

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

I tried:

LF () { () { cat >|$1 &! less $1 ; kill $! } =(:) }

find | LF

unfortunately when hitting F then ctrl-c in less the find process is
immediately killed


Pier Paolo Grassi


Il giorno mer 29 set 2021 alle ore 16:15 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Wed, Sep 29, 2021 at 6:02 AM Vincent Lefevre <vincent@vinc17.net>
> wrote:
> >
> > cventin% LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> > cventin% echo | LF
> > (anon):kill: kill 27684 failed: no such process
>
> Yeah, if you use it with a process that produces very little output,
> the kill will fail.  But there's no point in using it in that case.
> Redirect stderr of kill if this bothers you.
>
> > And
> >
> > cventin% (sleep 1; echo foo) | LF
> >
> > gives an empty file in "less"
>
> Yes, you have to hit "F" in less to reload / wait for the file
> contents.  I suppose "less +F" might be preferable.  There are still
> some signal handling issues with having a subshell on the left side of
> the pipe, which might very well indicate that there is still a zsh (or
> "less"?) bug with signal propagation.
>
>

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

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

* Re: less with subprocess
  2021-09-29 14:47                       ` Pier Paolo Grassi
@ 2021-09-29 17:56                         ` Bart Schaefer
  2021-09-30 19:22                           ` Vincent Lefevre
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-29 17:56 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh Users

On Wed, Sep 29, 2021 at 7:47 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> LF () { () { cat >|$1 &! less $1 ; kill $! } =(:) }
>
> find | LF
>
> unfortunately when hitting F then ctrl-c in less the find process is immediately killed

You can get around that with

LF <<(find)

There could be some more failsafe stuff in "LF".  For example if you
accidentally invoke it with stdin still connected to the terminal
instead of to a pipe, "cat" will be stopped with SIGTTIN and left
lurking.


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

* Re: less with subprocess
  2021-09-29 14:14                     ` Bart Schaefer
  2021-09-29 14:47                       ` Pier Paolo Grassi
@ 2021-09-30 19:17                       ` Vincent Lefevre
  2021-09-30 19:48                         ` Dominik Vogt
  1 sibling, 1 reply; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-30 19:17 UTC (permalink / raw)
  To: zsh-users

On 2021-09-29 07:14:23 -0700, Bart Schaefer wrote:
> On Wed, Sep 29, 2021 at 6:02 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > cventin% LF () { () { cat >$1 &! less $1 ; kill $! } =(:) }
> > cventin% echo | LF
> > (anon):kill: kill 27684 failed: no such process
> 
> Yeah, if you use it with a process that produces very little output,
> the kill will fail.  But there's no point in using it in that case.

You don't always know in advance whether there will be little output.
And even with a lot of output, "kill" fails. Basically, the "cat" will
terminate as soon as the command terminates (there is no blocking due
to buffering like with a pipe).

There's another major issue: since there is no blocking, this can take
much disk space. Thus such a function must not be used in a case one
may be interested only in the beginning of the output.

> Redirect stderr of kill if this bothers you.

This won't solve the issue that "kill" may kill an arbitrary process.

I'd say that my patch on "less" provides a better solution.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-29 17:56                         ` Bart Schaefer
@ 2021-09-30 19:22                           ` Vincent Lefevre
  2021-10-01 16:44                             ` Bart Schaefer
  0 siblings, 1 reply; 41+ messages in thread
From: Vincent Lefevre @ 2021-09-30 19:22 UTC (permalink / raw)
  To: zsh-users

On 2021-09-29 10:56:30 -0700, Bart Schaefer wrote:
> On Wed, Sep 29, 2021 at 7:47 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
> >
> > LF () { () { cat >|$1 &! less $1 ; kill $! } =(:) }
> >
> > find | LF
> >
> > unfortunately when hitting F then ctrl-c in less the find process is immediately killed
> 
> You can get around that with
> 
> LF <<(find)

This is much worse! Ctrl-C then [End] yields

  zsh: suspended (tty input)

then "fg" makes the terminal unusable.

> There could be some more failsafe stuff in "LF".  For example if you
> accidentally invoke it with stdin still connected to the terminal
> instead of to a pipe, "cat" will be stopped with SIGTTIN and left
> lurking.

The above issue?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-30 19:17                       ` Vincent Lefevre
@ 2021-09-30 19:48                         ` Dominik Vogt
  2021-09-30 20:59                           ` Pier Paolo Grassi
  0 siblings, 1 reply; 41+ messages in thread
From: Dominik Vogt @ 2021-09-30 19:48 UTC (permalink / raw)
  To: zsh-users

On Thu, Sep 30, 2021 at 09:17:06PM +0200, Vincent Lefevre wrote:
> There's another major issue: since there is no blocking, this can take
> much disk space. Thus such a function must not be used in a case one
> may be interested only in the beginning of the output.

But ... even if you never press "F" in less to read the rest of
the input it's going to be stored somewhere, either in memory or
on disk.  What's the point in worrying bout temporry disk space?

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-30 19:48                         ` Dominik Vogt
@ 2021-09-30 20:59                           ` Pier Paolo Grassi
  2021-09-30 21:03                             ` Pier Paolo Grassi
  2021-09-30 23:46                             ` Dominik Vogt
  0 siblings, 2 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-30 20:59 UTC (permalink / raw)
  To: dominik.vogt, Zsh-Users List

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

writing on disk it can eat away all the space I have on my device and make
other processes that need that disk space to fail. Even if disk is cheap
doesn't mean it's always plentifully available

Pier Paolo Grassi


Il giorno gio 30 set 2021 alle ore 21:50 Dominik Vogt <dominik.vogt@gmx.de>
ha scritto:

> On Thu, Sep 30, 2021 at 09:17:06PM +0200, Vincent Lefevre wrote:
> > There's another major issue: since there is no blocking, this can take
> > much disk space. Thus such a function must not be used in a case one
> > may be interested only in the beginning of the output.
>
> But ... even if you never press "F" in less to read the rest of
> the input it's going to be stored somewhere, either in memory or
> on disk.  What's the point in worrying bout temporry disk space?
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>
>

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

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

* Re: less with subprocess
  2021-09-30 20:59                           ` Pier Paolo Grassi
@ 2021-09-30 21:03                             ` Pier Paolo Grassi
  2021-09-30 22:39                               ` Bart Schaefer
  2021-09-30 23:46                             ` Dominik Vogt
  1 sibling, 1 reply; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-30 21:03 UTC (permalink / raw)
  To: dominik.vogt, Zsh-Users List

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

Besides, google have sent me this error message two times:

The recipient server did not accept our requests to connect. Learn
more at https://support.google.com/mail/answer/7720
[prometheus.u-strasbg.fr
<https://support.google.com/mail/answer/7720%5Bprometheus.u-strasbg.fr>
130.79.203.100: FAILED_PRECONDITION: connect error (111): Connection
refused]

(of course the linked support page is inexistent...)

for a mail I tried to send to this thread, here it is again:

Date: Tue, 28 Sep 2021 22:10:04 +0200
Subject: Re: quoting words
Hello, here is the output:

5.8
a isa array
typeset -a omz=( 'the first' 'the last' )
'the first' 'the last'

the result from your script is in fact correct if I assign the
"${(@qq)omz}":

typeset -a omz=( 'the first' 'the last' )
a="${(@qq)omz}"
typeset -p a
typeset a='''the first'' ''the last'''

regards

Pier Paolo Grassi

Pier Paolo Grassi


Il giorno gio 30 set 2021 alle ore 22:59 Pier Paolo Grassi <
pierpaolog@gmail.com> ha scritto:

> writing on disk it can eat away all the space I have on my device and make
> other processes that need that disk space to fail. Even if disk is cheap
> doesn't mean it's always plentifully available
>
> Pier Paolo Grassi
>
>
> Il giorno gio 30 set 2021 alle ore 21:50 Dominik Vogt <dominik.vogt@gmx.de>
> ha scritto:
>
>> On Thu, Sep 30, 2021 at 09:17:06PM +0200, Vincent Lefevre wrote:
>> > There's another major issue: since there is no blocking, this can take
>> > much disk space. Thus such a function must not be used in a case one
>> > may be interested only in the beginning of the output.
>>
>> But ... even if you never press "F" in less to read the rest of
>> the input it's going to be stored somewhere, either in memory or
>> on disk.  What's the point in worrying bout temporry disk space?
>>
>> Ciao
>>
>> Dominik ^_^  ^_^
>>
>> --
>>
>> Dominik Vogt
>>
>>

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

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

* Re: less with subprocess
  2021-09-30 21:03                             ` Pier Paolo Grassi
@ 2021-09-30 22:39                               ` Bart Schaefer
  2021-09-30 22:46                                 ` Pier Paolo Grassi
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-09-30 22:39 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: dominik.vogt, Zsh-Users List

On Thu, Sep 30, 2021 at 2:04 PM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> Besides, google have sent me this error message two times:
>
> The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720 [prometheus.u-strasbg.fr 130.79.203.100: FAILED_PRECONDITION: connect error (111): Connection refused]

I think we've crossed threads here, but FWIW I just got a popup in
gmail about "having trouble authenticating" and had to re-log-in all
my google accounts.


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

* Re: less with subprocess
  2021-09-30 22:39                               ` Bart Schaefer
@ 2021-09-30 22:46                                 ` Pier Paolo Grassi
  0 siblings, 0 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-09-30 22:46 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dominik.vogt, Zsh-Users List

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

Yes you're right, sorry about that
(and don't let me started on google and accounts and all sort of gratuitous
tribulations they're making me endure...)

Pier Paolo Grassi


Il giorno ven 1 ott 2021 alle ore 00:39 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Thu, Sep 30, 2021 at 2:04 PM Pier Paolo Grassi <pierpaolog@gmail.com>
> wrote:
> >
> > Besides, google have sent me this error message two times:
> >
> > The recipient server did not accept our requests to connect. Learn more
> at https://support.google.com/mail/answer/7720 [prometheus.u-strasbg.fr
> 130.79.203.100: FAILED_PRECONDITION: connect error (111): Connection
> refused]
>
> I think we've crossed threads here, but FWIW I just got a popup in
> gmail about "having trouble authenticating" and had to re-log-in all
> my google accounts.
>

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

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

* Re: less with subprocess
  2021-09-30 20:59                           ` Pier Paolo Grassi
  2021-09-30 21:03                             ` Pier Paolo Grassi
@ 2021-09-30 23:46                             ` Dominik Vogt
  2021-10-01  0:04                               ` Pier Paolo Grassi
                                                 ` (2 more replies)
  1 sibling, 3 replies; 41+ messages in thread
From: Dominik Vogt @ 2021-09-30 23:46 UTC (permalink / raw)
  To: Zsh-Users List

On Thu, Sep 30, 2021 at 10:59:25PM +0200, Pier Paolo Grassi wrote:
> writing on disk it can eat away all the space I have on my device and make
> other processes that need that disk space to fail. Even if disk is cheap
> doesn't mean it's always plentifully available

If you don't want to consume disk space you could use a
ramdisk/tmpfs for the temporary files.  Less will gobble up memory
anyway if it gets tons of input, unless you give it the -b or -B
option.)

On the other hand I wonder what kind of command would generate an
awful lot of output quickly which can still be overlooked manually
in less.  I mean, if you're only interested in the first N lines
or M bytes, you can pipe the command's output through "head -n N"
or "head -c M".

  cat /dev/zero | head -c 1000000 LF

(With the global alias from an earlier message.)

--

So, what you really want is to put the producing command to sleep
while less is in "view" mode and wake it up when going to "follow"
mode?  That somehow contradicts your initial request:

>> I use it like this so I am able to use ctrl-c and +F inside less to move
>> around in the output already received ...
>> ... and receive the new input received in the meantime (with +F)
           ^^^^^^^     ^^^^^^^^^          ^^^^^^^^^^^^^^^

--

If you *don't* want to put the producing process to sleep, it
sounds a bit like "the command shall keep running and buffer the
output in a magical bag of holding while less is in 'view' mode".

--

If you don't want the output on disk, the only options I see are

 * either do not generate new data in the meantime
 * or store it somewhere else (memory/ramdisk, other medium)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-09-30 23:46                             ` Dominik Vogt
@ 2021-10-01  0:04                               ` Pier Paolo Grassi
  2021-10-01  0:06                                 ` Pier Paolo Grassi
  2021-10-01  0:31                                 ` Dominik Vogt
  2021-10-01  0:17                               ` Dominik Vogt
  2021-10-01  2:47                               ` Vincent Lefevre
  2 siblings, 2 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-10-01  0:04 UTC (permalink / raw)
  To: dominik.vogt, Zsh-Users List

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

Hello, thanks for your insights, but I think you are kind of missing the
point: I am already happy with what

less -f <(find ...)

gives me in terms of ux. Of course the output is generated continuously and
it is stored in ram by less, having gigabytes of ram it doesn't really
matters how much output is produced.
The only upgrade I was looking for was to be able to do ctrl-c to dispose
of the command even when find had not yet produced enough output to make
less satisfied, the infamous one screenfull of text.
your solution to use ctrl-z is good enough for that, given that no other
solution seems possibile (except for the patch proposed by Vincent, but I
can only cheer for that solution for now)
I fail to understand how it would help me to create a tmpfs and make the
long running process write there instead of to a pipe. If the process
doesn't produce output it will still hang the shell, doesn't it?

Pier Paolo Grassi


Il giorno ven 1 ott 2021 alle ore 01:49 Dominik Vogt <dominik.vogt@gmx.de>
ha scritto:

> On Thu, Sep 30, 2021 at 10:59:25PM +0200, Pier Paolo Grassi wrote:
> > writing on disk it can eat away all the space I have on my device and
> make
> > other processes that need that disk space to fail. Even if disk is cheap
> > doesn't mean it's always plentifully available
>
> If you don't want to consume disk space you could use a
> ramdisk/tmpfs for the temporary files.  Less will gobble up memory
> anyway if it gets tons of input, unless you give it the -b or -B
> option.)
>
> On the other hand I wonder what kind of command would generate an
> awful lot of output quickly which can still be overlooked manually
> in less.  I mean, if you're only interested in the first N lines
> or M bytes, you can pipe the command's output through "head -n N"
> or "head -c M".
>
>   cat /dev/zero | head -c 1000000 LF
>
> (With the global alias from an earlier message.)
>
> --
>
> So, what you really want is to put the producing command to sleep
> while less is in "view" mode and wake it up when going to "follow"
> mode?  That somehow contradicts your initial request:
>
> >> I use it like this so I am able to use ctrl-c and +F inside less to move
> >> around in the output already received ...
> >> ... and receive the new input received in the meantime (with +F)
>            ^^^^^^^     ^^^^^^^^^          ^^^^^^^^^^^^^^^
>
> --
>
> If you *don't* want to put the producing process to sleep, it
> sounds a bit like "the command shall keep running and buffer the
> output in a magical bag of holding while less is in 'view' mode".
>
> --
>
> If you don't want the output on disk, the only options I see are
>
>  * either do not generate new data in the meantime
>  * or store it somewhere else (memory/ramdisk, other medium)
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>
>

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

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

* Re: less with subprocess
  2021-10-01  0:04                               ` Pier Paolo Grassi
@ 2021-10-01  0:06                                 ` Pier Paolo Grassi
  2021-10-01  0:31                                 ` Dominik Vogt
  1 sibling, 0 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-10-01  0:06 UTC (permalink / raw)
  To: dominik.vogt, Zsh-Users List

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

PS I really appreciated the bag of holding reference :)

Pier Paolo Grassi


Il giorno ven 1 ott 2021 alle ore 02:04 Pier Paolo Grassi <
pierpaolog@gmail.com> ha scritto:

> Hello, thanks for your insights, but I think you are kind of missing the
> point: I am already happy with what
>
> less -f <(find ...)
>
> gives me in terms of ux. Of course the output is generated
> continuously and it is stored in ram by less, having gigabytes of ram it
> doesn't really matters how much output is produced.
> The only upgrade I was looking for was to be able to do ctrl-c to dispose
> of the command even when find had not yet produced enough output to make
> less satisfied, the infamous one screenfull of text.
> your solution to use ctrl-z is good enough for that, given that no other
> solution seems possibile (except for the patch proposed by Vincent, but I
> can only cheer for that solution for now)
> I fail to understand how it would help me to create a tmpfs and make the
> long running process write there instead of to a pipe. If the process
> doesn't produce output it will still hang the shell, doesn't it?
>
> Pier Paolo Grassi
>
>
> Il giorno ven 1 ott 2021 alle ore 01:49 Dominik Vogt <dominik.vogt@gmx.de>
> ha scritto:
>
>> On Thu, Sep 30, 2021 at 10:59:25PM +0200, Pier Paolo Grassi wrote:
>> > writing on disk it can eat away all the space I have on my device and
>> make
>> > other processes that need that disk space to fail. Even if disk is cheap
>> > doesn't mean it's always plentifully available
>>
>> If you don't want to consume disk space you could use a
>> ramdisk/tmpfs for the temporary files.  Less will gobble up memory
>> anyway if it gets tons of input, unless you give it the -b or -B
>> option.)
>>
>> On the other hand I wonder what kind of command would generate an
>> awful lot of output quickly which can still be overlooked manually
>> in less.  I mean, if you're only interested in the first N lines
>> or M bytes, you can pipe the command's output through "head -n N"
>> or "head -c M".
>>
>>   cat /dev/zero | head -c 1000000 LF
>>
>> (With the global alias from an earlier message.)
>>
>> --
>>
>> So, what you really want is to put the producing command to sleep
>> while less is in "view" mode and wake it up when going to "follow"
>> mode?  That somehow contradicts your initial request:
>>
>> >> I use it like this so I am able to use ctrl-c and +F inside less to
>> move
>> >> around in the output already received ...
>> >> ... and receive the new input received in the meantime (with +F)
>>            ^^^^^^^     ^^^^^^^^^          ^^^^^^^^^^^^^^^
>>
>> --
>>
>> If you *don't* want to put the producing process to sleep, it
>> sounds a bit like "the command shall keep running and buffer the
>> output in a magical bag of holding while less is in 'view' mode".
>>
>> --
>>
>> If you don't want the output on disk, the only options I see are
>>
>>  * either do not generate new data in the meantime
>>  * or store it somewhere else (memory/ramdisk, other medium)
>>
>> Ciao
>>
>> Dominik ^_^  ^_^
>>
>> --
>>
>> Dominik Vogt
>>
>>

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

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

* Re: less with subprocess
  2021-09-30 23:46                             ` Dominik Vogt
  2021-10-01  0:04                               ` Pier Paolo Grassi
@ 2021-10-01  0:17                               ` Dominik Vogt
  2021-10-01  2:47                               ` Vincent Lefevre
  2 siblings, 0 replies; 41+ messages in thread
From: Dominik Vogt @ 2021-10-01  0:17 UTC (permalink / raw)
  To: Zsh-Users List

On Fri, Oct 01, 2021 at 12:46:12AM +0100, Dominik Vogt wrote:
> On the other hand I wonder what kind of command would generate an
> awful lot of output quickly which can still be overlooked manually
> in less.

In the initial message you mentioned long running find commands.
A quick check on my Devuan system shows:

  $ find / | wc
   404059  465820 24085840

So, ~24 MB output from ~400.000 paths on a desktop system with
relatively few installed packets.  Make that twice as much on a
fancy, super flashy desktop.  Maybe add network filesystems.  Does
an upper bound of about 100 MB temporary disk space really matter?

It's hard to imagine a system where 100 MB disk space are too
much, but 100 MB memory are not.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-10-01  0:04                               ` Pier Paolo Grassi
  2021-10-01  0:06                                 ` Pier Paolo Grassi
@ 2021-10-01  0:31                                 ` Dominik Vogt
  2021-10-01  1:32                                   ` Pier Paolo Grassi
  1 sibling, 1 reply; 41+ messages in thread
From: Dominik Vogt @ 2021-10-01  0:31 UTC (permalink / raw)
  To: Zsh-Users List

On Fri, Oct 01, 2021 at 02:04:11AM +0200, Pier Paolo Grassi wrote:
> Hello, thanks for your insights, but I think you are kind of missing the
> point: I am already happy with what
>
> less -f <(find ...)
>
> gives me in terms of ux. Of course the output is generated continuously and
> it is stored in ram by less, having gigabytes of ram it doesn't really
> matters how much output is produced.
> The only upgrade I was looking for was to be able to do ctrl-c to dispose
> of the command even when find had not yet produced enough output to make
> less satisfied, the infamous one screenfull of text.

1) This is not an issue at all if the input comes from a regular
   file.

2) With "less -f <(<command>)" it can be solved by artificially
   generating at least a screen of output:

    $ less -f <(repeat $LINES; echo; <command>)

> I fail to understand how it would help me to create a tmpfs and make the
> long running process write there instead of to a pipe.

There was some issue about the generating command being killed by
ctrl-c.  Storing output in a tempfile solves this, and using a
ramdisk solves the disk space concerns.

> If the process
> doesn't produce output it will still hang the shell, doesn't it?

The "alias" or "shell function" solutions would run the generating
command in the backgroud, so the shell does not hang.  Also, less
does not hang when input comes from a regular file, even if that
file is growing.  This is a significant difference in behaviour
from taking input from a pipe.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


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

* Re: less with subprocess
  2021-10-01  0:31                                 ` Dominik Vogt
@ 2021-10-01  1:32                                   ` Pier Paolo Grassi
  0 siblings, 0 replies; 41+ messages in thread
From: Pier Paolo Grassi @ 2021-10-01  1:32 UTC (permalink / raw)
  To: Zsh-Users List, dominik.vogt

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

I use this on production servers where i don't want to alter anything that
is't necessary, so of course i will not create ramdisks just for launching
a find command with a pager attached ;)
this leaving aside the issues with kill raised by vincent, which i didn't
yet looked into

Il giorno ven 1 ott 2021 alle 02:36 Dominik Vogt <dominik.vogt@gmx.de> ha
scritto:

> On Fri, Oct 01, 2021 at 02:04:11AM +0200, Pier Paolo Grassi wrote:
> > Hello, thanks for your insights, but I think you are kind of missing the
> > point: I am already happy with what
> >
> > less -f <(find ...)
> >
> > gives me in terms of ux. Of course the output is generated continuously
> and
> > it is stored in ram by less, having gigabytes of ram it doesn't really
> > matters how much output is produced.
> > The only upgrade I was looking for was to be able to do ctrl-c to dispose
> > of the command even when find had not yet produced enough output to make
> > less satisfied, the infamous one screenfull of text.
>
> 1) This is not an issue at all if the input comes from a regular
>    file.
>
> 2) With "less -f <(<command>)" it can be solved by artificially
>    generating at least a screen of output:
>
>     $ less -f <(repeat $LINES; echo; <command>)
>
> > I fail to understand how it would help me to create a tmpfs and make the
> > long running process write there instead of to a pipe.
>
> There was some issue about the generating command being killed by
> ctrl-c.  Storing output in a tempfile solves this, and using a
> ramdisk solves the disk space concerns.
>
> > If the process
> > doesn't produce output it will still hang the shell, doesn't it?
>
> The "alias" or "shell function" solutions would run the generating
> command in the backgroud, so the shell does not hang.  Also, less
> does not hang when input comes from a regular file, even if that
> file is growing.  This is a significant difference in behaviour
> from taking input from a pipe.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>
> --
Pier Paolo Grassi

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

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

* Re: less with subprocess
  2021-09-30 23:46                             ` Dominik Vogt
  2021-10-01  0:04                               ` Pier Paolo Grassi
  2021-10-01  0:17                               ` Dominik Vogt
@ 2021-10-01  2:47                               ` Vincent Lefevre
  2 siblings, 0 replies; 41+ messages in thread
From: Vincent Lefevre @ 2021-10-01  2:47 UTC (permalink / raw)
  To: zsh-users

On 2021-10-01 00:46:12 +0100, Dominik Vogt wrote:
> On Thu, Sep 30, 2021 at 10:59:25PM +0200, Pier Paolo Grassi wrote:
> > writing on disk it can eat away all the space I have on my device and make
> > other processes that need that disk space to fail. Even if disk is cheap
> > doesn't mean it's always plentifully available
> 
> If you don't want to consume disk space you could use a
> ramdisk/tmpfs for the temporary files.

which can be worse (RAM is often more limited than disk space).

> Less will gobble up memory anyway if it gets tons of input, unless
> you give it the -b or -B option.)

No, not if one doesn't read data past some line.

For instance, I often pipe the output of "svn log" to "less", and
I generally read only the beginning to some point (not known in
advance). So, in practice, "less" will take a few dozens of KB
and avoid useless network transfers (since the log typically
comes from a remote server).

I think I've also run "less" on infinite loops ("while true; ...").

> On the other hand I wonder what kind of command would generate an
> awful lot of output quickly which can still be overlooked manually
> in less.  I mean, if you're only interested in the first N lines
> or M bytes, you can pipe the command's output through "head -n N"
> or "head -c M".

But with a pipe, "less" does that for you, automatically, and you
don't have to guess N or M. That's much better!

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-09-30 19:22                           ` Vincent Lefevre
@ 2021-10-01 16:44                             ` Bart Schaefer
  2021-10-03  1:45                               ` Vincent Lefevre
  0 siblings, 1 reply; 41+ messages in thread
From: Bart Schaefer @ 2021-10-01 16:44 UTC (permalink / raw)
  To: Zsh Users

On Thu, Sep 30, 2021 at 12:22 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2021-09-29 10:56:30 -0700, Bart Schaefer wrote:
> > On Wed, Sep 29, 2021 at 7:47 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
> > >
> > > LF () { () { cat >|$1 &! less $1 ; kill $! } =(:) }
> > LF <<(find)
>
> This is much worse! Ctrl-C then [End] yields
>
>   zsh: suspended (tty input)
>
> then "fg" makes the terminal unusable.

This doesn't happen to me with the current zsh head revision from git.
I do get the "suspended (tty input)" but "fg" just brings back "less"
... and the behavior is a bit different (although I'm not sure if
consistently so) when the process substitution uses 2>/dev/null or
2>&1

This does seem to have something to do with your suggested patch to "less".


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

* Re: less with subprocess
  2021-10-01 16:44                             ` Bart Schaefer
@ 2021-10-03  1:45                               ` Vincent Lefevre
  2021-10-03 21:41                                 ` Bart Schaefer
  0 siblings, 1 reply; 41+ messages in thread
From: Vincent Lefevre @ 2021-10-03  1:45 UTC (permalink / raw)
  To: zsh-users

On 2021-10-01 09:44:59 -0700, Bart Schaefer wrote:
> On Thu, Sep 30, 2021 at 12:22 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > On 2021-09-29 10:56:30 -0700, Bart Schaefer wrote:
> > > On Wed, Sep 29, 2021 at 7:47 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
> > > >
> > > > LF () { () { cat >|$1 &! less $1 ; kill $! } =(:) }
> > > LF <<(find)
> >
> > This is much worse! Ctrl-C then [End] yields
> >
> >   zsh: suspended (tty input)
> >
> > then "fg" makes the terminal unusable.
> 
> This doesn't happen to me with the current zsh head revision from git.
> I do get the "suspended (tty input)" but "fg" just brings back "less"
> ... and the behavior is a bit different (although I'm not sure if
> consistently so) when the process substitution uses 2>/dev/null or
> 2>&1
> 
> This does seem to have something to do with your suggested patch to "less".

The version of "less" I was testing didn't have my suggested patch
(it has two other patches, but unrelated to signal handling).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

* Re: less with subprocess
  2021-10-03  1:45                               ` Vincent Lefevre
@ 2021-10-03 21:41                                 ` Bart Schaefer
  0 siblings, 0 replies; 41+ messages in thread
From: Bart Schaefer @ 2021-10-03 21:41 UTC (permalink / raw)
  To: Zsh Users

On Sat, Oct 2, 2021 at 6:46 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> The version of "less" I was testing didn't have my suggested patch

That was my assumption.  I meant that your "less" patch might improve
the situation.


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

end of thread, other threads:[~2021-10-03 21:42 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-27 20:30 less with subprocess Pier Paolo Grassi
2021-09-27 20:46 ` Roman Perepelitsa
2021-09-27 21:38   ` Bart Schaefer
2021-09-27 21:48     ` Bart Schaefer
2021-09-27 22:57       ` Pier Paolo Grassi
2021-09-27 23:05         ` Bart Schaefer
2021-09-27 23:28           ` Pier Paolo Grassi
2021-09-27 23:31         ` Dominik Vogt
2021-09-28  0:41           ` Bart Schaefer
2021-09-28  0:53             ` Bart Schaefer
2021-09-28 18:52               ` Dominik Vogt
2021-09-28 19:29                 ` Bart Schaefer
2021-09-29 13:02                   ` Vincent Lefevre
2021-09-29 13:13                     ` Pier Paolo Grassi
2021-09-29 13:26                       ` Vincent Lefevre
2021-09-29 14:14                     ` Bart Schaefer
2021-09-29 14:47                       ` Pier Paolo Grassi
2021-09-29 17:56                         ` Bart Schaefer
2021-09-30 19:22                           ` Vincent Lefevre
2021-10-01 16:44                             ` Bart Schaefer
2021-10-03  1:45                               ` Vincent Lefevre
2021-10-03 21:41                                 ` Bart Schaefer
2021-09-30 19:17                       ` Vincent Lefevre
2021-09-30 19:48                         ` Dominik Vogt
2021-09-30 20:59                           ` Pier Paolo Grassi
2021-09-30 21:03                             ` Pier Paolo Grassi
2021-09-30 22:39                               ` Bart Schaefer
2021-09-30 22:46                                 ` Pier Paolo Grassi
2021-09-30 23:46                             ` Dominik Vogt
2021-10-01  0:04                               ` Pier Paolo Grassi
2021-10-01  0:06                                 ` Pier Paolo Grassi
2021-10-01  0:31                                 ` Dominik Vogt
2021-10-01  1:32                                   ` Pier Paolo Grassi
2021-10-01  0:17                               ` Dominik Vogt
2021-10-01  2:47                               ` Vincent Lefevre
2021-09-29 12:51                 ` Vincent Lefevre
2021-09-28 19:50           ` Pier Paolo Grassi
2021-09-27 21:38 ` Dominik Vogt
2021-09-27 22:35   ` Dominik Vogt
2021-09-27 23:03     ` Bart Schaefer
2021-09-29 12:24 ` Vincent Lefevre

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ https://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git