GNU bug report logs -
#51466
guix shell --check reports missing PKG_CONFIG_PATH on Debian bookworm
Previous Next
To reply to this bug, email your comments to 51466 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Thu, 28 Oct 2021 19:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vagrant Cascadian <vagrant <at> debian.org>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Thu, 28 Oct 2021 19:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is a recently installed Debian bookworm system, initially using the
package from debian experimental (guix 1.3.0-3, built with guile 3.0),
and "guix pull" up to a recent guix master:
vagrant <at> vagranttdgxbookworm:~$ guix describe
Generation 7 Oct 28 2021 11:04:25 (current)
guix 0e6470b
repository URL: /home/vagrant/src/guix
branch: master
commit: 0e6470b47f00470c213fbf20bddc5bcf1e2f8e2a
Most things seem to work fine, but noticed an oddity with guix shell:
vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --check --development guix guix git less
guix shell: checking the environment variables visible from shell
'/bin/bash'...
guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell
environment
hint: One or more environment variables have a different value in the
shell than the one we set. This means that you may find yourself
running code in an environment different from the one you asked Guix to
prepare.
This usually indicates that your shell startup files are unexpectedly
modifying those environment variables. For example, if you
are using Bash, make sure that environment variables are set or modified
in `~/.bash_profile' and _not_ in `~/.bashrc'. For more
information on Bash startup files, run:
info "(bash) Bash Startup Files"
Alternatively, you can avoid the problem by passing the `--container' or
`-C' option. That will give you a fully isolated
environment running in a "container", immune to the issue described
above.
vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --development guix guix git less
vagrant <at> vagranttdgxbookworm:~$ echo $PKG_CONFIG_PATH
/gnu/store/9vk59alg27y0cp1za91nfdjiy718cn1f-profile/lib/pkgconfig
So, --check seems to think the environment variable is missing but
running without --check the variable is defined...
I don't see anything obviously relevent in /etc/profile/ or
/etc/profile.d/guix.sh or /etc/profile.d/bash-completions.sh or
~/.profile or ~/.bashrc ... just used the defaults that shipped in
Debian.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Fri, 29 Oct 2021 19:07:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi!
Vagrant Cascadian <vagrant <at> debian.org> skribis:
> Most things seem to work fine, but noticed an oddity with guix shell:
>
> vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --check --development guix guix git less
>
> guix shell: checking the environment variables visible from shell
> '/bin/bash'...
> guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell
[...]
> vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --development guix guix git less
>
> vagrant <at> vagranttdgxbookworm:~$ echo $PKG_CONFIG_PATH
> /gnu/store/9vk59alg27y0cp1za91nfdjiy718cn1f-profile/lib/pkgconfig
Notice that it doesn’t complain about any of the other environment
variables (there are 10 of them according to ‘guix shell -D guix
--search-paths|wc -l’).
If you look at ‘child-shell-environment’ in (guix scripts environment),
it runs this in the child shell:
env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit
If the shell prints non-newline-terminated stuff before the output of
‘env’, the first line of ‘env’ would be swallowed by the parser below.
Could you run:
strace -o log -s 500 guix shell --check -D guix
to see exactly what ‘guix shell’ reads?
If there’s nothing obvious, you know the story: we can always add ‘pk’
calls in ‘child-shell-environment’. :-)
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 30 Oct 2021 06:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2021-10-29, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>
>> Most things seem to work fine, but noticed an oddity with guix shell:
>>
>> vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --check --development guix guix git less
>>
>> guix shell: checking the environment variables visible from shell
>> '/bin/bash'...
>> guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell
>
> [...]
>
>> vagrant <at> vagranttdgxbookworm:~$ guix shell --pure --development guix guix git less
>>
>> vagrant <at> vagranttdgxbookworm:~$ echo $PKG_CONFIG_PATH
>> /gnu/store/9vk59alg27y0cp1za91nfdjiy718cn1f-profile/lib/pkgconfig
>
> Notice that it doesn’t complain about any of the other environment
> variables (there are 10 of them according to ‘guix shell -D guix
> --search-paths|wc -l’).
>
> If you look at ‘child-shell-environment’ in (guix scripts environment),
> it runs this in the child shell:
>
> env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit
>
> If the shell prints non-newline-terminated stuff before the output of
> ‘env’, the first line of ‘env’ would be swallowed by the parser below.
>
> Could you run:
>
> strace -o log -s 500 guix shell --check -D guix
>
> to see exactly what ‘guix shell’ reads?
That showed nothing obvious to me; the log it spits out is about 3MB
(~320k compressed with zstd) I could attach if it is useful...
I did notice SHELL=/bin/bash, and tried an experiment:
$ SHELL=/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash guix shell --check -D guix
guix shell: checking the environment variables visible from shell
'/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash'...
guix shell: All is good! The shell gets correct environment variables.
So, somehow the value of SHELL and/or the user's default shell is
triggering the issue?
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 30 Oct 2021 14:22:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Howdy!
Vagrant Cascadian <vagrant <at> debian.org> skribis:
> On 2021-10-29, Ludovic Courtès wrote:
[...]
>> If you look at ‘child-shell-environment’ in (guix scripts environment),
>> it runs this in the child shell:
>>
>> env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit
>>
>> If the shell prints non-newline-terminated stuff before the output of
>> ‘env’, the first line of ‘env’ would be swallowed by the parser below.
>>
>> Could you run:
>>
>> strace -o log -s 500 guix shell --check -D guix
>>
>> to see exactly what ‘guix shell’ reads?
>
> That showed nothing obvious to me; the log it spits out is about 3MB
> (~320k compressed with zstd) I could attach if it is useful...
>
> I did notice SHELL=/bin/bash, and tried an experiment:
>
> $ SHELL=/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash guix shell --check -D guix
> guix shell: checking the environment variables visible from shell
> '/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash'...
> guix shell: All is good! The shell gets correct environment variables.
>
> So, somehow the value of SHELL and/or the user's default shell is
> triggering the issue?
Yes, ‘--check’ runs $SHELL.
To make sure, could you try with the attached patch to see exactly which
variables ‘guix shell’ “sees”, and whether it drops a line it shouldn’t
drop?
TIA,
Ludo’.
[Message part 2 (text/x-patch, inline)]
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index cca0ad991b..7f3d3b9db8 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -452,10 +452,10 @@ (define lines
;; but it also truncates values anyway, so don't try to support it.
(let ((index (string-index line #\=)))
(if index
- (vhash-cons (string-take line index)
+ (vhash-cons (pk 'variable line (string-take line index))
(string-drop line (+ 1 index))
table)
- table)))
+ (pk 'dropped line table))))
vlist-null
lines))
Added tag(s) moreinfo.
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 15 Nov 2021 14:44:01 GMT)
Full text and
rfc822 format available.
Merged 51466 53355.
Request was from
Chris Marusich <cmmarusich <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 02 Feb 2022 07:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Wed, 02 Feb 2022 07:50:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I also observed this bug and reported it as 53355. I tried to search
for bugs, but I didn't find this bug report until Ludo mentioned it. I
think it's probably the same bug, so I've merged them.
Ludovic Courtès <ludo <at> gnu.org> writes:
> It looks like the shell-check machinery is misdiagnosing things, as
> Vagrant reported in <https://issues.guix.gnu.org/51466> (is this on
> Debian too?).
Yes, it's also Debian. Debian Bullseye. I've also verified that
similar behavior occurs on Fedora, although the problematic env vars are
different. I tried fiddling with SHELL like Vagrant did, but I couldn't
make the error go away like he did. Maybe I did something differently.
> Could you try the debugging tricks I proposed there?
Sure thing! Thank you for taking the time to make the patch, even
though it was simple. Here is the result on my Debian Bullseye ppc64el
system:
--8<---------------cut here---------------start------------->8---
[0] [env] marusich <at> suzaku:~/guix-master
$ ./pre-inst-env guix shell --check --pure --development guix
guix shell: checking the environment variables visible from shell '/bin/sh'...
;;; (dropped "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" #<vlist ()>)
;;; (variable "$ LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ LIBRARY_PATH")
;;; (variable "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "C_INCLUDE_PATH")
;;; (variable "USER=marusich" "USER")
;;; (variable "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" "GUIX_LOCPATH")
;;; (variable "HOME=/home/marusich" "HOME")
;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH")
;;; (variable "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "CPLUS_INCLUDE_PATH")
;;; (variable "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" "INFOPATH")
;;; (variable "LOGNAME=marusich" "LOGNAME")
;;; (variable "PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig" "PKG_CONFIG_PATH")
;;; (variable "TERM=screen.xterm-256color" "TERM")
;;; (variable "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal" "ACLOCAL_PATH")
;;; (variable "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin" "PATH")
;;; (variable "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" "GUIX_ENVIRONMENT")
;;; (variable "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_PATH")
;;; (variable "PWD=/home/marusich/guix-master" "PWD")
guix shell: warning: variable 'LIBRARY_PATH' is missing from shell environment
hint: One or more environment variables have a different value in the shell than
the one we set. This means that you may find yourself running code in an
environment different from the one you asked Guix to prepare.
This usually indicates that your shell startup files are unexpectedly
modifying those environment variables. For example, if you are using Bash,
make sure that environment variables are set or modified in
`~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash
startup files, run:
info "(bash) Bash Startup Files"
Alternatively, you can avoid the problem by passing the `--container' or
`-C' option. That will give you a fully isolated environment running in a
"container", immune to the issue described above.
[1] [env] marusich <at> suzaku:~/guix-master
$
--8<---------------cut here---------------end--------------->8---
The presence of the "$" in front of LIBRARY_PATH seems suspicious:
;;; (variable "$ LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ LIBRARY_PATH")
I'm not sure why the "$" is being added. I tried various things to
remove it. I tried explicitly setting PS1 to an empty string in my
~/.bashrc. I also tried setting it explicitly to an empty string in
/etc/profile. Maybe if we can figure out where that "$ " prefix is
coming from, we can resolve this issue?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 08 Feb 2022 09:27:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Chris,
Thanks for testing!
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> The presence of the "$" in front of LIBRARY_PATH seems suspicious:
>
> ;;; (variable "$ LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ LIBRARY_PATH")
>
> I'm not sure why the "$" is being added. I tried various things to
> remove it. I tried explicitly setting PS1 to an empty string in my
> ~/.bashrc. I also tried setting it explicitly to an empty string in
> /etc/profile. Maybe if we can figure out where that "$ " prefix is
> coming from, we can resolve this issue?
How about this:
[Message part 2 (text/x-patch, inline)]
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index ec071402f4..ac2c79ab65 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -420,7 +420,7 @@ (define script
;; Script to obtain the list of environment variable values. On a POSIX
;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
;; 'set' truncates values and prints them in a different format.)
- "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+ "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
(define lines
(match (primitive-fork)
[Message part 3 (text/plain, inline)]
?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 13 Feb 2022 23:18:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Ludovic Courtès <ludo <at> gnu.org> writes:
> How about this:
>
> diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
> index ec071402f4..ac2c79ab65 100644
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -420,7 +420,7 @@ (define script
> ;; Script to obtain the list of environment variable values. On a POSIX
> ;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
> ;; 'set' truncates values and prints them in a different format.)
> - "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
> + "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
>
> (define lines
> (match (primitive-fork)
Unfortunately, this doesn't quite work. I tried this patch:
--8<---------------cut here---------------start------------->8---
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 510cee727f..4399a5dd04 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -420,7 +420,7 @@ (define script
;; Script to obtain the list of environment variable values. On a POSIX
;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
;; 'set' truncates values and prints them in a different format.)
- "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+ "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
(define lines
(match (primitive-fork)
@@ -440,7 +440,7 @@ (define lines
(result (begin
(display script port)
(let loop ((lines '()))
- (match (read-line port)
+ (match (pk 'read-line (read-line port))
((? eof-object?) (reverse lines))
("GUIX-CHECK-DONE\r"
(display "done\n" port)
@@ -458,10 +458,10 @@ (define lines
;; but it also truncates values anyway, so don't try to support it.
(let ((index (string-index line #\=)))
(if index
- (vhash-cons (string-take line index)
+ (vhash-cons (pk 'variable line (string-take line index))
(string-drop line (+ 1 index))
table)
- table)))
+ (pk 'dropped line table))))
vlist-null
lines))
--8<---------------cut here---------------end--------------->8---
Here is the output:
--8<---------------cut here---------------start------------->8---
[0] [env] marusich <at> suzaku:~/guix-master
$ ./pre-inst-env guix shell --check --pure --development guix
guix shell: checking the environment variables visible from shell '/bin/bash'...
;;; (read-line "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\r")
;;; (read-line "\x1b[?2004h[0] [env] marusich <at> suzaku:~/guix-master\r\r")
;;; (read-line "$ PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\r")
;;; (read-line "\x1b[?2004l\rPKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig\r")
;;; (read-line "PWD=/home/marusich/guix-master\r")
;;; (read-line "LOGNAME=marusich\r")
;;; (read-line "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0\r")
;;; (read-line "HOME=/home/marusich\r")
;;; (read-line "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:\r")
;;; (read-line "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0\r")
;;; (read-line "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info\r")
;;; (read-line "TERM=screen.xterm-256color\r")
;;; (read-line "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include\r")
;;; (read-line "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal\r")
;;; (read-line "USER=marusich\r")
;;; (read-line "LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib\r")
;;; (read-line "SHLVL=1\r")
;;; (read-line "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale\r")
;;; (read-line "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile\r")
;;; (read-line "PS1=\r")
;;; (read-line "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin\r")
;;; (read-line "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include\r")
;;; (read-line "_=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin/env\r")
;;; (read-line "GUIX-CHECK-DONE\r")
;;; (variable "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" "PS1")
;;; (dropped "\x1b[?2004h[0] [env] marusich <at> suzaku:~/guix-master\r" #<vhash 2b482ca0 1 pairs>)
;;; (variable "$ PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" "$ PS1")
;;; (variable "\x1b[?2004l\rPKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig" "\x1b[?2004l\rPKG_CONFIG_PATH")
;;; (variable "PWD=/home/marusich/guix-master" "PWD")
;;; (variable "LOGNAME=marusich" "LOGNAME")
;;; (variable "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_PATH")
;;; (variable "HOME=/home/marusich" "HOME")
;;; (variable "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:" "LS_COLORS")
;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH")
;;; (variable "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" "INFOPATH")
;;; (variable "TERM=screen.xterm-256color" "TERM")
;;; (variable "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "CPLUS_INCLUDE_PATH")
;;; (variable "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal" "ACLOCAL_PATH")
;;; (variable "USER=marusich" "USER")
;;; (variable "LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "LIBRARY_PATH")
;;; (variable "SHLVL=1" "SHLVL")
;;; (variable "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" "GUIX_LOCPATH")
;;; (variable "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" "GUIX_ENVIRONMENT")
;;; (variable "PS1=" "PS1")
;;; (variable "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin" "PATH")
;;; (variable "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "C_INCLUDE_PATH")
;;; (variable "_=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin/env" "_")
guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment
hint: One or more environment variables have a different value in the shell than
the one we set. This means that you may find yourself running code in an
environment different from the one you asked Guix to prepare.
This usually indicates that your shell startup files are unexpectedly
modifying those environment variables. For example, if you are using Bash,
make sure that environment variables are set or modified in
`~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash
startup files, run:
info "(bash) Bash Startup Files"
Alternatively, you can avoid the problem by passing the `--container' or
`-C' option. That will give you a fully isolated environment running in a
"container", immune to the issue described above.
[1] [env] marusich <at> suzaku:~/guix-master
$
--8<---------------cut here---------------end--------------->8---
Most of the interesting stuff happened in the first few lines:
--8<---------------cut here---------------start------------->8---
;;; (read-line "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\r")
;;; (read-line "\x1b[?2004h[0] [env] marusich <at> suzaku:~/guix-master\r\r")
;;; (read-line "$ PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\r")
;;; (read-line "\x1b[?2004l\rPKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig\r")
--8<---------------cut here---------------end--------------->8---
As you can see, nothing good is happening when the code parses this
later on:
--8<---------------cut here---------------start------------->8---
;;; (variable "PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" "PS1")
;;; (dropped "\x1b[?2004h[0] [env] marusich <at> suzaku:~/guix-master\r" #<vhash 2b482ca0 1 pairs>)
;;; (variable "$ PS1=; env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" "$ PS1")
;;; (variable "\x1b[?2004l\rPKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig" "\x1b[?2004l\rPKG_CONFIG_PATH")
--8<---------------cut here---------------end--------------->8---
Although I'm sure you see it, for clarity I will explain why the above
is bad: The first variable was actually just the entire script being
echoed back; it is not actually an environment variable. The second
variable "$ PS1" is also not really an environment variable. And the
variable "\x1b[?2004l\rPKG_CONFIG_PATH", again, appears to contain
garbage at the start, probably from my PS1 value.
Basically, I think we can work around these issues if we just read and
discard all that junk at the start. I wasn't able to figure out a
graceful way to force that to happen, but I did find that simply
printing a few lines at the start of the script was good enough to work
around the issue on my computer. Here's my proposed patch, with
debugging statements included:
--8<---------------cut here---------------start------------->8---
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 510cee727f..35669b39cd 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -420,7 +420,8 @@ (define script
;; Script to obtain the list of environment variable values. On a POSIX
;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
;; 'set' truncates values and prints them in a different format.)
- "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+ "PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
+env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
(define lines
(match (primitive-fork)
@@ -439,8 +440,10 @@ (define lines
(let* ((port (fdopen controller "r+l"))
(result (begin
(display script port)
+ (while (not (string=? "GUIX_FLUSH_3\r"
+ (read-line port))))
(let loop ((lines '()))
- (match (read-line port)
+ (match (pk 'read-line (read-line port))
((? eof-object?) (reverse lines))
("GUIX-CHECK-DONE\r"
(display "done\n" port)
@@ -458,10 +461,10 @@ (define lines
;; but it also truncates values anyway, so don't try to support it.
(let ((index (string-index line #\=)))
(if index
- (vhash-cons (string-take line index)
+ (vhash-cons (pk 'variable line (string-take line index))
(string-drop line (+ 1 index))
table)
- table)))
+ (pk 'dropped line table))))
vlist-null
lines))
--8<---------------cut here---------------end--------------->8---
And here's the output:
--8<---------------cut here---------------start------------->8---
[0] [env] marusich <at> suzaku:~/guix-master
$ ./pre-inst-env guix shell --check --pure --development guix
guix shell: checking the environment variables visible from shell '/bin/bash'...
;;; (read-line "PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig\r")
;;; (read-line "PWD=/home/marusich/guix-master\r")
;;; (read-line "LOGNAME=marusich\r")
;;; (read-line "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0\r")
;;; (read-line "HOME=/home/marusich\r")
;;; (read-line "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:\r")
;;; (read-line "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0\r")
;;; (read-line "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info\r")
;;; (read-line "TERM=screen.xterm-256color\r")
;;; (read-line "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include\r")
;;; (read-line "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal\r")
;;; (read-line "USER=marusich\r")
;;; (read-line "LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib\r")
;;; (read-line "SHLVL=1\r")
;;; (read-line "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale\r")
;;; (read-line "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile\r")
;;; (read-line "PS1=\r")
;;; (read-line "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin\r")
;;; (read-line "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include\r")
;;; (read-line "_=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin/env\r")
;;; (read-line "GUIX-CHECK-DONE\r")
;;; (variable "PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig" "PKG_CONFIG_PATH")
;;; (variable "PWD=/home/marusich/guix-master" "PWD")
;;; (variable "LOGNAME=marusich" "LOGNAME")
;;; (variable "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_PATH")
;;; (variable "HOME=/home/marusich" "HOME")
;;; (variable "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:" "LS_COLORS")
;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH")
;;; (variable "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" "INFOPATH")
;;; (variable "TERM=screen.xterm-256color" "TERM")
;;; (variable "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "CPLUS_INCLUDE_PATH")
;;; (variable "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal" "ACLOCAL_PATH")
;;; (variable "USER=marusich" "USER")
;;; (variable "LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "LIBRARY_PATH")
;;; (variable "SHLVL=1" "SHLVL")
;;; (variable "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" "GUIX_LOCPATH")
;;; (variable "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" "GUIX_ENVIRONMENT")
;;; (variable "PS1=" "PS1")
;;; (variable "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin" "PATH")
;;; (variable "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "C_INCLUDE_PATH")
;;; (variable "_=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin/env" "_")
guix shell: All is good! The shell gets correct environment variables.
[0] [env] marusich <at> suzaku:~/guix-master
$
--8<---------------cut here---------------end--------------->8---
As you can see, it seems to be working correctly here.
Here's a version of the patch that is ready for committing, with the
debug statements removed and comments added:
[0001-environment-Prevent-PS1-from-clobbering-output-in-ch.patch (text/x-patch, inline)]
From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich <at> gmail.com>
Date: Sun, 13 Feb 2022 14:15:14 -0800
Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
Fixes: <https://issues.guix.gnu.org/51466>.
* guix/scripts/environment.scm (child-shell-environment): In the script
executed the child shell, set PS1 to an empty value and then echo three
sentinel lines to try to "flush" the original PS1 value before printing the
environment variables. In the parent process, read and discard all lines up
to and including the last sentinel line. After that, read the remaining lines
as usual.
---
guix/scripts/environment.scm | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index ec071402f4..0b137467f9 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -2,6 +2,7 @@
;;; Copyright © 2014, 2015, 2018 David Thompson <davet <at> gnu.org>
;;; Copyright © 2015-2022 Ludovic Courtès <ludo <at> gnu.org>
;;; Copyright © 2018 Mike Gerwitz <mtg <at> gnu.org>
+;;; Copyright © 2022 Chris Marusich <cmmarusich <at> gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -420,7 +421,16 @@ by running 'set' in the shell."
;; Script to obtain the list of environment variable values. On a POSIX
;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
;; 'set' truncates values and prints them in a different format.)
- "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+ ;;
+ ;; Why print "GUIX_FLUSH" a few times? We are trying to "flush" the
+ ;; original PS1 value to the port so we can read it (and discard it)
+ ;; before we start reading the environment variables from the port. If we
+ ;; don't do this, the original PS1 value can sometimes get interleaved
+ ;; into the output, which interferes with our parsing logic. It's a hack,
+ ;; but in practice it seems to do the job. If you know of a more graceful
+ ;; solution, please implement it! See: https://issues.guix.gnu.org/51466
+ "PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
+env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
(define lines
(match (primitive-fork)
@@ -439,6 +449,12 @@ by running 'set' in the shell."
(let* ((port (fdopen controller "r+l"))
(result (begin
(display script port)
+ ;; Ignore all lines up to and including the final
+ ;; "GUIX_FLUSH" line.
+ (while (not (string=? "GUIX_FLUSH_3\r"
+ (read-line port))))
+ ;; Now (hopefully) the original PS1 value will not be
+ ;; interleaved in the remaining lines.
(let loop ((lines '()))
(match (read-line port)
((? eof-object?) (reverse lines))
base-commit: d65979c46c99dc36324ca94aa9650b9de37f22de
--
2.26.3
[Message part 3 (text/plain, inline)]
And here's its output:
--8<---------------cut here---------------start------------->8---
[0] [env] marusich <at> suzaku:~/guix-master
$ ./pre-inst-env guix shell --check --pure --development guix
guix shell: checking the environment variables visible from shell '/bin/bash'...
guix shell: All is good! The shell gets correct environment variables.
[0] [env] marusich <at> suzaku:~/guix-master
$
--8<---------------cut here---------------end--------------->8---
WDYT?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 14 Feb 2022 09:49:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
Thanks for debugging this!
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich <at> gmail.com>
> Date: Sun, 13 Feb 2022 14:15:14 -0800
> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>
> Fixes: <https://issues.guix.gnu.org/51466>.
>
> * guix/scripts/environment.scm (child-shell-environment): In the script
> executed the child shell, set PS1 to an empty value and then echo three
> sentinel lines to try to "flush" the original PS1 value before printing the
> environment variables. In the parent process, read and discard all lines up
> to and including the last sentinel line. After that, read the remaining lines
> as usual.
[...]
> + ;; Why print "GUIX_FLUSH" a few times? We are trying to "flush" the
> + ;; original PS1 value to the port so we can read it (and discard it)
> + ;; before we start reading the environment variables from the port. If we
> + ;; don't do this, the original PS1 value can sometimes get interleaved
> + ;; into the output, which interferes with our parsing logic. It's a hack,
> + ;; but in practice it seems to do the job. If you know of a more graceful
> + ;; solution, please implement it! See: https://issues.guix.gnu.org/51466
> + "PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
> +env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
So you confirm that a single “echo” is not enough, right?
Perhaps we should unroll the ‘for’ loop for portability, to be on the
safe side. Initially I tested with Bash, Zsh, and Fish:
https://issues.guix.gnu.org/51285#0-lineno49
I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
‘for’.
I realized that setting PS1 could interfere with the logic below that
checks for PS1. And since it doesn’t seem to help, perhaps we can
remove “PS1=;”?
Thoughts?
Sorry to answer with yet more questions!
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 08 Mar 2022 19:08:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
Did you have a chance to look into it?
https://issues.guix.gnu.org/53355
TIA. :-)
Ludo’.
Ludovic Courtès <ludo <at> gnu.org> skribis:
> Hi Chris,
>
> Thanks for debugging this!
>
> Chris Marusich <cmmarusich <at> gmail.com> skribis:
>
>> From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001
>> From: Chris Marusich <cmmarusich <at> gmail.com>
>> Date: Sun, 13 Feb 2022 14:15:14 -0800
>> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>>
>> Fixes: <https://issues.guix.gnu.org/51466>.
>>
>> * guix/scripts/environment.scm (child-shell-environment): In the script
>> executed the child shell, set PS1 to an empty value and then echo three
>> sentinel lines to try to "flush" the original PS1 value before printing the
>> environment variables. In the parent process, read and discard all lines up
>> to and including the last sentinel line. After that, read the remaining lines
>> as usual.
>
> [...]
>
>> + ;; Why print "GUIX_FLUSH" a few times? We are trying to "flush" the
>> + ;; original PS1 value to the port so we can read it (and discard it)
>> + ;; before we start reading the environment variables from the port. If we
>> + ;; don't do this, the original PS1 value can sometimes get interleaved
>> + ;; into the output, which interferes with our parsing logic. It's a hack,
>> + ;; but in practice it seems to do the job. If you know of a more graceful
>> + ;; solution, please implement it! See: https://issues.guix.gnu.org/51466
>> + "PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
>> +env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
>
> So you confirm that a single “echo” is not enough, right?
>
> Perhaps we should unroll the ‘for’ loop for portability, to be on the
> safe side. Initially I tested with Bash, Zsh, and Fish:
>
> https://issues.guix.gnu.org/51285#0-lineno49
>
> I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
> ‘for’.
>
> I realized that setting PS1 could interfere with the logic below that
> checks for PS1. And since it doesn’t seem to help, perhaps we can
> remove “PS1=;”?
>
> Thoughts?
>
> Sorry to answer with yet more questions!
>
> Thanks,
> Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 27 Mar 2022 17:00:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 51466 <at> debbugs.gnu.org (full text, mbox):
The PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; hack appears to work
for me but here is my alternate version. I don't think we have to hack our way
around the shell if we can dump the environment variables somewhere else.
I added a test but the potato machine I'm running that on is taking a very
long time to run the whole thing (I did run the test in isolation with and
without my patch), would you mind checking it works for you (and can we use
Bash there?).
Note I'm still not sure why we have env || /usr/bin/env (in case we mess with
the PATH I guess?) so I've kept it.
Comments welcome, I haven't coded much in Guile/Scheme.
Kevin Boulain (1):
environment: properly parse environment variables during --check
guix/scripts/environment.scm | 65 +++++++++++++++++++++++-------------
tests/guix-environment.sh | 16 +++++++++
2 files changed, 57 insertions(+), 24 deletions(-)
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 27 Mar 2022 17:00:03 GMT)
Full text and
rfc822 format available.
Message #39 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Should solve https://issues.guix.gnu.org/51466.
This redirects the env command's output to a temporary file so that
there is no way to get it mixed with the shell's output (like PS1).
Additionnally:
- Remove GUIX-CHECK-DONE and read: I don't think there is a need for
them as discarding the output until the shell exits is enough to
guarantee the environment has been dumped. Sadly, Linux doesn't
report EOF but EIO when the shell exits and the pty gets closed hence
the catch/throw.
- Don't try to parse environment variables by splitting them on \n,
instead use env's -0 option to separate environment variables with
\0. This prevent incorrect parsing of some multi-line variables
(e.g.: f() { echo "hello"; }; declare -fx f) but isn't standard.
* guix/scripts/environment.scm (child-shell-environment): make
environment variables parsing more robust.
* tests/guix-environment.sh: add a simple test that was reliably
failing on my machine.
---
guix/scripts/environment.scm | 65 +++++++++++++++++++++++-------------
tests/guix-environment.sh | 16 +++++++++
2 files changed, 57 insertions(+), 24 deletions(-)
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index ec071402f4..4ff13c6bde 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -48,7 +48,7 @@ (define-module (guix scripts environment)
#:autoload (gnu packages bash) (bash)
#:autoload (gnu packages bootstrap) (bootstrap-executable %bootstrap-guile)
#:use-module (ice-9 match)
- #:autoload (ice-9 rdelim) (read-line)
+ #:autoload (ice-9 rdelim) (read-delimited read-line)
#:use-module (ice-9 vlist)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-11)
@@ -413,16 +413,22 @@ (define (child-shell-environment shell profile manifest)
"Create a child process, load PROFILE and MANIFEST, and then run SHELL in
interactive mode in it. Return a name/value vhash for all the variables shown
by running 'set' in the shell."
- (define-values (controller inferior)
- (openpty))
-
- (define script
- ;; Script to obtain the list of environment variable values. On a POSIX
- ;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
- ;; 'set' truncates values and prints them in a different format.)
- "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
-
(define lines
+ (let* ((environment-port (mkstemp "/tmp/guix-enviroment-XXXXXX"))
+ (environment-file (port-filename environment-port))
+ ;; Script to obtain the list of environment variable values. On a
+ ;; POSIX shell we can rely on 'set', but on fish we have to use 'env'
+ ;; (fish's 'set' truncates values and prints them in a different
+ ;; format.)
+ ;; We rely on env --null to mark the end of environment variables.
+ ;; This is expected to be safe because POSIX defines environment
+ ;; variables end with '\0' (but does't document the --null option).
+ ;; Some shells, like Bash, allow to export functions, which will span
+ ;; multiple lines and break any trivial parsing relying on '\n'.
+ (script (format #f "env --null > ~a || /usr/bin/env --null > ~a; exit\n"
+ environment-file environment-file)))
+
+ (let-values (((controller inferior) (openpty)))
(match (primitive-fork)
(0
(catch #t
@@ -436,26 +442,37 @@ (define lines
(primitive-exit 127))))
(pid
(close-fdes inferior)
- (let* ((port (fdopen controller "r+l"))
- (result (begin
+ (let ((port (fdopen controller "r+l")))
(display script port)
+ (catch 'system-error
+ (lambda ()
+ ;; We aren't interested in the output of the shell itself,
+ ;; drop it.
+ (while (not (eof-object? (read-line port)))))
+ (lambda args
+ (let ((errno (system-error-errno args)))
+ (cond
+ ((= errno EIO)
+ ;; On Linux, a read won't return EOF but will fail with EIO
+ ;; when the device is closed:
+ ;; https://bugs.python.org/issue5380#msg252544
+ #t)
+ (#t
+ (apply throw args))))))
+ (close-port port)
+ (waitpid pid)))))
+
+ (let ((result (begin
(let loop ((lines '()))
- (match (read-line port)
+ (match (read-delimited "\0" environment-port)
((? eof-object?) (reverse lines))
- ("GUIX-CHECK-DONE\r"
- (display "done\n" port)
- (reverse lines))
(line
- ;; Drop the '\r' from LINE.
- (loop (cons (string-drop-right line 1)
- lines))))))))
- (close-port port)
- (waitpid pid)
- result))))
+ (loop (cons line lines))))))))
+ (close-port environment-port)
+ (delete-file environment-file)
+ result)))
(fold (lambda (line table)
- ;; Note: 'set' in fish outputs "NAME VALUE" instead of "NAME=VALUE"
- ;; but it also truncates values anyway, so don't try to support it.
(let ((index (string-index line #\=)))
(if index
(vhash-cons (string-take line index)
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index 95fe95b437..114bf9fbf5 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -258,3 +258,19 @@ then
guix gc --references "$profile" | grep "$dep"
done
fi
+
+# https://issues.guix.gnu.org/51466
+# guix environment --check was sometimes unable to find PKG_CONFIG_PATH
+# because the env command is sent before the prompt gets printed and there
+# is no proper way to deinterleave streams:
+# ;;; (read-line "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\r")
+# ;;; (read-line "bash-5.1$ PKG_CONFIG_PATH=/gnu/store/0ysl5arpf0yf3pn15afr450k676lgdq3-profile/lib/pkgconfig\r")
+# ;;; (read-line "PWD=/home/ether/source/guix\r")
+bash=$(mktemp)
+cat > "$bash" << 'BASH'
+#!/usr/bin/env bash
+exec bash --noprofile --rcfile /dev/null "$@"
+BASH
+chmod +x "$bash"
+env SHELL=$bash guix environment --check --pure guix -- env
+rm -f "$bash"
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Fri, 20 May 2022 21:38:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
A friendly ping. :-)
Ludo’.
Ludovic Courtès <ludo <at> gnu.org> skribis:
> Hi Chris,
>
> Did you have a chance to look into it?
>
> https://issues.guix.gnu.org/53355
>
> TIA. :-)
>
> Ludo’.
>
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> Hi Chris,
>>
>> Thanks for debugging this!
>>
>> Chris Marusich <cmmarusich <at> gmail.com> skribis:
>>
>>> From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001
>>> From: Chris Marusich <cmmarusich <at> gmail.com>
>>> Date: Sun, 13 Feb 2022 14:15:14 -0800
>>> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>>>
>>> Fixes: <https://issues.guix.gnu.org/51466>.
>>>
>>> * guix/scripts/environment.scm (child-shell-environment): In the script
>>> executed the child shell, set PS1 to an empty value and then echo three
>>> sentinel lines to try to "flush" the original PS1 value before printing the
>>> environment variables. In the parent process, read and discard all lines up
>>> to and including the last sentinel line. After that, read the remaining lines
>>> as usual.
>>
>> [...]
>>
>>> + ;; Why print "GUIX_FLUSH" a few times? We are trying to "flush" the
>>> + ;; original PS1 value to the port so we can read it (and discard it)
>>> + ;; before we start reading the environment variables from the port. If we
>>> + ;; don't do this, the original PS1 value can sometimes get interleaved
>>> + ;; into the output, which interferes with our parsing logic. It's a hack,
>>> + ;; but in practice it seems to do the job. If you know of a more graceful
>>> + ;; solution, please implement it! See: https://issues.guix.gnu.org/51466
>>> + "PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
>>> +env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
>>
>> So you confirm that a single “echo” is not enough, right?
>>
>> Perhaps we should unroll the ‘for’ loop for portability, to be on the
>> safe side. Initially I tested with Bash, Zsh, and Fish:
>>
>> https://issues.guix.gnu.org/51285#0-lineno49
>>
>> I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
>> ‘for’.
>>
>> I realized that setting PS1 could interfere with the logic below that
>> checks for PS1. And since it doesn’t seem to help, perhaps we can
>> remove “PS1=;”?
>>
>> Thoughts?
>>
>> Sorry to answer with yet more questions!
>>
>> Thanks,
>> Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 24 May 2022 04:43:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Ludovic Courtès <ludo <at> gnu.org> writes:
> So you confirm that a single “echo” is not enough, right?
I didn't test one specifically. It might work with just one, but it did
work with three. If we want to proceed with the "echo" approach, let me
know and I'll test just one echo to see if that is reliable enough.
> Perhaps we should unroll the ‘for’ loop for portability, to be on the
> safe side. Initially I tested with Bash, Zsh, and Fish:
>
> https://issues.guix.gnu.org/51285#0-lineno49
>
> I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
> ‘for’.
I see. Yes, I'll do that if we decide to go with the echo-based
approach.
> I realized that setting PS1 could interfere with the logic below that
> checks for PS1. And since it doesn’t seem to help, perhaps we can
> remove “PS1=;”?
I recall that I tried removing PS1, and I still had trouble. I believe
it was because even if we unset PS1 as the very first command we do, the
original prompt is still printed. Foreign distros usually set PS1 to
something, and whatever that is will be printed before we have a chance
to input any commands. It's hard to avoid that in general.
> Thoughts?
One alternative method I tried successfully in a variety of shells was
to use shell redirection (see attached). I like this approach.
However, this will only work in shells that support redirection. I
recall testing with bash, ash (busybox's shell), dash, zsh, fish, ksh,
and csh. I recall that only csh failed, since it doesn't support
redirection.
I personally like the attached patch better than what I proposed
earlier. The earlier patch just echoes a few times. Presumably, it
only works because the PS1 prompt is likely (but not guaranteed) to be
emitted before the last of the echo commands finishes printing. I'd
rather just control the desired output and ignore PS1 entirely, and that
is what the attached patch accomplishes using FDs. However, if support
for shells without redirection is a requirement, then maybe the original
hack (echo a few times) is OK, or perhaps we need something else.
How would you like to proceed? Is it OK to rely on shell redirection?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[0001-environment-Prevent-PS1-from-clobbering-output-in-ch.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 13 Jun 2022 10:04:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> One alternative method I tried successfully in a variety of shells was
> to use shell redirection (see attached). I like this approach.
> However, this will only work in shells that support redirection. I
> recall testing with bash, ash (busybox's shell), dash, zsh, fish, ksh,
> and csh. I recall that only csh failed, since it doesn't support
> redirection.
That’s a good success list in my view; not being a POSIX shell, (t)csh
was already excluded from the list in the original submission I think:
<https://issues.guix.gnu.org/51285>.
> I personally like the attached patch better than what I proposed
> earlier. The earlier patch just echoes a few times. Presumably, it
> only works because the PS1 prompt is likely (but not guaranteed) to be
> emitted before the last of the echo commands finishes printing. I'd
> rather just control the desired output and ignore PS1 entirely, and that
> is what the attached patch accomplishes using FDs. However, if support
> for shells without redirection is a requirement, then maybe the original
> hack (echo a few times) is OK, or perhaps we need something else.
>
> How would you like to proceed? Is it OK to rely on shell redirection?
Yeah, I think so. This new approach looks more robust.
> From 9a1cef589abf01b61e22656f44c76441f4c50ffd Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich <at> gmail.com>
> Date: Fri, 11 Mar 2022 00:20:12 -0800
> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>
> Fixes: <https://issues.guix.gnu.org/51466>.
>
> * guix/scripts/environment.scm (child-shell-environment) [shell-pipe]
> [shell-pipe-in, shell-pipe-out]: New local variables.
> [script]: Redirect the stdout of each command to the file descriptor of the
> shell-pipe-out port.
> [lines]: In the child, close shell-pipe-in before starting the shell. In the
> parent, close shell-pipe-out before sending the script to the shell. Read
> lines from shell-pipe-in, not port, so that the shell's PS1 prompt cannot
> clobber the lines. Close shell-pipe-in just before waiting on the child.
LGTM, please push!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 19 Jun 2022 20:42:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Thank you for the review!
Ludovic Courtès <ludo <at> gnu.org> 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
[0001-environment-Don-t-assume-that-lines-have-a-trailing-.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 20 Jun 2022 07:35:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi,
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> 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.
Weird, not sure what could have changed.
> Unless you have more feedback, I'll go ahead and push both patches to
> master in a few days.
Great, thank you!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 20 Jun 2022 10:13:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 51466 <at> debbugs.gnu.org (full text, mbox):
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 <ludo <at> gnu.org> 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 <cmmarusich <at> gmail.com>
> 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
>
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 20 Jun 2022 17:58:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Sorry to reply to myself, but forgot to illustrate.
On +2022-06-20 12:12:10 +0200, bokr <at> bokr.com wrote:
> Hi Chris,
[...]
>
> 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?
>
There are a couple functions without prefixed underscore too,
which invoke some underscore-prefixed ones that look too trusting
of their arguments if you ask me: can someone declare these safe?
I think I can grok quote () ...
(escape single quotes and enclose result in single quotes, trusting bash state)
But what if I want to define my own function quote?? How would I know I was
overriding this? I really don't like my programming space occupied by unknowns :-(
--8<---------------cut here---------------start------------->8---
quote ()
{
local quoted=${1//\'/\'\\\'\'};
printf "'%s'" "$quoted"
}
--8<---------------cut here---------------end--------------->8---
but this one below will take more time than I want to spend on code
I'm not intentionally going to use, and which invites name clashes
in my command name space :-(
--8<---------------cut here---------------start------------->8---
quote_readline ()
{
local quoted;
_quote_readline_by_ref "$1" ret;
printf %s "$ret"
}
--8<---------------cut here---------------end--------------->8---
where the above calls this:
--8<---------------cut here---------------start------------->8---
_quote_readline_by_ref ()
{
if [ -z "$1" ]; then
printf -v $2 %s "$1";
else
if [[ $1 == \'* ]]; then
printf -v $2 %s "${1:1}";
else
if [[ $1 == ~* ]]; then
printf -v $2 ~%q "${1:1}";
else
printf -v $2 %q "$1";
fi;
fi;
fi;
[[ ${!2} == \$* ]] && eval $2=${!2}
}
--8<---------------cut here---------------end--------------->8---
HTH somehow.
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 20 Jun 2022 23:29:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Sorry again, but I found the source:
tl;dr: These functions are defined in
/usr/share/bash-completion/bash_completion
which looks awful kludgey to me, (however clever :)
There is a reference to
http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00155.html
in the header comments for
_quote_readline_by_ref ()
I also found
https://askubuntu.com/questions/571544/bash-tab-completion-bash-unexpected-eof-while-looking-for-matching-bash
My bet is there is at least one bug active now.
Completion is really nice when it works, but IMO they certainly
shouldn't use a name like unadorned ``quote'' in their implementation.
And I think it would be prettier in scheme :)
Lots could be prettier if bash could be extended with scheme.
I'm about out of time to chase this, but I expect to bump into it again ;/
HTH.
--
Regards,
Bengt Richter
On +2022-06-20 19:56:56 +0200, Bengt Richter wrote:
> Sorry to reply to myself, but forgot to illustrate.
>
> On +2022-06-20 12:12:10 +0200, bokr <at> bokr.com wrote:
> > Hi Chris,
> [...]
> >
> > 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?
> >
>
> There are a couple functions without prefixed underscore too,
> which invoke some underscore-prefixed ones that look too trusting
> of their arguments if you ask me: can someone declare these safe?
>
> I think I can grok quote () ...
> (escape single quotes and enclose result in single quotes, trusting bash state)
> But what if I want to define my own function quote?? How would I know I was
> overriding this? I really don't like my programming space occupied by unknowns :-(
>
> --8<---------------cut here---------------start------------->8---
> quote ()
> {
> local quoted=${1//\'/\'\\\'\'};
> printf "'%s'" "$quoted"
> }
> --8<---------------cut here---------------end--------------->8---
>
> but this one below will take more time than I want to spend on code
> I'm not intentionally going to use, and which invites name clashes
> in my command name space :-(
>
> --8<---------------cut here---------------start------------->8---
> quote_readline ()
> {
> local quoted;
> _quote_readline_by_ref "$1" ret;
> printf %s "$ret"
> }
> --8<---------------cut here---------------end--------------->8---
>
> where the above calls this:
>
> --8<---------------cut here---------------start------------->8---
> _quote_readline_by_ref ()
> {
> if [ -z "$1" ]; then
> printf -v $2 %s "$1";
> else
> if [[ $1 == \'* ]]; then
> printf -v $2 %s "${1:1}";
> else
> if [[ $1 == ~* ]]; then
> printf -v $2 ~%q "${1:1}";
> else
> printf -v $2 %q "$1";
> fi;
> fi;
> fi;
> [[ ${!2} == \$* ]] && eval $2=${!2}
> }
> --8<---------------cut here---------------end--------------->8---
>
> HTH somehow.
> --
> Regards,
> Bengt Richter
>
>
>
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 21 Jun 2022 04:05:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hello,
Bengt Richter <bokr <at> bokr.com> writes:
> Lots could be prettier if bash could be extended with scheme.
Today is your lucky day. :-)
$ guix show guile-bash | recsel -p name,synopsis
name: guile-bash
synopsis: Extend Bash using Guile
--
Thanks
Thiago
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 09:09:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo & Everyone,
Chris Marusich <cmmarusich <at> gmail.com> writes:
> Is it OK to rely on shell redirection?
It turns out that it is probably not OK to rely on shell redirection in
this case, after all. For example, "dash does not support multi-digit
file descriptors":
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
Indeed, the patch I proposed earlier to rely on shell redirection caused
a command like
./pre-inst-env env SHELL=/gnu/store/nm0hccsphymxi8c24xmg6ixm9vcf25xb-dash-0.5.11.5/bin/dash guix shell --check --container -D guix
to hang. It hangs because the FD Guile chooses to create and embed in
the script is 19 (on my machine, at least). A redirection like
"env >&19" causes dash to error out, so no environment information gets
sent back to the parent process. The same issue seemed to occur for the
ksh from our oksh package.
To resolve this, I changed the code so that it just writes to a
temporary file. This is simple and more robust. With the attached
patch, I was able to use a command like the one above to verify that
"guix environment --check" works correctly for Guix-built bash, dash,
ksh, fish, zsh, and ash. I also verified that it works for Fedora's
/bin/sh and /bin/bash.
What do you think of this file-based approach? Supporting many
different shells is pretty tricky, but I think this patch does a good
enough job.
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[0001-environment-Prevent-PS1-from-clobbering-output-in-ch.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 09:38:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Chris Marusich schreef op za 25-06-2022 om 02:07 [-0700]:
> It turns out that it is probably not OK to rely on shell redirection
> in
> this case, after all. For example, "dash does not support multi-
> digit
> file descriptors":
>
> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
I consider temporary files to be more fragile -- you have to take care
of file permissions, removing the file afterwards even after an
interrupt with C-c, deleting the temporary file can fail, there might
be an out-of-space error, in case of file system corruption things
might be remounted read-only, some other program could read, write or
delete the file ..., so I think it would be best to just fix the bug in
dash instead.
Greetings,
Maxime.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 16:53:01 GMT)
Full text and
rfc822 format available.
Message #75 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Maxime,
Maxime Devos <maximedevos <at> telenet.be> writes:
> Chris Marusich schreef op za 25-06-2022 om 02:07 [-0700]:
>> It turns out that it is probably not OK to rely on shell redirection
>> in
>> this case, after all. For example, "dash does not support multi-
>> digit
>> file descriptors":
>>
>> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
>
> I consider temporary files to be more fragile -- you have to take care
> of file permissions, removing the file afterwards even after an
> interrupt with C-c, deleting the temporary file can fail, there might
> be an out-of-space error, in case of file system corruption things
> might be remounted read-only, some other program could read, write or
> delete the file ..., so I think it would be best to just fix the bug in
> dash instead.
Yes, I agree those are good reasons to avoid a temporary file if we can.
To that end, do you know if we can somehow force Guile to use a specific
file descriptor for the pipe? In the patch I wrote earlier, which uses
redirection, the problem was that I could not control Guile's choice of
file descriptors. Guile chose file descriptor 19 for one end of the
pipe, and I don't know how to make it use anything else. If we can
arrange for Guile to consistently use file descriptor 7, for example,
then probably it would work in all the shell I've tested.
I wonder if maybe I can just duplicate the file descriptor? I don't
know; if for example Guile reserves all the file descriptors below 10
for other uses, it might be hard.
What do you think? Is there a way to do it?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 17:41:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]:
> Yes, I agree those are good reasons to avoid a temporary file if we
> can.
> To that end, do you know if we can somehow force Guile to use a
> specific
> file descriptor for the pipe? In the patch I wrote earlier, which
> uses
> redirection, the problem was that I could not control Guile's choice
> of
> file descriptors. Guile chose file descriptor 19 for one end of the
> pipe, and I don't know how to make it use anything else. If we can
> arrange for Guile to consistently use file descriptor 7, for example,
> then probably it would work in all the shell I've tested.
>
> I wonder if maybe I can just duplicate the file descriptor? I don't
> know; if for example Guile reserves all the file descriptors below 10
> for other uses, it might be hard.
>
Have a look at ‘(guile)Ports and File Descriptors’. It has lots of
procedures for duplicating and renumbering. That's fragile though, you
might accidentally overwrite an fd that's being used for something
else.
(Normally move->fdes would prevent overwriting things by moving pre-
existing fds out of the way, adjusting ports automatically, but move-
>fdes doesn't know (yet) about the pipe that Guile uses for
finalisation, see maybe:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48563>)
I think it would be best to patch the dash appropriately (though fixing
move->fdes would be nice too).
Greetings,
Maximee.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 20:08:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 51466 <at> debbugs.gnu.org (full text, mbox):
On +2022-06-25 19:40:48 +0200, Maxime Devos wrote:
> Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]:
> > Yes, I agree those are good reasons to avoid a temporary file if we
> > can.
> > To that end, do you know if we can somehow force Guile to use a
> > specific
> > file descriptor for the pipe? In the patch I wrote earlier, which
> > uses
> > redirection, the problem was that I could not control Guile's choice
> > of
> > file descriptors. Guile chose file descriptor 19 for one end of the
> > pipe, and I don't know how to make it use anything else. If we can
> > arrange for Guile to consistently use file descriptor 7, for example,
> > then probably it would work in all the shell I've tested.
> >
> > I wonder if maybe I can just duplicate the file descriptor? I don't
> > know; if for example Guile reserves all the file descriptors below 10
> > for other uses, it might be hard.
> >
>
> Have a look at ‘(guile)Ports and File Descriptors’. It has lots of
> procedures for duplicating and renumbering. That's fragile though, you
> might accidentally overwrite an fd that's being used for something
> else.
>
> (Normally move->fdes would prevent overwriting things by moving pre-
> existing fds out of the way, adjusting ports automatically, but move-
> >fdes doesn't know (yet) about the pipe that Guile uses for
> finalisation, see maybe:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48563>)
>
> I think it would be best to patch the dash appropriately (though fixing
> move->fdes would be nice too).
>
> Greetings,
> Maximee.
Could this help?:
(from man 2 openat (scroll down a fair bit):
-8<---------------cut here---------------start------------->8---
There are two main use cases for O_TMPFILE:
* Improved tmpfile(3) functionality: race-free creation of temporary files that (1) are automatically
deleted when closed; (2) can never be reached via any pathname; (3) are not subject to symlink at‐
tacks; and (4) do not require the caller to devise unique names.
* Creating a file that is initially invisible, which is then populated with data and adjusted to have
appropriate filesystem attributes (fchown(2), fchmod(2), fsetxattr(2), etc.) before being atomi‐
cally linked into the filesystem in a fully formed state (using linkat(2) as described above).
O_TMPFILE requires support by the underlying filesystem; only a subset of Linux filesystems provide
that support. In the initial implementation, support was provided in the ext2, ext3, ext4, UDF,
Minix, and shmem filesystems. Support for other filesystems has subsequently been added as follows:
XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs (Linux 4.9)
--8<---------------cut here---------------end--------------->8---
BTW, IIRC, this can be used to create an invisible file that
can be mmap-ed, and the mmap will persist when you delete
the file. Which then can be used as an anonymous buffer
passed to wayland, along with metadate saying what the buffer
contains, e.g. different kinds of rgb or rgba permutations
and encodings, (or anything, which you can tell wayland just
to keep track of for you.
You need a directory for openat, so probably
XDG_RUNTIME_DIR=/run/user/1000
is suitable if it exists. Worked in my case.
HTH
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sat, 25 Jun 2022 21:05:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
bokr <at> bokr.com schreef op za 25-06-2022 om 22:06 [+0200]:
> BTW, IIRC, this can be used to create an invisible file that
Invisible files don't have file names, so they cannot be put in the
tiny shell script:
> + (format
> + #f "env >~a || /usr/bin/env >~a || set >~a; \
> +echo GUIX-CHECK-DONE >>~a; exit\n"
> + temporary-file temporary-file temporary-file temporary-file))
Also, I just noticed that this tiny shell script isn't quoting
anything, so you'll get in trouble if $TMPDIR (or was it $TEMPDIR,
whatever) contains " or ' or \ or whatever.
So to avoid messy and fragile escaping, I'd recommend to work with file
descriptors.
Greetings,
Maxime.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 26 Jun 2022 10:34:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hello everyone,
Maxime Devos <maximedevos <at> telenet.be> writes:
> Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]:
>> [...]
>> the problem was that I could not control Guile's choice
>> of
>> file descriptors. Guile chose file descriptor 19 for one end of the
>> pipe, and I don't know how to make it use anything else. If we can
>> arrange for Guile to consistently use file descriptor 7, for example,
>> then probably it would work in all the shell I've tested.
> Have a look at ‘(guile)Ports and File Descriptors’. It has lots of
> procedures for duplicating and renumbering. That's fragile though, you
> might accidentally overwrite an fd that's being used for something
> else.
Just my 2¢, from my experience, Guile uses a lot of fds (`guile -q` uses
15). I'm not sure it would be safe or advisable to move fds, since we
cannot be sure that they're backing ports or not, and if they're not it
would break things. In general, the Guile ports/fds interface works ok,
but there is a lot of code that is fragile and doesn't handle
edge-cases.
Best,
--
Josselin Poiret
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 26 Jun 2022 13:08:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Josselin Poiret schreef op zo 26-06-2022 om 12:33 [+0200]:
> Just my 2¢, from my experience, Guile uses a lot of fds (`guile -q` uses
> 15). I'm not sure it would be safe or advisable to move fds, since we
> cannot be sure that they're backing ports or not, and if they're not it
> would break things
As mentioned previously, move->fdes looks in the port table to see if
the file descriptor things are being moved too is still in use, and if
so, moves that (fd, port) out of the way first, so should be safe.
That only works if Guile knows about the fd though, and Guile currently
does not know about it's own finalisation pipe, which I think is the
cause of <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48563>, so
currently still fragile ...
(To be clear, I still recommend just fixing dash ...)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Sun, 26 Jun 2022 19:46:03 GMT)
Full text and
rfc822 format available.
Message #93 received at 51466 <at> debbugs.gnu.org (full text, mbox):
On 26 June 2022 13:07:11 UTC, Maxime Devos <maximedevos <at> telenet.be> wrote:
>(To be clear, I still recommend just fixing dash ...)
That's the long-term solution, but Guix needs a work-around regardless.
Kind regards,
T G-R
Sent on the go. Excuse or enjoy my brevity.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 27 Jun 2022 10:18:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi Chris,
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> It turns out that it is probably not OK to rely on shell redirection in
> this case, after all. For example, "dash does not support multi-digit
> file descriptors":
>
> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
Bah. :-/
[...]
> To resolve this, I changed the code so that it just writes to a
> temporary file. This is simple and more robust. With the attached
> patch, I was able to use a command like the one above to verify that
> "guix environment --check" works correctly for Guix-built bash, dash,
> ksh, fish, zsh, and ash. I also verified that it works for Fedora's
> /bin/sh and /bin/bash.
>
> What do you think of this file-based approach? Supporting many
> different shells is pretty tricky, but I think this patch does a good
> enough job.
Like Maxime, I’d rather not create a temporary file.
I agree that Dash should be fixed, but in the meantime, we still want
our stuff to work with the broken Dash (it’s the default on
Debian/Ubuntu, isn’t it?).
I don’t have a better idea to offer though…
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 27 Jun 2022 10:35:03 GMT)
Full text and
rfc822 format available.
Message #99 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès schreef op ma 27-06-2022 om 12:17 [+0200]:
> I agree that Dash should be fixed, but in the meantime, we still want
> our stuff to work with the broken Dash (it’s the default on
> Debian/Ubuntu, isn’t it?).
If Dash is fixed, then it's non-broken, and we don't have to work with
the broken Dash. I don't expect fixing it to be more complicated than
the work-arounds in Guile.
> On 26 June 2022 13:07:11 UTC, Maxime Devos <maximedevos <at> telenet.be>
> wrote:
> >(To be clear, I still recommend just fixing dash ...)
>
> That's the long-term solution, but Guix needs a work-around
> regardless.
Fixing dash seems to me something that could be done in the short term?
Greetings,
Maxime
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 27 Jun 2022 11:24:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 51466 <at> debbugs.gnu.org (full text, mbox):
On +2022-06-27 12:17:08 +0200, Ludovic Courtès wrote:
> Hi Chris,
>
> Chris Marusich <cmmarusich <at> gmail.com> skribis:
>
> > It turns out that it is probably not OK to rely on shell redirection in
> > this case, after all. For example, "dash does not support multi-digit
> > file descriptors":
> >
> > https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
>
> Bah. :-/
>
> [...]
>
> > To resolve this, I changed the code so that it just writes to a
> > temporary file. This is simple and more robust. With the attached
> > patch, I was able to use a command like the one above to verify that
> > "guix environment --check" works correctly for Guix-built bash, dash,
> > ksh, fish, zsh, and ash. I also verified that it works for Fedora's
> > /bin/sh and /bin/bash.
> >
> > What do you think of this file-based approach? Supporting many
> > different shells is pretty tricky, but I think this patch does a good
> > enough job.
>
> Like Maxime, I’d rather not create a temporary file.
>
> I agree that Dash should be fixed, but in the meantime, we still want
> our stuff to work with the broken Dash (it’s the default on
> Debian/Ubuntu, isn’t it?).
>
> I don’t have a better idea to offer though…
>
> Ludo’.
>
>
>
If this is all about capturing an environment as text,
how about
--8<---------------cut here---------------start------------->8---
xargs -0 < /proc/$$/environ
--8<---------------cut here---------------end--------------->8---
(not limited to $$ I would think)
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 27 Jun 2022 14:23:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 51466 <at> debbugs.gnu.org (full text, mbox):
On +2022-06-27 13:23:15 +0200, bokr <at> bokr.com wrote:
> >
> If this is all about capturing an environment as text,
> how about
>
> --8<---------------cut here---------------start------------->8---
> xargs -0 < /proc/$$/environ
> --8<---------------cut here---------------end--------------->8---
>
> [...]
>
Actually, why fight shell stuff when guile can read it?
Or are these modules not available in your context?
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (use-modules (ice-9 textual-ports))
scheme@(guile-user)> (define ep (open-input-file "/proc/12430/environ"))
scheme@(guile-user)> (define es (get-string-all ep))
--8<---------------cut here---------------end--------------->8---
es from above got it all, when I tried manually as above.
FWIW I also did the same with (use-modules (rnrs bytevectors))
and the nulls show up as the expected zeroes.
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 28 Jun 2022 07:46:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Maxime Devos <maximedevos <at> telenet.be> skribis:
> Ludovic Courtès schreef op ma 27-06-2022 om 12:17 [+0200]:
>> I agree that Dash should be fixed, but in the meantime, we still want
>> our stuff to work with the broken Dash (it’s the default on
>> Debian/Ubuntu, isn’t it?).
>
> If Dash is fixed, then it's non-broken
Even if a fix goes upstream today, people will still be using a distro
with the broken Dash for years, literally. That’s why I think we have
to cope with it.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 28 Jun 2022 10:39:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès schreef op di 28-06-2022 om 09:45 [+0200]:
> Maxime Devos <maximedevos <at> telenet.be> skribis:
>
> > Ludovic Courtès schreef op ma 27-06-2022 om 12:17 [+0200]:
> > > I agree that Dash should be fixed, but in the meantime, we still want
> > > our stuff to work with the broken Dash (it’s the default on
> > > Debian/Ubuntu, isn’t it?).
> >
> > If Dash is fixed, then it's non-broken
>
> Even if a fix goes upstream today, people will still be using a distro
> with the broken Dash for years, literally. That’s why I think we have
> to cope with it.
Then it could be fixed in that distro? And if the distro intentionally
keeps it broken for years, then that seems more a problem in the distro
than Guix to me.
Greetings,
Maxime.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 28 Jun 2022 16:58:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 51466 <at> debbugs.gnu.org (full text, mbox):
On Tue Jun 28, 2022 at 11:38 AM BST, Maxime Devos wrote:
> Then it could be fixed in that distro? And if the distro intentionally
> keeps it broken for years, then that seems more a problem in the distro
> than Guix to me.
I believe Ludo' is referring to LTS distros and other situations where
somebody might not update for a long time.
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Tue, 28 Jun 2022 17:32:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 51466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
( schreef op di 28-06-2022 om 17:57 [+0100]:
> On Tue Jun 28, 2022 at 11:38 AM BST, Maxime Devos wrote:
> > Then it could be fixed in that distro? And if the distro intentionally
> > keeps it broken for years, then that seems more a problem in the distro
> > than Guix to me.
>
> I believe Ludo' is referring to LTS distros and other situations where
> somebody might not update for a long time.
>
> -- (
I'm thinking so too, though I want to mention LTS is not just ‘don't
update’ -- the third letter means ‘support’, which covers backporting
bug fixes, though I don't know if the distro would include dash > 9 fds
in this.
Greetings,
Maxime.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#51466; Package
guix.
(Mon, 04 Jul 2022 08:12:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 51466 <at> debbugs.gnu.org (full text, mbox):
Hi,
"(" <paren <at> disroot.org> skribis:
> On Tue Jun 28, 2022 at 11:38 AM BST, Maxime Devos wrote:
>> Then it could be fixed in that distro? And if the distro intentionally
>> keeps it broken for years, then that seems more a problem in the distro
>> than Guix to me.
>
> I believe Ludo' is referring to LTS distros and other situations where
> somebody might not update for a long time.
Yeah. Whatever the reason, it’s a fact that our users might run Guix on
a system with a broken Dash, which is why I think we have to cope with it.
Ludo’.
This bug report was last modified 2 years and 344 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.