>> 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.
In general, I have on occasion run into cases where it is important to know that sh -c is (or isn't) used. Consider $ foo echo a b \> z Does this put "a b" into z, or does it print "a b > z" on stdout? That's a substantial difference in behaviour, and it's the difference between pasting the arguments together with spaces and using sh -c, for the first result, and just execing the strings provided directly, for the second. In the particular case of script(1), the command is a single argument. In that case, it's the difference between $ script -c 'echo a b' a b $ and $ script -c 'echo a b' echo a b: not found $ Furthermore, and people using Bourne-family shells for interactive use tend to forget this, there's the difference between using sh -c and using $SHELL -c. In my case, for example, script -c 'echo x 1>&2' would print x to stderr (if using sh -c) or put "x 1" into a file named "2" (if using $SHELL -c). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
