Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: no_clobber and error conditions



Bart Schaefer wrote:
> However, it appears that the error from noclobber does not "throw an
> exception," it merely causes the command to have exit status 1.
> 
> That's not consistent with csh behavior (tcsh in this sample):
> 
> [schaefer@toltec /tmp]$ ( set noclobber; echo > lockfile; echo oops )
> lockfile: File exists.
> [schaefer@toltec /tmp]$ 
> schaefer[537] ( setopt noclobber; echo > lockfile; echo oops )
> zsh: file exists: lockfile
> oops
> schaefer[538]

It is consistent with bash.  The standard just says it "shall fail".  I
couldn't see a formal definition of "fail", but it seems just to
indicate returning a non-zero status, as in

  If a command fails during word expansion or redirection, its exit status
  shall be greater than zero.

But a failure doesn't need to be atomically handled, does it?  How about
revisiting:

  echo >foo || { readonly THROW; THROW= 2>/dev/null; };

(where "readonly THROW" should be at the top of the function).  Or, of
course, use throw and catch functions:

function lock() {
  emulate -L zsh
  setopt noclobber xtrace
  integer ret=-1

  autoload -U throw catch
  while true; do
    {
       : >$1  ||  throw Exists
    } always {
      if ! catch Exists; then
        if catch ''; then
          ret=1
        else
          ret=0
        fi
      fi
    }
    (( ret >= 0 )) && return $ret
    sleep 1
  done
}

("return" in the middle of the always block doesn't work.  I can't quite
make up my mind whether to be embarrassed or not.  It depends how
seriously you take "Execution [after the always block] continues from
the result of the execution of try-list".)

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



Messages sorted by: Reverse Date, Date, Thread, Author