If we do end up going down the single argument only route, the following patch has the simplified code (I rebased onto the newest master before since there were changes) and an updated man page attached.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, June 28, 2019 4:06 AM, Michael Forney <[email protected]> wrote: > On 2019-06-27, Laslo Hunhold [email protected] wrote: > > > On Thu, 27 Jun 2019 09:10:28 +0200 > > Quentin Rameau [email protected] wrote: > > Dear Quentin, > > > > > I agree, yes is neither a benchmark tool nor a data generator, it just > > > outputs 'y' for piping into other commands. > > > Keep it simple. > > > > I agree with you in general, but are we really "optimizing" yes(1) here > > for the sake of performance? This looks to me like a case of premature > > optimization. > > I think we are all on the same page here about simplifying yes(1) > rather than optimizing it. See aidanwillie0317's most recent patch. > > > We don't know if a script relies on the behaviour of yes(1) printing > > all passed strings repeatedly. So, even though the tool is not > > standardized by Posix the common "consensus" is that > > > > - with no arguments, it shall print y and a newline repeatedly. > > - with arguments, it shall print them, comma separated, followed by > > newline, repeatedly. > > > > (I think you mean "space separated" here) > > How did you determine this consensus? All the BSD implementations I > looked at (OpenBSD, FreeBSD, NetBSD) only support a single argument. > > Do you have any examples of scripts relying on this behavior of yes(1)? > > > The point about readability is a good one. I will even take the blame > > for writing it as it is now. However, you could greatly improve > > readability without sacrificing features/performance. The line > > argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0; > > is used in many places in sbase and is more or less an idiom. The > > entire tool itself could then be written as follows. We can even > > remove the checks consequently within the loop, which could be regarded > > as a "performance" improvement. > > int i; > > argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0; > > if (argc == 0) { > > for (;;) { > > fputs("y\n", stdout); > > } > > } else { > > for (;;) { > > for (i = 0; i < argc; i++) { > > fputs(argv[i], stdout); > > fputc(' ', stdout); > > This will end up printing an extra space before the newline. > > > } > > fputc('\\n', stdout); > > } > > > > > > } > > What do you think? Patch is attached. > > This looks pretty good to me. If we decide to support any number of > operands, this seems like the way to do it.
From 9dac741f831a13757fd0dfa0a71992a65b8af289 Mon Sep 17 00:00:00 2001 From: AGitBoy <[email protected]> Date: Sun, 30 Jun 2019 22:17:14 -0400 Subject: [PATCH] Simplified yes codebase --- yes.1 | 4 ++-- yes.c | 12 +++++------- 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/yes.1 b/yes.1 index 87e390a..519343d 100644 --- a/yes.1 +++ b/yes.1 @@ -6,9 +6,9 @@ .Nd output strings repeatedly .Sh SYNOPSIS .Nm -.Op Ar string ... +.Op Ar string .Sh DESCRIPTION .Nm -will repeatedly write 'y' or a line with each +will repeatedly write 'y' or .Ar string to stdout. diff --git a/yes.c b/yes.c index ffc77f0..d4da256 100644 --- a/yes.c +++ b/yes.c @@ -6,23 +6,21 @@ static void usage(void) { - eprintf("usage: %s [string ...]\n", argv0); + eprintf("usage: %s [string]\n", argv0); } int main(int argc, char *argv[]) { - char **p; - ARGBEGIN { default: usage(); } ARGEND - for (p = argv; ; p = (*p && *(p + 1)) ? p + 1 : argv) { - fputs(*p ? *p : "y", stdout); - putchar((!*p || !*(p + 1)) ? '\n' : ' '); - } + char *p = argc > 1 ? argv[1] : "y"; + + for (;;) + puts(p); return 1; /* not reached */ } -- 2.21.0
