If you are looking for a non-joke implementation[0]. Excluding the test code at the bottom, the Rust version is a bit less than 120 lines.
[0] https://github.com/uutils/coreutils/blob/main/src/uu/yes/src...
[0] https://github.com/uutils/coreutils/blob/main/src/uu/yes/src...
int main(int argc, char *argv[])
{
if (pledge("stdio", NULL) == -1)
err(1, "pledge");
if (argc > 1)
for (;;)
puts(argv[1]);
else
for (;;)
puts("y");
}
[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c
[2] https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
[3] https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
The GNU-yes
$ yes | pv > /dev/null
... [10.2GiB/s] ...
void main() {
while(write(1, "y\n", 2)); // 1 is stdout
}
$ gcc yes.c -o yes
$ ./yes | pv > /dev/null
... [6.21 MiB/s] ... yes | pv > /dev/null
0:00:15 [1.12GiB/s]
build/yes | pv > /dev/null
0:00:20 [1.03GiB/s]
package main
import "core:sys/linux"
import "core:os"
import "core:strings"
main :: proc() {
msg := "y" if len(os.args) == 1 else os.args[1]
msg = strings.concatenate({msg, "\n"})
buf := transmute([]u8) strings.repeat(msg, 8192)
for {
linux.write(linux.STDOUT_FILENO, buf)
}
}I suspect what you suggest creates a more voluminous dump but is slower in the desired use case
yes &
The GNU version of true/false is more interesting. All the logic is in true and false just redefined the EXIT_STATUS and imports all of true.c. https://github.com/coreutils/coreutils/blob/master/src/false...
It unnecessarily duplicates the for loop. I would have written something like:
char *what = argc > 1 ? argv[1] : "y";
for (;;)
puts(what);In 99% of cases, yes of course you’re right, factor this loop.
In this specific case? This is trivial code, that will likely _never_ change. If it does change, it’s extremely unlikely that the two loops would accidentally diverge (the dev would likely not miss one branch, tests would catch it, reviewers would catch it). So if you get any upside by keeping the two loops, it might be worth it.
Here you get 8 bytes back. I honestly can’t see how that would ever matter, but hey it’s _something_, and of course this is a very old program that was running on memory-constrained machines.
So it’s a trade-off of (minor) readability versus (minor) runtime optimisation. I think it’s the better choice (although it’s very minor).
Or maybe there’s a better reason they chose this pattern… can’t imagine the compiler would generate worse code, but maybe it did back in the days?
If you consistently deduplicate code that is supposed to do the same and evolve the same, then any duplicated code sticks out as a statement of “this isn’t the same”, and in the present case it then makes you wonder what is supposed to be different about both cases. In other words, such code casts doubt on one’s own understanding, raising the question whether one might be overlooking an important conceptual reason for why the code is being kept duplicated. So in that sense I disagree that the duplicated version is more readable, because it immediately raises unanswered questions.
About possible performance reasons, those need an explanatory comment, exactly for the above reason. And also, if performance reasons warrant complicating the code, then it isn’t “as simple as it gets” any more. I was commenting because I disagreed with that latter characterization.
for (;;) {
if (argc > 1)
puts(argv[1]);
else
puts("y");
}
You said "it’s about duplicating logic that should inherently be the same", but that is exactly how it is more explicit, by having this duplication. I assume your problem is with the two "puts()"?
But still, I don’t see why you wouldn’t first name what you want to output before starting the outputting. If anything, I’d place the whole output loop in a separate function and have two calls to that function. Nevertheless, it’s even better to express in code the fact that the program doesn’t want to make a distinction between a literal “y” and an argument “y”, by consolidating them into the same variable.
Another way to do this would be to have a static default argument array containing the “y”, and for example having:
if (argc <= 1) { argv = default_argv; }
for (;;) { puts(argv[1]); }
Though I think the separate variable (what) is clearly preferable.
> in that sense I disagree that the duplicated version is more readable
I didn't say it is, I agreed it's _less_ readable. I said it's trading off readability for 8 bytes of memory at runtime.
> If you consistently deduplicate code that is supposed to do the same and evolve the same, then [...]
I agree with all this. I'm not saying to consistently go for the deduplicated approach (I don't think anyone would say that), I'm saying it's a reasonable trade-off in this specific case (each branch is still trivial, and the code won't evolve much if at all).
> About possible performance reasons, those need an explanatory comment, exactly for the above reason.
Agreed.
> if performance reasons warrant complicating the code, then it isn’t “as simple as it gets” any more. I was commenting because I disagreed with that latter characterization.
Also agreed.
This joke project has a lot of truths in it that others do dead seriously; something to think about.