On Sun, 9 Nov 2025, Greg Wooledge wrote: > On Sun, Nov 09, 2025 at 15:36:12 +0100, Nicolas George wrote: >> [email protected] (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
