zsh home service breaks guix shell via ssh

  • Open
  • quality assurance status badge
Details
2 participants
  • Malte Frank Gerdes
  • Saku Laesvuori
Owner
unassigned
Submitted by
Malte Frank Gerdes
Severity
normal
M
M
Malte Frank Gerdes wrote on 23 Sep 2023 12:19
(address . bug-guix@gnu.org)
868r8xrxu4.fsf@gmail.com
Hi,

i set up a new system last weekend and am connecting to it via ssh. I
also just recently started using guix home.

I noticed that after connecting via ssh the profile that gets created
when doing `guix shell' is not sourced, therefore the environment
variables are not correct. This seems to be because guix home inserts
"[ -n \"$SSH_CLIENT\" ] && source /etc/profile" into the zshenv file. I
assume this is meant to ensure that /etc/profile is sourced because ssh
does not start a login shell? Anyway, removing that line makes
everything work normally. So am i doing it wrong or is this actually
unnecessary?


mfg²
S
S
Saku Laesvuori wrote on 24 Sep 2023 17:27
(name . Malte Frank Gerdes)(address . malte.f.gerdes@gmail.com)(address . 66168@debbugs.gnu.org)
gvkz2lwzlrs7nokt6fjfy45p4gulpt6xss54dxfvkd7gjmp2tm@jwb7hnnfnj3i
On Sat, Sep 23, 2023 at 12:19:10PM +0200, Malte Frank Gerdes wrote:
Toggle quote (7 lines)
> I noticed that after connecting via ssh the profile that gets created
> when doing `guix shell' is not sourced, therefore the environment
> variables are not correct. This seems to be because guix home inserts
> "[ -n \"$SSH_CLIENT\" ] && source /etc/profile" into the zshenv file. I
> assume this is meant to ensure that /etc/profile is sourced because ssh
> does not start a login shell?

That is correct, it was added in https://issues.guix.gnu.org/64765
because commands like `ssh host -- cmd` (and commands depending on ssh
such as `git pull/push`) failed.


Toggle quote (3 lines)
> Anyway, removing that line makes everything work normally. So am i
> doing it wrong or is this actually unnecessary?

I can reproduce this:

```
$ ssh localhost
$ guix shell gnuplot
$ gnuplot
zsh: command not found: gnuplot
```

However (still within the ssh session)

```
$ guix shell gnuplot -- gnuplot
[gnuplot opens as expected]
```

and weirdly enough

```
$ guix shell --check gnuplot
guix shell: checking the environment variables visible from shell '/gnu/store/i4rj0banq044423if5xwb3df723g14r9-zsh-5.9/bin/zsh'...
guix shell: All is good! The shell gets correct environment variables.
$ gnuplot
zsh: command not found: gnuplot
```

I don't really know what is happening here. Why does it work when
running the command directly and why does `guix shell --check` claim
that everything is correct when clearly something is wrong? If I
understand correctly `.zshenv` should be sourced in all these cases but
for some reason the problems only occur in some of them.

Any ideas?
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoMkZR3NPB29fCOn/JX0oSiodOjIFAmUQVUwACgkQJX0oSiod
OjIKKxAAr1mNjtOoi5v5cqLEdmUTmv4KfAtdrpIUJ4orKhsjYtWDMVu9Bb180NAK
JV2SkkgqoKFGLLXF3qdiURSrUXoju051Rx8OLkiTo9DC3FvJ9/etr9GzMjJo+e07
tMe1gX6DlqxV3vQ0zBRAIbfcIDmz3gWb2c1VHV9ElFErbbl5FUeh3my56zQDVDwI
hR1pmQnwXJq+BKkvwCLr6qir47GpNk8Qnr/2oTF2rB92auroGLmtKm8z9DKcHv6v
S8lUpl+5gojHZjJFmaenUz+GcqnWGLFy3QXBWmGD2KBkszkPQMzQP1ytFA8djOzI
/8XEg5rWo501f+Gr/CAQxQiE3W1/3JSDxcY7wbmswSZwjb96De39RuDRAO0RzYLu
EsJUTlNZioXXbv1NrI8am7y4rGcRSCs+L3Zf4UHOnv+9jYtONaV84q7r5zZxoUUr
9UjkS/hEs3pm57WYzmqwrzli3vmZ0pajxi9osliH9htmSNEIOWdHDvBuHFfaF0L5
rSHIti1i1si4xe7rT3qizibd67EDO+00zdEPtztzQv8Yiir5p62bCNaZ7DF4jYoU
jP20tlSU+GyU+qk4UQKdYEZpV/L8vUk1gf/R3/JtAggx/9uvAVTQFLIKaigzMV2S
oKA7uKXt7/BaCooNyBR5SGkbNm87dhgWpB62DSkCLvYdMvfr2UA=
=MDMH
-----END PGP SIGNATURE-----


M
M
Malte Frank Gerdes wrote on 24 Sep 2023 20:48
(name . Saku Laesvuori)(address . saku@laesvuori.fi)(address . 66168@debbugs.gnu.org)
86cyy75rg1.fsf@gmail.com
Saku Laesvuori <saku@laesvuori.fi> writes:

