GNU bug report logs - #876
^M in some Windows info files because of null-byte detection

Previous Next

Full log

Message #40 received at 876-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 876-done <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: ^M in the info files
Date: Sat, 10 Jan 2009 17:13:56 +0200

> Date: Sat, 10 Jan 2009 15:07:37 +0100
> From: "Juanma Barranquero" <lekktu <at> gmail.com>
> Cc: 876-done <at> emacsbugs.donarmstrong.com, emacs-devel <at> gnu.org
> 
> On Sat, Jan 10, 2009 at 12:15, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > I fixed this bug.
> 
> If the info files are compressed with gzip (using the Windows binary
> from http://www.gzip.org), when visited from Info they still have
> spurious ^M.

I cannot reproduce this (tried with compressing info/emacs*).  Please
send a complete self-contained recipe.

Does "spurious" mean that every line has a ^M, like you saw before the
fix, or just some lines?

Also, does the above reference to http://www.gzip.org means that files
compressed by other versions of gzip do work as intended?

> As an aside, when I use MSYS' gzip I get an error in decompressing:
> 
>   Error while executing "gzip -c -q -d < c:/emacs/info/efaq.gz"
>   gzip: stdin: invalid compressed data--crc error
> 
> Could be related to CRLF issues in the redirection (but this is a gzip
> problem, not Emacs', of course).

Right, and I don't have MSYS anyway.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.