Re: nested popen()'s lead to fgets() failure on 64-bit only

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jan 13 09:35, David Levine wrote:
> Corinna wrote:
> 
> > That's the version number of the setup-x86_64.exe tool, not the version
> > number of Cygwin.  Try `uname -r'.
> 
> 1.7.27(0.271/5/3)
> 
> > Maybe you're calling the wrong file command?  What's your $PATH set to?
> > What if you change your popen call to run /usr/bin/file.exe with full
> > path?
> > 
> >   if ((f2 = popen("/usr/bin/file --mime-type /usr/bin/file.exe", "r")))
> 
> My PATH picks /usr/bin/file, but just to be sure I hard coded it,
> and also used it for the first popen(), and also set PATH to /usr/bin:
> 
> $ gcc -o nested_popen nested_popen.c -Wall -Wextra && \
>   PATH=/usr/bin ./nested_popen
>   buf1 = /usr/bin/file.exe: application/x-dosexec
> popen: No error
> fgets2 EOF

Looks like this here:

  $ ./popen-test
    buf1 = /usr/bin/file.exe: application/x-dosexec
  popen: No error
    buf2 = /usr/bin/file.exe: application/x-dosexec

> It shouldn't be at EOF in this case.  If I change the
> second popen() to open anything, e.g.,
> popen("garbage,really", "r"), it still reports success.

Looks like this here:

  $ ./popen-test
    buf1 = /usr/bin/file.exe: application/x-dosexec
  popen: No error
  /bin/sh: garbage.really: command not found
  fgets2 EOF

Same as on Linux:

  $ ./popen-test
    buf1 = /usr/bin/file: application/x-executable
  popen: Success
    buf2 = /usr/bin/file: application/x-executable

  $ ./popen-test
    buf1 = /usr/bin/file: application/x-executable
  popen: Success
  sh: garbage.really: command not found
  fgets2 EOF

> We're getting closer?

Not really.  I have no idea why this fails for you.  Does an strace
show anything suspicious?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpAKLiFu77LH.pgp
Description: PGP signature