bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Eli Zaretskii
> From: Eric Blake > Date: Mon, 13 Feb 2017 14:20:56 -0600 > > > While we're on the topic, the undossify_input approach is just a > > heuristic and it sometimes guesses wrong. I wish the heuristic could be > > removed somehow, so that grep would behave more deterministically on > > MS-DOS/Windows

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Eric Blake
On 02/16/2017 11:26 AM, Eli Zaretskii wrote: >> I'm of the opinion that undossify_input causes more problems than it >> solves. We should trust fopen("r") to do the right thing, rather than >> reinventing it ourselves. > > FYI: You'd be losing an important feature for non-Cygwin DOS/Windows > us

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Paul Eggert
On 02/15/2017 06:23 AM, Eric Blake wrote: xfreopen() may need a patch Thanks for pointing out the problems with my suggestion. I think I'd rather leave xfreopen alone, as silently adjusting its argument from "wb" to "ab" might cause other problems. Instead, I added a Gnulib module to set the

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Eli Zaretskii
> Cc: egg...@cs.ucla.edu, 25...@debbugs.gnu.org > From: Eric Blake > Date: Thu, 16 Feb 2017 11:40:29 -0600 > > On 02/16/2017 11:26 AM, Eli Zaretskii wrote: > > >> I'm of the opinion that undossify_input causes more problems than it > >> solves. We should trust fopen("r") to do the right thing,

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Eli Zaretskii
> Cc: 25...@debbugs.gnu.org > From: Paul Eggert > Date: Thu, 16 Feb 2017 09:45:43 -0800 > > On 02/16/2017 09:26 AM, Eli Zaretskii wrote: > > It seems to me that when one bumps into some code which looks > > incorrect or less than optimal, and one considers its replacement with > > a more clever c

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Paul Eggert
On 02/16/2017 09:26 AM, Eli Zaretskii wrote: It seems to me that when one bumps into some code which looks incorrect or less than optimal, and one considers its replacement with a more clever code, No, that's not it. The idea was to simplify maintenance for the GNU case, perhaps at some cost t

bug#25749: grep 3.0 skips "binary" lines in ssconvert output

2017-02-16 Thread Paul Eggert
On 02/16/2017 10:10 AM, Alexey Shipunov wrote: I wonder how much work would require to invent new option, saying --binary-text-strict which will cause grep to stop with error and do not output anything... Something like that shouldn't be hard, although "do not output anything" is too simple, a

bug#25749: grep 3.0 skips "binary" lines in ssconvert output

2017-02-16 Thread Alexey Shipunov
Yes, I understand. So maybe that supposed option should make grep go through data two times? It could be hard though. But reporting error not (only) in stdout but (also) to stderr should be really helpful! AS 2017-02-16 16:07 GMT-06:00 Paul Eggert : > On 02/16/2017 10:10 AM, Alexey Shipunov wrot

bug#25707: [PATCH] grep: don't forcefully strip carriage returns

2017-02-16 Thread Paul Eggert
On 02/16/2017 10:08 AM, Eli Zaretskii wrote: I'm well aware that their needs are of a very low priority to you. I would not say "very low priority". (To me, "very low priority" would be something like supporting GNU grep on IRIX. :-) Regardless, it's better not to try to personalize any disa

bug#25749: grep 3.0 skips "binary" lines in ssconvert output

2017-02-16 Thread Paul Eggert
On 02/16/2017 02:14 PM, Alexey Shipunov wrote: But reporting error not (only) in stdout but (also) to stderr should be really helpful! That sounds like a better idea.