GNU bug report logs - #48137
27.2; `package-install-file' fails when loading a package file with DOS line endings

Previous Next

Full log

Message #77 received at 48137 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ioannis Kappas <ioannis.kappas <at> gmail.com>
Cc: 48137 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#48137: 27.2; `package-install-file' fails when loading a
 package file with DOS line endings
Date: Tue, 11 May 2021 15:55:31 +0300

> From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
> Date: Tue, 11 May 2021 07:52:02 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48137 <at> debbugs.gnu.org
> 
> > So you are saying the description of the package needs to be decoded
> > before using it for list-packages?  That'd be okay; all I care about
> > is that the decoded stuff does NOT replace the original raw bytes, but
> > instead is used only where decoding is needed.  IOW, decoding should
> > either be done on substrings of the original file, and the result
> > stored in strings, or the decoded stuff should be placed in a separate
> > scratch buffer, which will be used only where decoding is really
> > needed.
> 
> Is loading with `insert-file-contents' and saving as 'raw-text the
> same as copying the raw bytes of the original file?

No.  You should load with insert-file-contents-literally, and then
saving will automatically DTRT.

You could also load using raw-text, in which case Emacs will be able
to convert EOL.  But I don't recommend to do any conversions,
including the EOL conversions, because they still can change the
contents on saving in some rare cases.

> `hexlify-buffer' in 'hexl uses 'raw-text to display the raw bytes of
> an encoded buffer. I always assumed hexl displayed the actual binary
> representation of the underlying file.

It does, indeed.

> In which case, having `package-install-file' load the .el package file
> metaphorically and modifying `package-unpack' to store 'single files
> with 'raw-text should satisfy the requirement? Thus header parsing is
> done in the intended coding system, while the end package is a "copy"
> of the original.

Sorry, you lost me here: I don't think I understand the details of how
you intend to do the above.

> -         (package--write-file-no-coding el-file)))
> +         (package--write-file-raw-text el-file)))

You don't need to force any encoding on write: Emacs by default will
use the same encoding as the one used to read the file.

> Btw,
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-System-Basics.html
> mentions about the 'no-conversion coding system:
> 
>   no-conversion (and its alias binary) is equivalent to raw-text-unix:
> it specifies no conversion of either character codes or end-of-line.
> 
> but since it is -unix, it does do EOL conversions to LF.

No, -unix means it doesn't convert EOL.  IOW, the -unix part means
"assume Unix-style LF-only EOLs and don't convert EOL conventions".

Previous Next

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