4 ms·

> It runs at about 6 GiB/s on my system... Honest question: what are the practical use cases of this? Repeatedly typing the 'y' character into a Linux pipe is

by gitgud 4y ago

> It runs at about 6 GiB/s on my system... Honest question: what are the practical use cases of this? Repeatedly typing the 'y' character into a Linux pipe is surely not that common, especially at that bit rate. Also seems like the bottleneck would always be the consuming program...

singron 4y ago
Yes can repeat any string, not just "y". It can be useful for basic load generation.
- jolmg 4y ago
  I've used it to test some db behavior with `yes 'insert ...;' | mysql ...`. Fastest insertions I could think of.
TacticalCoder 4y ago
> Repeatedly typing the 'y' character into a Linux pipe is surely not that common, especially at that bit rate. At that rate no but I definitely use it once in a while. For example if a copy quite a few files and then get repeatedly asked if I want to overwrite the destination (when it's already present). Sure, I could get my commmand back and use the proper flag to "cp" or whatever to overwrite, but it's usually much quicker to just get back the previous line, go at the beginning (C-a), then type "yes | " and be done with it. Note that you can pass a parameter to "yes" and then it repeats what you passed instead of 'y'.
linsomniac 4y ago
Historically, you could have dirty filesystems after a reboot that "fsck" would ask an absurd number of questions about ("blah blah blah inode 1234567890 fix? (y/n)"). Unless you were in a very specific circumstance, you'd probably just answer "y" to them. It could easily ask thousands of questions though. So: "yes | fsck" was not uncommon.
- jolmg 4y ago
  > Historically It's probably still common in installation scripts, like in Dockerfiles. `apt-get install` has the `-y` option, but it would be useful for all other programs that don't.
  - linsomniac 4y ago
    Just to clarify: I was applying "historically" to "fsck", not to the use of "yes" in general. I can't remember the last time I've had the need to use "yes | fsck"
travisgriggs 4y ago
> Honest question: what are the practical use cases of this? It also allows you to script otherwise interactive command line operations with the correct answer. Many come like tools now days provide specific options to override queries. But there are still a couple hold outs which might not.
jolmg 4y ago
> especially at that bit rate. Also seems like the bottleneck would always be the consuming program... It's not made to be fast; it's just fast by nature, because there's no other computation it needs to do than to just output the string.
- kaba0 4y ago
  It is optimized quite seriously. I remember there was a comparison of it with I believe a BSD version, where the latter was thousands time more readable (although slower).
  - jolmg 4y ago
    I'm getting ~3.10GiB/s with both GNU's and FreeBSD's. I do see that GNU's version has some optimizations, but their effectiveness isn't apparent when doing `yes | pv > /dev/null`. However, my point was just that its performance was never a main point of it. Even without optimizations, it's still very fast, and I don't think whoever created it first was concerned with it having to be super fast, as long as it was faster than the prompts of whatever was downstream in the pipe.
  - zbentley 4y ago
    It really is! It's been a few years since I saw the article on HN so I just reposted it: https://news.ycombinator.com/item?id=31619076 https://news.ycombinator.com/item?id=31619076

by gitgud 4y ago

singron 4y ago

Yes can repeat any string, not just "y". It can be useful for basic load generation.

jolmg 4y ago
I've used it to test some db behavior with `yes 'insert ...;' | mysql ...`. Fastest insertions I could think of.

TacticalCoder 4y ago

> Repeatedly typing the 'y' character into a Linux pipe is surely not that common, especially at that bit rate. At that rate no but I definitely use it once in a while. For example if a copy quite a few files and then get repeatedly asked if I want to overwrite the destination (when it's already present). Sure, I could get my commmand back and use the proper flag to "cp" or whatever to overwrite, but it's usually much quicker to just get back the previous line, go at the beginning (C-a), then type "yes | " and be done with it. Note that you can pass a parameter to "yes" and then it repeats what you passed instead of 'y'.

linsomniac 4y ago

Historically, you could have dirty filesystems after a reboot that "fsck" would ask an absurd number of questions about ("blah blah blah inode 1234567890 fix? (y/n)"). Unless you were in a very specific circumstance, you'd probably just answer "y" to them. It could easily ask thousands of questions though. So: "yes | fsck" was not uncommon.

jolmg 4y ago
> Historically It's probably still common in installation scripts, like in Dockerfiles. `apt-get install` has the `-y` option, but it would be useful for all other programs that don't.
- linsomniac 4y ago
  Just to clarify: I was applying "historically" to "fsck", not to the use of "yes" in general. I can't remember the last time I've had the need to use "yes | fsck"

travisgriggs 4y ago

> Honest question: what are the practical use cases of this? It also allows you to script otherwise interactive command line operations with the correct answer. Many come like tools now days provide specific options to override queries. But there are still a couple hold outs which might not.

jolmg 4y ago

> especially at that bit rate. Also seems like the bottleneck would always be the consuming program... It's not made to be fast; it's just fast by nature, because there's no other computation it needs to do than to just output the string.

kaba0 4y ago
It is optimized quite seriously. I remember there was a comparison of it with I believe a BSD version, where the latter was thousands time more readable (although slower).
- jolmg 4y ago
  I'm getting ~3.10GiB/s with both GNU's and FreeBSD's. I do see that GNU's version has some optimizations, but their effectiveness isn't apparent when doing `yes | pv > /dev/null`. However, my point was just that its performance was never a main point of it. Even without optimizations, it's still very fast, and I don't think whoever created it first was concerned with it having to be super fast, as long as it was faster than the prompts of whatever was downstream in the pipe.
- zbentley 4y ago
  It really is! It's been a few years since I saw the article on HN so I just reposted it: https://news.ycombinator.com/item?id=31619076 https://news.ycombinator.com/item?id=31619076