Re: where does command output go

[fxkl47BF@protonmail.com]

On Sun, 9 Nov 2025, Greg Wooledge wrote:

> On Sun, Nov 09, 2025 at 15:36:12 +0100, Nicolas George wrote:
>> fxkl47BF@protonmail.com (HE12025-11-09):
>>> i execute
>>>
>>> some_long_running_command | mail billy_bob@localhost
>>>
>>> where is the output of the command stored while it is running before it's mailed
>>
>> Under the responsibility of the mail command. Probably in memory.
>
> This command is called a "pipeline", and it has two smaller commands
> inside it.  Both of the smaller commands run simultaneously, and the
> output of the first command is connected to the input of the second
> command via a pipe(2).  For those who don't have the developer man
> pages installed:
>
> DESCRIPTION
>       pipe()  creates  a  pipe, a unidirectional data channel that can be used
>       for interprocess communication. [...]
>       Data written to the write end of the pipe is buffered by the ker‐
>       nel until it is read from the read end of the  pipe.   For  further  de‐
>       tails, see pipe(7).
>
> The first command is writing to the "write end of the pipe", and any
> output it produces will be buffered in memory until it's read by
> the second command, mail.
>
> Depending on how quickly the mail command reads input, the amount of
> data buffered in memory may be small, or large, but it will never
> exceed the kernel's maximum allocated pipe buffer size.  pipe(7) goes
> into some detail about the "Pipe capacity" on various kernel versions.
>
> If the amount of data buffered in the pipe reaches the kernel's limit,
> the writing process will "block" (be put on pause, essentially) until
> the reading process has consumed some data to make room for more.
>
> In practice, the mail command probably reads its input very quickly,
> so the amount of data held in the pipe will probably never reach the
> limit.  With other readers, this is not always going to be true.
>
> There is no temporary file involved in the pipeline itself.  The data
> written by the first command is read in pieces as it's being written.
> What the reader (mail) does with the data it reads will depend on how
> it was implemented.  The mail command may decide to hold all the input
> in memory, or it may write it to a file.  Different implementations of
> mail(1) may make different decisions about this.
>
> Once mail has received all of the input data, it will typically open
> its own pipe(2) to /usr/sbin/sendmail, to which it will write a full
> email message, including headers generated by the mail program, a
> blank line, and finally the input that it received from the first
> program.
>
>> From that point, treatment of the message will depend on your local MTA
> (whatever implements /usr/sbin/sendmail on your system).  It's very
> likely that your MTA will write the message to a file in what it calls a
> "queue", which is full of messages pending delivery.  When the message is
> ultimately delivered by the local delivery agent, it will typically end up
> in the recipient's "inbox", which could be a single file or a directory
> full of files, depending on how you've configured your mail system.
> Or, the recipient may have configured it so that the incoming message
> is piped through a program, or forwarded to an outside email address,
> or simply discarded.  There are lots of possibilities.
>


thanks for the details
if i wanted to have the same results as my command above
but wanted to do it so it didn't consume memory for storage
and i didn't want to manage files
what might a good alternate strategy be
is there a replacement for mail that uses file storage