zsh-users
 help / color / mirror / code / Atom feed
From: Pier Paolo Grassi <pierpaolog@gmail.com>
To: dominik.vogt@gmx.de, Zsh-Users List <zsh-users@zsh.org>
Subject: Re: less with subprocess
Date: Fri, 1 Oct 2021 02:06:05 +0200	[thread overview]
Message-ID: <CAP+y1xCXNrYLooi86idzUZjnUZZqhwo46489Th+j_bNRY+Zx+A@mail.gmail.com> (raw)
In-Reply-To: <CAP+y1xCSWkappkaRoM7+k=svEf3E_OKb_8o7mgGmkVMgPLX=Kg@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2021-10-01  0:07 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 20:30 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAP+y1xCXNrYLooi86idzUZjnUZZqhwo46489Th+j_bNRY+Zx+A@mail.gmail.com \
    --to=pierpaolog@gmail.com \
    --cc=dominik.vogt@gmx.de \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).