From: "Peter A. Castro" <doctor@fruitbat.org>
To: Peter Stephenson <pws@csr.com>
Cc: zsh-workers@sunsite.dk
Subject: Re: D03 test hang on cygwin with latest sources
Date: Tue, 25 Nov 2008 15:26:09 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0811251443420.4752@gremlin.fruitbat.org> (raw)
In-Reply-To: <200811250956.mAP9ukDw026001@news01.csr.com>
On Tue, 25 Nov 2008, Peter Stephenson wrote:
> Phil Pennock wrote:
>> On 2008-11-24 at 17:32 +0000, Peter Stephenson wrote:
>>> Right, the behaviour isn't new. It seems as if the subprocess is
>>> reading EOF from the input.
>>>
>>> % foo() { print $1; print hello >$1; [[ -e $1 ]] || print Ouch! }
>>> % foo >(sleep 1; read foo || print Failed)
>>> /proc/self/fd/12
>>> Failed
>>
>> ...% zsh -f
>> redoubt% echo $ZSH_VERSION
>> 4.3.6
>> redoubt% foo() { print $1; print hello >$1; [[ -e $1 ]] || print Ouch! }
>> redoubt% foo >(sleep 1; read foo || print Failed)
>> /tmp/zshQCDdM0
>> redoubt%
>>
>> Looks like a regression after all.
>
> Did you try it in 4.3.9? I tried it on three different versions, before
> and after 4.3.6, and got the same result. If your system is doing
> something different I'd like to find out what.
>
> I *can* get the test to pass if I undefine PATH_DEV_FD and define
> HAVE_FIFOS, so it looks like this is the way forward. Some
> investigation of why HAVE_FIFOS doesn't get define automatically would
> be useful.
Well, configure.ac has an explicit check for cygwin and disables the feature:
dnl -----------
dnl named FIFOs
dnl -----------
AC_CACHE_CHECK(if named FIFOs work,
zsh_cv_sys_fifo,
[if test "$host_os" = cygwin; then
zsh_cv_sys_fifo=no
else
The other thing about this is that the fifo test code fails but the
reason appears to be a race condition between the parent and child
creating the fifo. I've modified the example thus:
#include <fcntl.h>
#include <signal.h>
main()
{
char c;
int fd;
int pid, ret;
unlink("/tmp/fifo$$");
#ifdef HAVE_MKFIFO
if(mkfifo("/tmp/fifo$$", 0600) < 0)
#else
if(mknod("/tmp/fifo$$", 0010600, 0) < 0)
#endif
exit(1);
pid = fork();
if(pid < 0)
exit(1);
if(pid) {
fd = open("/tmp/fifo$$", O_RDONLY);
exit(fd < 0 || read(fd, &c, 1) != 1 || c != 'x');
}
sleep(1); /* prevent race */
fd = open("/tmp/fifo$$", O_WRONLY);
ret = (fd < 0 || write(fd, "x", 1) < 1);
unlink("/tmp/fifo$$");
exit(ret);
}
With this, the test runs, and HAVE_FIFOS gets defined. I hacked
configure to not set PATH_DEV_FD too. :-)
With the above changes the 'foo' test above works, though
Test/C02cond.ztst still generates an error.
Cygwin (really Windows) has some issues with fifos and the order in which
they are created, and for the longest time fifos were really just not
usable under Cygwin. Recent versions of Cygwin have updated the
fifo/pipe code but it's still subject to Windows underlying functions.
I understand the up coming Cygwin-1.7 will have a completely new
implemention of pipes which should behave more like what the POSIX spec
says it should.
I could probably provide a sample configure.ac for all of this if you'd
like, but the changes are pretty trivial.
> (I tried adding a "sync" pipe to getpipe() in the same way as in the
> other pipe code, but it didn't seem to help.)
>
> I'm also finding that I can read files with mode 000, so the [[ -r
> ... ]] test fails (but it's clearly doing the right thing, since "cat"
> on the file works, too). This may be because I have administrator
> rights. Unless some Cygwin expert can do this better, I'll apply the
> following.
>
> This is with Cygwin updated from the stable versions yesterday.
>
> Index: Test/C02cond.ztst
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Test/C02cond.ztst,v
> retrieving revision 1.22
> diff -u -r1.22 C02cond.ztst
> --- Test/C02cond.ztst 26 Feb 2008 20:50:13 -0000 1.22
> +++ Test/C02cond.ztst 25 Nov 2008 09:54:00 -0000
> @@ -94,6 +94,10 @@
> if (( EUID == 0 )); then
> print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]] (root reads anything)'
> [[ -r zerolength && -r unmodish ]]
> + elif [[ $OSTYPE = cygwin ]]; then
> + print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]]
> + (all files created by user may be readable)'
> + [[ -r zerolength ]]
> else
> [[ -r zerolength && ! -r unmodish ]]
> fi
--
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
next prev parent reply other threads:[~2008-11-25 23:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 4:08 Vin Shelton
2008-11-21 5:12 ` Bart Schaefer
2008-11-24 17:32 ` Peter Stephenson
2008-11-24 22:31 ` Phil Pennock
2008-11-25 9:56 ` Peter Stephenson
2008-11-25 23:26 ` Peter A. Castro [this message]
2008-12-01 12:20 ` Peter Stephenson
2008-12-02 3:42 ` Peter A. Castro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0811251443420.4752@gremlin.fruitbat.org \
--to=doctor@fruitbat.org \
--cc=pws@csr.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).