Re: forwarded bug report

Re: forwarded bug report

[Peter Stephenson]

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

I certainly don't think we should change it if it's not for completion, you
never know what you're going to break.  But it looks harmless if it is from
completion --- although technically stdin and the editing file descriptor
are different, I can't imagine anyone really expects reading from stdin
during a completion to be useful, so I suppose it's worth doing.

I suppose closing it is better than redirecting it from /dev/null, since
then you get an error message which will warn the user that something
happened which shouldn't have --- although a bit cryptic: cat gives me
  cat: cannot stat 
Are there cases where this is bad?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: forwarded bug report

[Sven Wischnowsky]

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

Re: forwarded bug report

[Bart Schaefer]

On Jun 4, 11:54am, Sven Wischnowsky wrote:
} Subject: Re: forwarded bug report
}
} > 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.

A variant of CSH_NULL_GLOB, then; you get exactly one empty string, only if
none of the patterns match.

} [...] 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?

That's what I meant, yes.  Don't just close the stdin of $(...), rather,
treat the entire completion system as if it were inside { ... } <&-

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: forwarded bug report

[Tanaka Akira]

In article <9906040940.AA31818@ibmth.df.unipi.it>,
  Peter Stephenson <pws@ibmth.df.unipi.it> writes:

> I suppose closing it is better than redirecting it from /dev/null, since
> then you get an error message which will warn the user that something
> happened which shouldn't have --- although a bit cryptic: cat gives me
>   cat: cannot stat 
> Are there cases where this is bad?

I think also that closing stdin is right behavior to show that reading
from stdin is an error in completion. But it is bit more riskey than
redirecting stdin from /dev/null.

At least, on SunOS 4.1.4, following command produces strange result.
(some-file is opend as file descriptor 0 and comm confuses.)

  comm some-file - <&-

However, intentional read from stdin like above may not appear in
copmletion.
-- 
Tanaka Akira

Re: forwarded bug report

[Bart Schaefer]

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.

} 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.

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.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: forwarded bug report

[Tanaka Akira]

In article <199905311312.PAA18094@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Does anyone have an idea how we could make this safe?

I think that zsh can prevents hanging by redirecting stdin to /dev/null.
-- 
Tanaka Akira

RE: forwarded bug report

[Andrej Borsenkow]

  However, I think the real bug here is
> that for some
> reason it takes two ^C's to stop it.

What do you mean? Running pws-19 with all patches, I have to press ^C once
to stop completion and return to line editing. Second ^C cancels current
input line alltogether.

But some feedback from Zsh like "completion cancelled" would be welcome
though.

/andrej

Re: forwarded bug report

[Sven Wischnowsky]

Markus F.X.J. Oberhumer wrote:

> zsh badly hangs if file globbing fails in connection
> with completion. Please try the following with
> any zsh 3.x version (including 3.1.5-pws-19) and
> enter "foo [tab]":
> 
>   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'.
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?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: forwarded bug report

[Peter Stephenson]

Sven Wischnowsky wrote:
> 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'.
> 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?

I though of playing around with CSH_NULL_GLOB like options, but couldn't
get that to work reasonably.  One possibility is to timeout $(...)'s when
they occur inside zle.  However, I think the real bug here is that for some
reason it takes two ^C's to stop it.  Fixing that would just leave the user
with the reponsibility of testing difficult cases (and adding /dev/null on
the end if necessary).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

forwarded bug report

[Peter Stephenson]

just got this which I should probably pass on.

------- Forwarded Message

Message-Id: <XFMail.990527044528.markus.oberhumer@jk.uni-linz.ac.at>
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Thu, 27 May 1999 04:45:28 +0200 (CEST)
Reply-To: markus.oberhumer@jk.uni-linz.ac.at
From: "Markus F.X.J. Oberhumer" <markus.oberhumer@jk.uni-linz.ac.at>
To: pws@ifh.de
Subject: zsh 3.1.5-pws-19 bug report
Content-Transfer-Encoding: 8bit

Hello Peter !

It's good to see that someone is still working on inproving
zsh. I'm using this opportunity to report a nasty bug
that is annoying me for almost two years now (I had posted
that to zsh-workers a year ago, but without response).

zsh badly hangs if file globbing fails in connection
with completion. Please try the following with
any zsh 3.x version (including 3.1.5-pws-19) and
enter "foo [tab]":

  compctl -s "\$(cat [tT]his-file-does-not-exist)" foo
 
thanks,
Markus

- -----   Markus F.X.J. Oberhumer <markus.oberhumer@jk.uni-linz.ac.at>   -----
- -----             http://wildsau.idv.uni-linz.ac.at/mfx/               -----
- -----        5E CB 5C 85 DE AF 9E BF  E9 DA 7E 6A 39 F8 CC 67          -----

                             3 WARPS TO URANUS




------- End of Forwarded Message