From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ioannis Kappas Newsgroups: gmane.emacs.bugs Subject: bug#48137: 27.2; `package-install-file' fails when loading a package file with DOS line endings Date: Sat, 15 May 2021 14:52:39 +0100 Message-ID: References: <834kfmabvs.fsf@gnu.org> <83tunj651i.fsf@gnu.org> <83lf8u68bu.fsf@gnu.org> <83mtta4gtf.fsf@gnu.org> <83fsz24f2x.fsf@gnu.org> <83v97x2xum.fsf@gnu.org> <83bl9nevd3.fsf@gnu.org> <831rad5t18.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2932"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48137@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 15 15:54:38 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lhukY-0000XO-2F for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 May 2021 15:54:38 +0200 Original-Received: from localhost ([::1]:55800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhukX-000754-1k for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 May 2021 09:54:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhuj1-00033W-6g for bug-gnu-emacs@gnu.org; Sat, 15 May 2021 09:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36344) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhuj0-0006Hn-AH for bug-gnu-emacs@gnu.org; Sat, 15 May 2021 09:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lhuj0-00015p-5w for bug-gnu-emacs@gnu.org; Sat, 15 May 2021 09:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ioannis Kappas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 May 2021 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48137 X-GNU-PR-Package: emacs Original-Received: via spool by 48137-submit@debbugs.gnu.org id=B48137.16210867764190 (code B ref 48137); Sat, 15 May 2021 13:53:02 +0000 Original-Received: (at 48137) by debbugs.gnu.org; 15 May 2021 13:52:56 +0000 Original-Received: from localhost ([127.0.0.1]:47890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhuiu-00015V-4p for submit@debbugs.gnu.org; Sat, 15 May 2021 09:52:56 -0400 Original-Received: from mail-oi1-f173.google.com ([209.85.167.173]:34652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhuis-00015H-1G for 48137@debbugs.gnu.org; Sat, 15 May 2021 09:52:54 -0400 Original-Received: by mail-oi1-f173.google.com with SMTP id u11so2259537oiv.1 for <48137@debbugs.gnu.org>; Sat, 15 May 2021 06:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jw3d+NjfJwGeLszhB5MbnFNYZBz/ZtnU4Wm/ZTSGmyU=; b=Ln1OLpojZahKsPa5iRyiqeju95i15mQRKcqY8EDTfJazUNWUBgqwifWJJc4+9I4g9h NiW9CZVqiuNuNtt5xuB09xcvOzmYWGjvRHhD/7brmzS5y1L4gb7X20Fl7cNMmAhIskjc 1Okpan43/azJd9Z4fRDJ98Y9tfhqBCExKPTcoHiTt4Xq7FC8jdakdmY2h8nG77E/8N1P /yosiwEz+kYfon5qTnT6OnZ3la9UVlFxX1vRaeQ0/kUOqvtLBvXcmIhc5EXO4ohMDpQG 6zHxcPYhCJbFMO927MTmlCVTi377bHaOlGd0zBIdxl4WxAzA5jeOP48Mnt0WjfZoDuIm NtMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jw3d+NjfJwGeLszhB5MbnFNYZBz/ZtnU4Wm/ZTSGmyU=; b=QmoAmkrGqk9+9iMJ12iNIU7sZMVDNM2AIhsRY4Hj+TNRu+z6PYC1GVY1J1RjUE6Fwp i8tqP2TyHLR7A/ITFIQMKwUVfp5KLcBGpA5GJdz7dzZF/rA15jsMpHuYhuAEHykiE/KI ZlnI/ihzYM1Fb3GAPGMdXm7C1IbvyQVfDT8xi9vJ+bt9zdBxCSeacLLsCVlqVjKjwfAZ N8EX9qBfflKVGx3tyWwCBa03WUEcehlW5bwm/x+LoOidbjCI0QxNnvz/3RzbPt4H/nrG RoRCUS1zFxm25KUk3ec/d1MjqMIYIND3FUqufRKJt/yaZkoiL0z1Q5uo+qnLDv/LaVlV HnNw== X-Gm-Message-State: AOAM533kNaXiJewzn8d22OJEEe7JsMUvyRN17EvdNssnKcwNSWSmCg3A rf4kNpiSYK94jUJXq/opvJdesCPQ9zKuGvtzk5yCy2yY2VY= X-Google-Smtp-Source: ABdhPJyocwI3GuqyPpUkgS/rQ4Qzy84sLFeNyMx4i8LcOPtVceSaTc4q5YXRMna7IlNhSHTZkmG+3QPbBt4nNJ3lHFQ= X-Received: by 2002:aca:3684:: with SMTP id d126mr37035902oia.129.1621086768222; Sat, 15 May 2021 06:52:48 -0700 (PDT) In-Reply-To: <831rad5t18.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:206606 Archived-At: On Tue, May 11, 2021 at 1:55 PM Eli Zaretskii wrote: > > 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. Yes, sorry, you are right, I misunderstood how 'raw-text is used in `hexlify-buffer'. I thought it was used to discern the *original bytes seq* from the encoded buffer and send them over to the hexl process for processing. So, I was inquiring whether we could use the same in our case, i.e. decode the .el file (with `insert-file-contents'), but have `package-unpack' save it with 'raw-text instead of 'no-conversion. I was wrong though in my extrapolation, since 'raw-text specifies the encoding to use for reading data from the synchronous hexl process, not allegedly writing the original file byte sequence to the process from the buffer. Thus I take it there is no way to reconstruct the original file sequence from an encoded buffer under all circumstances as you said, even in our specific case where the scope is just an .el file. I shall have a look next whether we could always load the package with `insert-file-contents-literally' but parse headers with the correct encoding (`find-operation-coding-system' looks like a promising fn to determine the correct encoding from a literal file buffer). Thanks