From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 06:12:38 2022 Received: (at 51466) by debbugs.gnu.org; 20 Jun 2022 10:12:38 +0000 Received: from localhost ([127.0.0.1]:54434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3EOb-0003Z4-Vj for submit@debbugs.gnu.org; Mon, 20 Jun 2022 06:12:38 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:44460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3EOY-0003Yj-Ek; Mon, 20 Jun 2022 06:12:36 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id B798461D76; Mon, 20 Jun 2022 10:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1655719948; bh=2sveoYcOrAXCbu66Lcz+YQA+rm7eOZZ8Y+bZIah7Ink=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=RAIxWx15cUc5Cl3qTm+pncCSa2S5+kS/zZvoVBZ7xBrK1dsSLCBR8OpNqEyNxrgXU XCdc2lK9Lxte4LaOSJ/dtZmraJ/k0wDfzJSlxS4rK3xsnW2KmpBGhl2F83xt9156CH J/bzczT0YNoV/ixlNP1waoq1EUxh/az2Ix+gg2iYt4Dm0IJsSxd7fRtKGm8AwD9XGp /ePMGoBMO/UlCg9wwf5XKPVxblk6Y7JTYAZIrONfbsyylTjjK2K4qGvGkb+pSLZouO oy0XvTCB6B+QoEhx+GkpA0lJnScp/VQuOuE9tapwSWE3RVYeeyaq7+ta/xCQKDC0Yv cvsyTNS0p3S4w== X-Virus-Scanned: Debian amavisd-new at emo09-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo09-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuE3T0keRJ6A; Mon, 20 Jun 2022 10:12:28 +0000 (UTC) Received: from localhost (m90-129-192-219.cust.tele2.se [90.129.192.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id D5E6D61C94; Mon, 20 Jun 2022 10:12:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1655719948; bh=2sveoYcOrAXCbu66Lcz+YQA+rm7eOZZ8Y+bZIah7Ink=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=RAIxWx15cUc5Cl3qTm+pncCSa2S5+kS/zZvoVBZ7xBrK1dsSLCBR8OpNqEyNxrgXU XCdc2lK9Lxte4LaOSJ/dtZmraJ/k0wDfzJSlxS4rK3xsnW2KmpBGhl2F83xt9156CH J/bzczT0YNoV/ixlNP1waoq1EUxh/az2Ix+gg2iYt4Dm0IJsSxd7fRtKGm8AwD9XGp /ePMGoBMO/UlCg9wwf5XKPVxblk6Y7JTYAZIrONfbsyylTjjK2K4qGvGkb+pSLZouO oy0XvTCB6B+QoEhx+GkpA0lJnScp/VQuOuE9tapwSWE3RVYeeyaq7+ta/xCQKDC0Yv cvsyTNS0p3S4w== From: bokr@bokr.com Date: Mon, 20 Jun 2022 12:12:10 +0200 To: Chris Marusich Subject: Re: bug#51466: bug#53355: guix shell --check: confusing error message Message-ID: <20220620101210.GA19777@LionPure> References: <87lez5td4n.fsf@gnu.org> <87sftc4osu.fsf@gmail.com> <87h79slysd.fsf@gnu.org> <87sft13dyv.fsf@gmail.com> <874k59d802.fsf@gnu.org> <87wnhy2w73.fsf_-_@gmail.com> <878rudzsmv.fsf@gnu.org> <87sfozzglf.fsf_-_@gmail.com> <871qvsubgv.fsf@gnu.org> <87k09cpest.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87k09cpest.fsf@gmail.com> https: //lwn.net/Articles/892755/https://lwn.net/Articles/892755/ttps://lwn.net/Articles/892755/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51466 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 53355@debbugs.gnu.org, 51466@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Chris, Did you observe this behaviour inside a git repo directory? I wonder if this git security thing could be relevant: https://lwn.net/Articles/892755/ It makes also me wonder about readline completion stuff possibly interacting. Isn't that implemented with readline? I have had some mystery bash parsing errors, and I noticed set|less shows a heck of a lot of functions defined that I don't remember seeing in the past. Anyway, shouldn't stuff like that have better hygiene than just prefixed _underscore ? Or maybe set|less doesn't show all that on your system? Disclaimer: I played a lot of games trying to make stuff conditional at login, where I renamed .bash_profile and .bashrc (e.g. .my_bashrc) which brought .profile into play, and I messed with the downstream of that to source some .my_'s conditionally, so I've go a fragile mess right now ;/ Anyway, did you determine why things changed in the first place? Or will this be a whack-a-mole game with future weirdnesses? :) Semms like IWBN to have interfaces governed by contracts :) Best, Bengt Richter On +2022-06-19 13:40:50 -0700, Chris Marusich wrote: > Hi Ludo, > > Thank you for the review! > > Ludovic Courtès writes: > > > LGTM, please push! > > Before pushing, I did some more tests to make sure it was still working. > When I did this, I noticed that read-line was no longer returning > strings that end in "\r". This prevents child-shell-environment from > behaving correctly, since it incorrectly assumes that all the lines end > in "\r", stripping it off unconditionally. In the past, I'm sure > read-line was returning strings that end in "\r". I don't know what > changed, but I've attached a second patch that fixes this issue, also. > > Unless you have more feedback, I'll go ahead and push both patches to > master in a few days. > > -- > Chris > > PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 > From c4fee9e63f8cb694de86ae46bd1e2e4c692eb6f6 Mon Sep 17 00:00:00 2001 > From: Chris Marusich > Date: Sun, 19 Jun 2022 13:16:04 -0700 > Subject: [PATCH] environment: Don't assume that lines have a trailing "\r". > > I've noticed that the child-shell-environment procedure is misbehaving on my > computer because the lines returned by read-line do not have a trailing "\r". > In the past, I recall that such lines did in fact have a trailing "\r". I'm > not sure why it changed, but it seems prudent to just rewrite this code to > tolerate both cases, since it seems that both cases can happen. > > * guix/scripts/environment.scm (child-shell-environment) [lines]: Instead of > checking if the line exactly matches "GUIX_CHECK_DONE\r"; check if the line > begins with "GUIX_CHECK_DONE". Instead of always stripping the trailing > character from the line, only do it if the line has a trailing "\r". > --- > guix/scripts/environment.scm | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm > index f0cb341aab..1fb4f5b7c6 100644 > --- a/guix/scripts/environment.scm > +++ b/guix/scripts/environment.scm > @@ -462,13 +462,18 @@ (define lines > ;; prompt from getting mixed into what we read. > (match (read-line shell-pipe-in) > ((? eof-object?) (reverse lines)) > - ("GUIX-CHECK-DONE\r" > + ((? (lambda (line) > + ;; The line might or might not have a trailing \r. > + (string-prefix? "GUIX-CHECK-DONE" line))) > (display "done\n" port) > (reverse lines)) > (line > - ;; Drop the '\r' from LINE. > - (loop (cons (string-drop-right line 1) > - lines)))))))) > + ;; Strip the trailing '\r' from LINE if present. > + (let ((stripped-line > + (if (string-suffix? "\r" line) > + (string-drop-right line 1) > + line))) > + (loop (cons stripped-line lines))))))))) > (close-port port) > (close-port shell-pipe-in) > (waitpid pid) > -- > 2.34.0 >