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

Previous Next

Package: emacs;

Reported by: Ioannis Kappas <ioannis.kappas <at> gmail.com>

Date: Sat, 1 May 2021 11:40:02 UTC

Severity: normal

Tags: patch

Found in version 27.2

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48137 <at> debbugs.gnu.org, Stefan Monnier <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: Mon, 3 May 2021 19:49:27 +0100
On Mon, May 3, 2021 at 7:33 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  48137 <at> debbugs.gnu.org
> > Date: Mon, 03 May 2021 14:23:53 -0400
> >
> > > Thanks Stefan. Does this also apply to the only other use of
> > > `insert-file-contents-literally' in 'package,?
> >
> > I don't think so, no.
> >
> > > In particular `package--with-response-buffer-1' is referenced by
> > > `package-check-signature'
> >
> > This definitely needs to deal with bytes only, we don't want any
> > encoding/decoding to risk changing the byte contents.
> >
> > > and `package--download-one-archive'.
> >
> > I think the same is true here.
> >
> > > (I am personally more in favor of supporting DOS files, because it
> > > makes the caller's life easier on MS-Windows and brings them on par
> > > with Unix, though Eli's concern has to be addressed first)
> >
> > My own opinion is that .el files are files that belong to Emacs and they
> > should use Emacs's "native" file format, whatever that is.  I think the
> > "most native" would be `utf-8-emacs-unix` so I'd be OK with deprecating
> > all other encodings, but I don't think that's going to happen ;-)
>
> I think it's wrong for package.el to try to decode these files.  It
> should deliver the files to the disk exactly as they are received
> through the wire.  And the only safe way of doing that is to treat
> these files as raw bytes.  Where we must interpret some parts of the
> files, we should take precautions to handle the complications related
> to the encoding, but we should not try to decode anything.

Thanks, I think there is agreement we shouldn't decode files coming
from a remote archive. Are there still concerns though with decoding
local .el files passed in to `package-install-file' supporting the
windows DOS EOL case Eli? If not, I would like to suggest a slightly
updated patch that is targeting .el files directly as an exemption:

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ecb2573cab..19ab0445b9 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2147,7 +2147,9 @@ package-install-file
         (progn
           (setq default-directory file)
           (dired-mode))
-      (insert-file-contents-literally file)
+      (if (string-match "\\.el\\'" file)
+          (insert-file-contents file)
+        (insert-file-contents-literally file))
       (when (string-match "\\.tar\\'" file) (tar-mode)))
     (package-install-from-buffer)))




This bug report was last modified 3 years and 364 days ago.

Previous Next


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