Re: forwarded bug report

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On May 31,  3:12pm, Sven Wischnowsky wrote:
> } Subject: Re: forwarded bug report
> } 
> } Markus F.X.J. Oberhumer wrote:
> } >   compctl -s "\$(cat [tT]his-file-does-not-exist)" foo
> } 
> } When expanding the -s-string, we explicitly switch NULL_GLOB on so
> } that `compctl -s "*.c \$(< foo)"' works without producing an error if
> } there is no `*.c'.
> 
> That's not the only reason, is it?  We want the list of completion matches
> to be empty when the glob pattern fails; if the only concern was for the
> error, we could use NO_NOMATCH instead.

That's what I meant (I should have written `no files matching...').

> } Of course, this makes it fail in cases like the one above... (where
> } the cat tries to start reading and never finishes).
> } 
> } Does anyone have an idea how we could make this safe?
> 
> Seems as if we need a variant of NULL_GLOB that actually replaces the
> unmatched patterns with empty strings, rather than deleting them from the
> command entirely.

But that would fail with $(cat *.c *.h) if there are *.h files, but no 
*.c files.

> On May 31, 11:38pm, Tanaka Akira wrote:
> } Subject: Re: forwarded bug report
> }
> } I think that zsh can prevents hanging by redirecting stdin to /dev/null.
> 
> That's probably a good idea, but it doesn't solve the more general problem
> of commands being invoked with a different-than-expected number of args.
> 
> (Providing a closed stdin as if <&- might be a better idea for most cases,
> though it causes "cat" to complain about bad file descriptors.)

It seems that neither of sh, ksh, bash, and tcsh closes/redirects-to-/dev/null 
stdin of $(...) and `...` constructs. Should we do this only only when 
this may be called from completion?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx