1

yes produces a stream of "y" chars, or other requested.

If Unixen have a pseudodevice for random numbers, why not useful streams like this too?

Glorfindel
  • 815
  • 2
  • 10
  • 19
interstar
  • 1,077
  • 1
    You've asked the question the wrong way around, which is no doubt partly why people are objecting to it. A perhaps slightly better way around is to ask why, if Unices and Linux have a general purpose mechanism where any "useful stream" can be obtained from whatever program one cares to write to generate it, the pipe, is /dev/random a device file and not just a program that runs the very same CSPRNG in application space and writes to standard output. Not Why isn't everything like this all in the kernel? which is obvious, but Why is this in the kernel at all? – JdeBP Apr 21 '18 at 17:07
  • I think even by itself this question is quite valid and I feel it deserves a good answer. As for why is this in the kernel , it kind of has an answer here. This question is about the reverse statement i.e. why isn't everything in the kernel then – Ankur S Apr 21 '18 at 20:59
  • I agree that the question is valid and is formulated properly. The answers to Ankur S’s question illuminate the usefulness of having such a capability in the kernel. The only note I’d make is that /dev/random is not the best comparison; /dev/zero is the same as yes except it provides nulls instead of y bytes. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 03:36

1 Answers1

3

yes produces a stream of "y" chars, or other requested.

Precisely because of that. See yes(1) (which can repeat strings, not necessarily a single character - followed by newline).

It would be unpractical to have many devices, like /dev/repeatY to repeat Y, /dev/repeatO to repeat O etc.

Indeed, if you just want to get repeated zero bytes, consider /dev/zero (see zero(4))

BTW, on Linux, you could easily write your own kernel module implementing /dev/repeatY. But it is probably not worth the effort.

(so the why is also perhaps an historical reason)

Unixen have a pseudodevice for random numbers

These are probably much more difficult to get than a flow of constant bytes, and much more useful (and requires in practice some hardware support). See random(4) and this question. Read also myths about /dev/urandom

Basile Starynkevitch
  • 10,561
  • Your point that the yes program can write arbitrary strings is a valid argument why there should be a yes program; not so much that there should not be a /dev/yes. It would be trivial to make a family of /dev/zero clones that provide arbitrary byte values. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 03:36
  • Do we really want 256 different devices /dev/repeat0x00, /dev/repeat0x01, .... /dev/repeat0xfe, /dev/repeat0xff? I feel that would be too much (especially in the previous century) – Basile Starynkevitch Apr 22 '18 at 06:02
  • I would like the freedom to say mknod /dev/zero c 42 0 and mknod /dev/yes c 42 121 (at least as a matter of principle).  The modification to the /dev/zero driver — and I estimate that it would be a one-line change — wouldn’t require the user / administrator to instantiate all 256 nodes in /dev. Alternatively, we could make /dev/repeat/0x00 through /dev/repeat/0xFF and then link to the ones we want.  There’s lots of clutter under /dev/char and /dev/disk, and it doesn’t bother anybody. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 15:24
  • But if you want yes helloworld to be done by a device, it could be more difficult. I really think the reason is mostly historical: in the 1980s, 256 device inodes was not unsignificant – Basile Starynkevitch Apr 22 '18 at 16:23
  • OK, perhaps I was unclear.  I’m not suggesting that the driver be able to repeat arbitrary strings, just an arbitrary byte.  (I said that you had justified the existence of a yes program — although I would raise the point that the produce-a-string-repeatedly functionality could just as easily have been added to echo or printf as an option.) And, as I said, (a) it’s a one-line change to the kernel code, and (b) you don’t need to create all 256 inodes; just create the ones you want.  /bin/yes also takes an inode, and some disk space, too. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 16:34
  • We could also have something similar to losetup for loop device for the hypothetical /dev/repeat. Loop Device makes a regular file accessible just like a block device. It uses the losetup command to to send the loop device the name of this file via ioctl. In the same way we could send the name of the string we wish to repeat to the repeat device – Ankur S Apr 22 '18 at 21:03
  • 1
    First off, "yes" doesn't repeat one byte, it repeats two: 0x79 ('y') and 0x0a ('\n'). Second, /dev/null and /dev/zero are clearly useful (though I'd argue that the contents of /dev/zero don't matter as much as the fact that they are infinite). The use cases for other devices in that vein are less clear, and that makes it harder to justify putting this functionality in the kernel. – ioctl Apr 23 '18 at 18:31