sbase/yes.c

/* See LICENSE file for copyright and license details. */
#include <stdio.h>

#include "util.h"

int
main(int argc, char *argv[])
{
	char **p;

	argv0 = argv[0], argc--, argv++;

	for (p = argv; ; p = (*p && *(p + 1)) ? p + 1 : argv) {
		fputs(*p ? *p : "y", stdout);
		putchar((!*p || !*(p + 1)) ? '\n' : ' ');
	}

	return 1; /* not reached */
}
Adding the yes(1) command. 2012-04-23 16:27:40 +02:00			`/* See LICENSE file for copyright and license details. */`
			`#include <stdio.h>`
Fix coding style It was about damn time. Consistency is very important in such a big codebase. 2014-11-13 18:29:30 +01:00
Adding the yes(1) command. 2012-04-23 16:27:40 +02:00			`#include "util.h"`

			`int`
			`main(int argc, char *argv[])`
			`{`
Make already audited tools argv-centric instead of argc-centric This has already been suggested by Evan Gates <evan.gates@gmail.com> and he's totally right about it. So, what's the problem? I wrote a testing program asshole.c with int main(void) { execl("/path/to/sbase/echo", "echo", "test"); return 0; } and checked the results with glibc and musl. Note that the sentinel NULL is missing from the end of the argument list. glibc calculates an argc of 5, musl 4 (instead of 2) and thus mess up things anyway. The powerful arg.h also focuses on argv instead of argc as well, but ignoring argc completely is also the wrong way to go. Instead, a more idiomatic approach is to check *argv only and decrement argc on the go. While at it, I rewrote yes(1) in an argv-centric way as well. All audited tools have been "fixed" and each following audited tool will receive the same treatment. 2015-03-02 14:19:26 +01:00			`char **p;`
Finish up yes(1) by adding multiple string support 2015-02-01 02:13:47 +01:00
Do not use arg.h for tools which take no flags We've already seen the issue with echo(1): Before we changed it to ignore "--", the command $ echo -- did not work as expected. Given POSIX mandated this and makes most sense, in the interest of consistency the other tools need to be streamlined for that as well. Looking at yes(1) for instance, there's no reason to skip "--" in the argument list. We do not have long options like GNU does and there's no reason to tinker with that here. The majority of tools changed are ones taking lists of arguments or only a single one. There's no reason why dirname should "fail" on "--". In the end, this is a valid name. The practice of hand-holding the user was established with the GNU coreutils. "--help" and "--version" long-options are a disgrace to what could've been done properly with manpages. 2015-04-24 23:54:17 +02:00			`argv0 = argv[0], argc--, argv++;`
Adding the yes(1) command. 2012-04-23 16:27:40 +02:00
Make already audited tools argv-centric instead of argc-centric This has already been suggested by Evan Gates <evan.gates@gmail.com> and he's totally right about it. So, what's the problem? I wrote a testing program asshole.c with int main(void) { execl("/path/to/sbase/echo", "echo", "test"); return 0; } and checked the results with glibc and musl. Note that the sentinel NULL is missing from the end of the argument list. glibc calculates an argc of 5, musl 4 (instead of 2) and thus mess up things anyway. The powerful arg.h also focuses on argv instead of argc as well, but ignoring argc completely is also the wrong way to go. Instead, a more idiomatic approach is to check *argv only and decrement argc on the go. While at it, I rewrote yes(1) in an argv-centric way as well. All audited tools have been "fixed" and each following audited tool will receive the same treatment. 2015-03-02 14:19:26 +01:00			`for (p = argv; ; p = (p && (p + 1)) ? p + 1 : argv) {`
			`fputs(p ? p : "y", stdout);`
			`putchar((!p \|\| !(p + 1)) ? '\n' : ' ');`
Finish up yes(1) by adding multiple string support 2015-02-01 02:13:47 +01:00			`}`
Audit yes(1) Oh well, time to simplify the loop. Also, change the comment on unreachable code to something more clear. 2015-02-28 21:11:10 +01:00
			`return 1; /* not reached */`
Adding the yes(1) command. 2012-04-23 16:27:40 +02:00			`}`