Re: Cannot write to zsystem flock's descriptor

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 1,  2:49am, Sebastian Gniazdowski wrote:
}
} # echo "test" > file
} # zsystem flock -t 0 -f MY_FD "file"; echo $?
} 0
} # echo a>&${MY_FD}
} zsh: 11: bad file descriptor

This is actually internal to zsh and has nothing to do with the state
of the descriptor itself.  See addlockfd() in utils.c and lines 3524
to 3538 (approximately) in exec.c where the redirection is handled.

When you do >&${MY_FD} that implies duplicating the descriptor to
FD 1 of the "echo" job and then closing that descriptor when echo
has finished.  Doing so with the descriptor that is being held for
flock could cause the lock to be prematurely released, so when the
table of allocated descriptors is scanned for those that are valid
as redirection targets, the FTD_FLOCK descriptors are skipped.

I don't recall whether this is a portability issue -- e.g., it could
safely be done on linux as the util-linux flock executable seems to
imply, but perhaps it can't be done elsewhere.

You can always open a different descriptor on the same file, or first
open a descriptor on the file and then flock.  Locking with flock is
advisory only -- all programs accessing the file must agree to try
flock first -- so there's no restriction on other access before or
after flock is in place.