On Tue, Jan 04, 2022 at 09:16:30PM +0700, Robert Elz wrote: > Date: Mon, 3 Jan 2022 20:12:09 +0100 > From: =?utf-8?B?0L3QsNCx?= <nabijaczleweli%nabijaczleweli.xyz@localhost> > Message-ID: <cover.1641236714.git.nabijaczleweli%nabijaczleweli.xyz@localhost> > | script.c: fix usage string > > That one isn't a fix, just a change. In man pages and other > similar places meaning for words in exampkes (distinguishing > literal data from pkaceholders for example) can be done by > various markup/formatting techniques. Usage messages do not > have that possibility, just text. Some applications use the > <word> nitation to indicate that "word" is not literal text, > but to be replaced by the user. Others do not, keaving it to > either the written explanation, or just the common knowledge > of the reader to work out what should be entered as shown, > and what shoukd be replaced by the user's data. Neither is > correct, it is just a matter if choice. Yes, with this I don't disagree, but having no space between the []s in "[-c <command>][-adfpqr]" is, I'd say, a bug. At the very least, it's inconsistent with the rest of the usage strings (implying "script -c ls-a" is in some way valid) and adheres to XBD 12.1 syntax, which is slightly out-of-place here. (Also, most others I've tried don't surround option-arguments with <>s, and neither does XBD. Yes, this is less of a problem, but still, consistency.) Would "space out usage string for consistency" work as a message for you? > | script.c: use sh -c directly instead of system(3) > I'm nkt sure why that would matter, but if it is going > to change tgat way it shoukd use "sh -c -- command" so > commands tgat haopen to start with - or + are nit treated > as options by the shell (posix is going to require this > of system() and popen() - generally it is better to just > use those interfaces so enhancements to them simply > flow through to the applications. Because system(3) forks and waits, again. This both wastes a process and falls down to fail() in all cases, SIGTERMing the whole pgroup (as opposed to the no--c path which simply execs). Also, system(3) is also susceptible to this, so I'm not sure what you mean here (try it! run "script -c-l"!). system(3) just sucks. I've added the "--"s, and will include them in v2. > | script.1: clarify that -c runs the argument via sh -c > Even if #2 was done, this is too much detail. Users care what > happens, not the nechanism by which it is made to work. Disagree, sh -c arg is /what/ is being done. This is fundamentally different from if script -c /actually/ took a command, like FreeBSD script does. As it stands, and, for compatibility, presumably as it will stand, script takes a shell program, not a command, and script -c 'for i in 0 1 2 3 4 5 6; do echo $i; done; exec ls' is valid. Admittedly, saying "-c script" or "-c shell-program" /would/ be too much, but as it stands, it's still important to note this, because the string is subject to shell expansion. Best, наб
Attachment:
signature.asc
Description: PGP signature