zsh-workers
 help / color / mirror / code / Atom feed
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


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