Re: /bin/sh redirect without command failure mode

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 24 Nov 2018 23:46:10 +0100 (CET)
    From:        neitzel%hackett.marshlabs.gaertner.de@localhost (Martin Neitzel)
    Message-ID:  <20181124224610.254DE348F1%marshlabs-mx.gaertner.de@localhost>

  | As admin I quite often use a simple
  | 	> foo.log

Oh, yes, of course, I wasn't thinking of that case (the ones that were more
in issue were things like "<&4" used for the purpose of testing if fd 4 is 
open)

But this provides a good real example of the question.  If the redirect cannot
be performed (here, say there is a foo.log already, and either it has no write
permission, or is a directory, or there is no foo.log, and there is no write
permission on the current directory) should a script containing that command
terminate at this point, or simply continue, with $? set to indicate a failure?

Note that ": >foo.log" will always cause the script to terminate (as : is a 
special builtin, and that is required), and "true >foo.log" will always set $?
non-zero ("true" doesn't get run) and continue), as does "command : >foo.log"
(command turns off the specialness of ':') so the script writer can always
specify one behaviour or the other.    The question relates to what should be
done when that is not done, and we have just the bare redirect.

In an interactive shell, the failure will cause an error, $? to be set, and
a prompt for the next command - the only time there would be a difference
would be if you had entered

	> foo.log ; echo hello

or something similar, or perhaps

	for i in 1 2 3; do >"foo.$i"; done

when the echo will, or will not, be executed (or the loop will, or will not, 
iterate) depending upon what we decide is the answer to this question
(currently, will not, but in other shells, will).-- assuming the redirect fails
of course.

kre