[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #33138] .PARLLELSYNC enhancement with patch

From: Eli Zaretskii
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Fri, 26 Apr 2013 09:27:39 +0300

> Date: Wed, 24 Apr 2013 21:19:45 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > Date: Wed, 24 Apr 2013 19:14:01 +0200
> > Cc: address@hidden
> > From: Frank Heckenbach <address@hidden>
> > 
> > > Testing clearly shows it doesn't: GetFileInformationByHandle simply
> > > fails for handles open on console devices and the null device.  And we
> > > will be comparing handles for console devices in the majority of use
> > > cases here.
> > 
> > That's right. Or perhaps pipes (I post-process make's output, to
> > handle the directories in messages etc. and I suppose the mentioned
> > Emacs mode does something similar).
> GetFileInformationByHandle does work on pipes, at least on shell
> pipes (as in "foo | cat").
> > > I researched this a bit, and eventually succeeded in finding a way
> > > that is good enough for both disk files, pipes, and console devices.
> > 
> > Good. (And the null device, I suppose. Though it doesn't really
> > matter if we write to the null device combined or separate. ;-)
> No, I didn't find a satisfactory solution for the null device.  But as
> you point out, we don't care.

One more minor issue with this: do we want the comparison of stdin and
stdout for the purposes of combined_output to return zero, although
they refer to the same device on Unix?  I know it's a bit theoretical
for the case in point, but I'd like the code I write to be useful in
other contexts as well, and maybe even Make will need that in the

On Windows, console input and output use different devices, and I can
distinguish between them.  Should I?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]