Toggle quote (12 lines)
> [[PGP Signed Part:Undecided]]
> On Sat, Sep 23, 2023 at 12:19:10PM +0200, Malte Frank Gerdes wrote:
>> I noticed that after connecting via ssh the profile that gets created
>> when doing `guix shell' is not sourced, therefore the environment
>> variables are not correct. This seems to be because guix home inserts
>> "[ -n \"$SSH_CLIENT\" ] && source /etc/profile" into the zshenv file. I
>> assume this is meant to ensure that /etc/profile is sourced because ssh
>> does not start a login shell?
>
> That is correct, it was added in <https://issues.guix.gnu.org/64765>
> because commands like `ssh host -- cmd` (and commands depending on ssh
> such as `git pull/push`) failed.
Ah, i didn't think about this use case.

Toggle quote (36 lines)
>> Anyway, removing that line makes everything work normally. So am i
>> doing it wrong or is this actually unnecessary?
>
> I can reproduce this:
>
> ```
> $ ssh localhost
> $ guix shell gnuplot
> $ gnuplot
> zsh: command not found: gnuplot
> ```
>
> However (still within the ssh session)
>
> ```
> $ guix shell gnuplot -- gnuplot
> [gnuplot opens as expected]
> ```
>
> and weirdly enough
>
> ```
> $ guix shell --check gnuplot
> guix shell: checking the environment variables visible from shell '/gnu/store/i4rj0banq044423if5xwb3df723g14r9-zsh-5.9/bin/zsh'...
> guix shell: All is good! The shell gets correct environment variables.
> $ gnuplot
> zsh: command not found: gnuplot
> ```
>
> I don't really know what is happening here. Why does it work when
> running the command directly and why does `guix shell --check` claim
> that everything is correct when clearly something is wrong? If I
> understand correctly `.zshenv` should be sourced in all these cases but
> for some reason the problems only occur in some of them.
>
> Any ideas?
My guess would be that sourcing /etc/profile should only happen once,
but the SSH_CLIENT variable is inherited to the child shell which
evaluates zshenv which in turn sources /etc/profile because SSH_CLIENT
has non-zero length. So /etc/profile is sourced twice.

This is just a wild guess though.


mfg²
S
S
Saku Laesvuori wrote on 25 Sep 2023 16:56
(name . Malte Frank Gerdes)(address . malte.f.gerdes@gmail.com)(address . 66168@debbugs.gnu.org)
vnlwmxbvzg5gofbvff2tsaefgxx4edsqwzs7vnc3mzqs67fupz@dqbhrbdhs6sk
Toggle quote (39 lines)
> > ```
> > $ ssh localhost
> > $ guix shell gnuplot
> > $ gnuplot
> > zsh: command not found: gnuplot
> > ```
> >
> > However (still within the ssh session)
> >
> > ```
> > $ guix shell gnuplot -- gnuplot
> > [gnuplot opens as expected]
> > ```
> >
> > and weirdly enough
> >
> > ```
> > $ guix shell --check gnuplot
> > guix shell: checking the environment variables visible from shell '/gnu/store/i4rj0banq044423if5xwb3df723g14r9-zsh-5.9/bin/zsh'...
> > guix shell: All is good! The shell gets correct environment variables.
> > $ gnuplot
> > zsh: command not found: gnuplot
> > ```
> >
> > I don't really know what is happening here. Why does it work when
> > running the command directly and why does `guix shell --check` claim
> > that everything is correct when clearly something is wrong? If I
> > understand correctly `.zshenv` should be sourced in all these cases but
> > for some reason the problems only occur in some of them.
> >
> > Any ideas?
>
> My guess would be that sourcing /etc/profile should only happen once,
> but the SSH_CLIENT variable is inherited to the child shell which
> evaluates zshenv which in turn sources /etc/profile because SSH_CLIENT
> has non-zero length. So /etc/profile is sourced twice.
>
> This is just a wild guess though.

Seems to be about right. I had just assumed that guix shell would run
the command in a new shell (causing .zshenv to be sourced in all those
cases) but apparently it just calls the command directly. I haven't seen
any problems with sourcing /etc/profile multiple times because it
reloads both system and user profiles, but obviously it doesn't know
about guix shell profiles.

It seems that the default bash configuration only sources /etc/profile
if $SSH_CLIENT is non-empty and bash is used non-interactively.
Something similar could probably be done with zsh, but I would expect it
to still have this issue in certain situation. For example, I think
running a script like this

```
$ ssh host -- guix shell gnuplot <<EOF
...
EOF
```

would probably still fail.

I can't really think of any other possible solution than having an
environment variable that is set by /etc/profile and that makes sourcing
it a no-op.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoMkZR3NPB29fCOn/JX0oSiodOjIFAmURn6IACgkQJX0oSiod
OjJ9YQ/+OukMe1pzwOWeWz2rwaSwx+rcWOTOboLUjsu9JmXB/3HwL+Qh8Ot1bK9T
yfes+4G0EfHoyHtWpJ6yIifga70wEvODhurR2ZWokpjihynwoGxhT7hI1rFYJDzO
81CiYN3+rIqp4B1x/jKt/XIKe7UmcUOc25evWqjEWRy3sRd4FsnBGW7LG7B1eZyi
LxbfwyveTWAZjGvXB6gmuJ7zwzN4DuvX1FBEvhlWIt9VNkkBHk+kQ8jWNYYQBhQA
nhAR8YQYV684ftzNU36Wgh/E7H0hqIUtN0E3Y1mNTjD48iDIcXLYaOCH5kDFNAc+
uhEZbrGh8SHcVICOEWKwopT0i9+MK4reF+ATh8cBnWj8d4jZoVjGgr1tMtjmgMDl
EFN9u4eGJ+1gupER0z5/weHVf7Pv0DqgKcWZdmhM/3GWLyltZyS7l8zs1a6v/CCc
DGCctzRDG1wKIAaxoAvmh7K9tPgOLwpOYjSlCzZKrUhpPlLg8EQagZPtcfxdg9IZ
j5KQzP7M/T2rtp+wtzb1pt27OOJJnH8LxEdCjVa2kxfJWYUV4/yUYDVOuFH0QOZd
9qchxODcKe8yixF8dqAaY/3W1bGkpkIF8lCz+kYszMF0vTWwaAQaXy6ICRRNTyPP
sSAYgF93VHyPdoCmy0SA3olCC5uZZHKGgFd255sEayA2TGHf6H8=
=ljSb
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 66168@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66168
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch