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