[riquito]

Except that it does not display a single yes line by default, so its primary purpose is effectively to print them forever. Also, in this particular corner of the netsphere we should applaud the maddening research for performance that people put into that seemingly obvious command

[ninkendo]

Edit: riquito is totally right here, I'm wrong. I'm leaving this for posterity, but this is all incorrect: stdout buffering by default will allow the "yes" process to write a lot of data even if you do a naive loop of printf calls. Writing to stdout will not block just because nothing's reading from it, the writes will be held in a decently-sized buffer by default, so even the naive approach will be wasting energy. I'll leave this for my own shame:

It prints them as long as the receiving process reads them. That’s how pipes work. When piping to a process that only reads from stdin once (you know, like the original purpose of the command, to respond “yes” to prompts from processes that are asking for confirmation), it will only write once (because stdout is line-buffered, so printing a string with a newline will block until something reads it.) Filling a buffer with 4,000 instances of “y\n” on the off chance that the receiving process will actually read all of those, is doing extra work that may not be needed.

“Maddening research for performance” in this case is coming at the expense of energy expenditure: you’re always allocating that memory and always filling a buffer with thousands of “y”s even when it’s just going to get thrown out. That should not be applauded. People should be just as concerned about energy usage as they are about wall clock time.