GNU bug report logs - #51463
Lack of error message in several guix subcommands

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alice BRENON <alice.brenon <at> ens-lyon.fr>
Subject: bug#51463: closed (Re: bug#51463: Lack of error message in
 several guix subcommands)
Date: Sun, 07 Nov 2021 22:15:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#51463: Lack of error message in several guix subcommands

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 51463 <at> debbugs.gnu.org.

-- 
51463: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51463
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Alice BRENON <alice.brenon <at> ens-lyon.fr>
Cc: 51463-done <at> debbugs.gnu.org
Subject: Re: bug#51463: Lack of error message in several guix subcommands
Date: Sun, 07 Nov 2021 23:14:36 +0100

Hi Alice,

Alice BRENON <alice.brenon <at> ens-lyon.fr> skribis:

> I was giving guix shell a try today and noticed this annoying lack of
> relevant feedback from the tool: when running on a particularly
> malformed guix.scm, either by auto-loading or by explicitely passing -f
> guix.scm, guix shell returned in error ($? == 1) without printing any
> error message, which is a bit unhelpful.

I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the
issue affected ‘read-error’ exceptions for reasons other than missing
closing parentheses).

Let me know if anything’s amiss.

Thanks!

Ludo’.

[Message part 3 (message/rfc822, inline)]

From: Alice BRENON <alice.brenon <at> ens-lyon.fr>
To: bug-guix <at> gnu.org
Subject: Lack of error message in several guix subcommands
Date: Thu, 28 Oct 2021 19:15:17 +0200

[Message part 4 (text/plain, inline)]

Hi list,

I was giving guix shell a try today and noticed this annoying lack of
relevant feedback from the tool: when running on a particularly
malformed guix.scm, either by auto-loading or by explicitely passing -f
guix.scm, guix shell returned in error ($? == 1) without printing any
error message, which is a bit unhelpful.

The particular malformed guix.scm simply contains an extra parenthesis
after the package definition. Compare to the case when the package
definition lacks the final parenthesis, which yields a helpful message
like this:

/tmp/bug/guix.scm:25:1: missing closing parenthesis

This is not specific to guix shell because I could then reproduce this
behaviour with other commands like guix environment or guix build.

Find attached the file I've been using to reproduce the bug, which is
essentially the "hello" package example from the manual[1] without the
(define-public …) layer, in order for the top-level expression
contained in the file to be directly a package usable by -f (-l for
guix environment) and not have to put hello on the last line. The
version attached is correct and will allow guix shell -f guix.scm to
enter an environment where hello is installed. Remove a parenthesis,
you should have the above message. Add one, on the contrary, and you
should get nothing but silence.

I'm using guix on Guix System, and pulled this morning:

guix 5cbf9a4
  URL du dépôt : https://git.savannah.gnu.org/git/guix.git
  branche : master
  commit : 5cbf9a48d766191d8f17b2e9d1cf7b7db69b99ea


Regards,

Alice


[1]
https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html

[guix.scm (text/x-scheme, attachment)]

Previous Next

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