Re: "does not contain a file descriptor" (Re: cat as a builtin command)

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Mon, 01 Sep 2014 12:44:03 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> On Sep 1, 11:39am, Bart Schaefer wrote:
> }
> } torch% exec {fd}<&-
> } zsh: parameter fd does not contain a file descriptor
> } 
> } It appears that only an UNSET parameter name triggers the "does not
> } contain" error; a set-but-empty parameter is treated as 0 and closes
> } standard input
> 
> Do we really want that behavior?

No, that doesn't seem a good idea.

> Or the following behavior?
> 
> torch% declare fd="12+7"
> torch% exec {fd}<&-
> zsh: failed to close file descriptor 19: bad file descriptor
> 
> Patch below makes this somewhat more rigorous; but if the parameter is
> declared as an integer, then even its string value is zero when no value
> has been assigned, so the original problem can't be completely avoided.
> (As far as I can tell, perhaps I'm wrong?)

The default value for an integer is 0, unless you explicitly set it.
There's no separate string default --- the string value comes from
converting the integer value each time it's needed.  So I think this is
unavoidable.  We could advise users to initialise fd variables to -1.

> I won't commit this without getting feedback, because it doesn't work
> correctly with parameters declared as integers in bases other than 10
> (also 8 if you set OCTAL_ZEROS, and also 16 if you set C_BASES).  So
> other suggestions are welcome ... or we can just document that all file
> descriptors must be base-10 integers, in which case we should change the
> base from 0 to 10 in the zstrtol() call.

I don't think this problem's fatal, but it's surprising if there isn't
some way or other of getting this to work by indicating the base
appropriately.

pws