* 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 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: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: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-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 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: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
* 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-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-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: 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-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-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-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-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 ` 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 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 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
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
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).