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