I would desire the yes command to be as slow as possible while still performing its basic function of automatically confirming questions that come up during an installation.
This is because I clusterssh into 40 machines and hey I haven't formally accepted them into my known_hosts file yet so I type "yes" to acknowledge them, but whoops I had already accepted two of them so now they are spitting out the letter 'y' as fast as they possibly can and now I have to wait for all of that output to transfer over the wire onto my machine despite pressing ctrl+c a minute ago.
Then just use yes | head -50? There's no need to artificially slow it down when there are more reasonable means of capping output than relying on SIGINT.
I'm not familiar with clusterssh, but assuming that it passes flags to ssh you can add `-o StrictHostKeyChecking=no`.
Of course, the parameter does what it says, but the security implications are really the same as for blindly yessing your way through. The best is to pre-populate your hosts file using ssh-keyscan.
Ah, so, this raises an interesting question: what do people use yes for?
One answer (a bad answer) is "generating artificial load".
This makes the I/O strategy oddly relevant -- different strategies result in different numbers of syscalls and (potentially) kernel lock acquisitions.
Couple this with someone trying to benchmark something's behavior with an antagonist load, and the story gets downright painful to contemplate in terms of confusing results.
Source: in my younger years, I did this. In more recent years, I've seen other engineers do it.
In this case it's probably just for fun and exercise, but generally don't think of speedy code as extending more effort, but as making the computer waste less effort. Well, unless the program isn't blocking anything any just waiting for the network, and other such cases. But any code that actually does run, especially in a loop, doesn't run in a vacuum, so I'd rather err on the case of speed. These tools don't get rewritten every 2 years in a new framework, which probably helps. Why not hone them if they're going to be that heavily used?
Because the yes command will repeat whatever string you give it. If you need to parse the incoming load in a certain way, /dev/{zero,urandom} won't be suitable.
I know right. The only time I have ever used it has required just 1 y/n and a new line. In that case, these "performance improvements" might make it slower for real world use cases.
