From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19309 invoked from network); 4 Jun 1999 09:54:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Jun 1999 09:54:15 -0000 Received: (qmail 9452 invoked by alias); 4 Jun 1999 09:54:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6459 Received: (qmail 9445 invoked from network); 4 Jun 1999 09:54:03 -0000 Date: Fri, 4 Jun 1999 11:54:02 +0200 (MET DST) Message-Id: <199906040954.LAA03159@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 31 May 1999 18:33:45 +0000 Subject: Re: forwarded bug report 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@informatik.hu-berlin.de