[bug #27983] Windows text mode mis-interpreted

[Ilguiz Latypov]

Follow-up Comment #9, bug #27983 (project findutils):

> app | d2u | xargs

> That is a one-size-fits-all solution - it works no matter the windows app
on the left and no matter the consumer on the right.

This means that the developers should be aware about the newline subtlety
that may be exposed by the use of Windows native applications and the Cygwin's
text mode mounts.

Some developers may test their changes on binary only mounts forgetting about
other users who are not even aware about the kind of the mount they have.

> to make it easier to change an existing stream to binary-only

I do not understand your point.  Earlier you argued that using the 'b' option
in the file open mode makes no sense on POSIX, and this is confirmed by the
Open Group specs.

Now you are saying that since the use of that option should be harmless on
POSIX-compliant systems, we could use it so that on some specific systems this
option would make a difference.  

But this hides the fact that Cygwin cannot be POSIX-compliant when processing
arbitrary input streams or generating output streams.  This is because Cygwin
should take the notion of native newlines into account.

As for the suggested change to either the use of freopen() or to the
xfreopen() wrapper with regards to preserving the possible append mode, I
agree that all uses of freopen() with "w" may need reviewing.  I am afraid
that just modifying freopen()'s implementation itself to preserve the append
mode would be too drastic as this could change the existing behavior where the
append mode was not supposed to be preserved.

(In case of xargs, only the mode of the input stream needs to be changed, so
preserving the append mode does not seem to be an issue to me).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27983>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/