Eric Blake writes:
>> What's really happening is that we need to peek at the first few bytes
>> of f before deciding which program to call in popen. After peeking,
>> there's a call to fseek(f,0,0) before the popen, with the intention that
>> the child receives a file pointer set to the beginning
> Thanks (and thanks to Corinna and Eric) for correcting my misconceptions.
You're welcome. I only wanted to follow up that (I don't know what
the heck happened to my head, but) when I was
referring to file descriptors, I was consistently and mistakenly using
"1" where "0" should have been used:
On 2/27/2015 11:20 AM, A L wrote:
I think that would create an unacceptable performance penalty for the child
process.
The child process would not be affected at all! FILE* will be
unbuffered only in your
application, yet "cat" will read from a file descriptor "1" (and may
or may not apply an
> I think that would create an unacceptable performance penalty for the child
> process.
The child process would not be affected at all! FILE* will be
unbuffered only in your
application, yet "cat" will read from a file descriptor "1" (and may
or may not apply any
buffering on top of it, such as
On 02/27/2015 05:40 AM, Ken Brown wrote:
>> Wrong expectations. Keep in mind that the default read mode using
>> stdio functions is buffered. So your fread fills the buffer in f.
>> The buffer is typically something like 1K or 4K. If the file is
>> shorter than that, the file pointer will be set
On Feb 27 07:40, Ken Brown wrote:
> On 2/27/2015 3:43 AM, Corinna Vinschen wrote:
> >On Feb 26 22:05, Ken Brown wrote:
> >>I'm not sure exactly where the bug is, but here's what happens (STC at the
> >>end):
> >>
> >>1. I use freopen to open a file "foo" and associate it with stdin.
> >>
> >>2. I
On 2/27/2015 3:43 AM, Corinna Vinschen wrote:
On Feb 26 22:05, Ken Brown wrote:
I'm not sure exactly where the bug is, but here's what happens (STC at the end):
1. I use freopen to open a file "foo" and associate it with stdin.
2. I use fread to read a byte from foo.
3. I call popen, expectin
On Feb 26 22:05, Ken Brown wrote:
> I'm not sure exactly where the bug is, but here's what happens (STC at the
> end):
>
> 1. I use freopen to open a file "foo" and associate it with stdin.
>
> 2. I use fread to read a byte from foo.
>
> 3. I call popen, expecting the child process to have foo
I'm not sure exactly where the bug is, but here's what happens (STC at the end):
1. I use freopen to open a file "foo" and associate it with stdin.
2. I use fread to read a byte from foo.
3. I call popen, expecting the child process to have foo as its stdin, with the
file-position indicator po
Patch checked in. Thanks.
-- Jeff J.
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cygwin popen does not match Linux popen when stdout is closed.
...
Oops - when stdout is closed, and the pipe is output on child, cygwin
popen mistakenly lost the pipe in both processes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Cygwin popen does not match Linux popen when stdout is closed.
...
> Oops - when stdout is closed, and the pipe is output on child, cygwin
> popen mistakenly lost the pipe in both processes.
>
>
> The real world case that found this:
> cygwin$ echo '
Cygwin popen does not match Linux popen when stdout is closed.
In cygwin window 1:
$ cat foo.c
#include
#include
int main()
{
FILE *f;
f = popen("sleep 30", "r");
if (!f)
return 1;
getc(f);
if (pclose(f))
return 2;
return 0;
}
$ ./foo >&-
In cygwin window 2, durin
12 matches
Mail list logo
