GNU bug report logs - #66168
zsh home service breaks guix shell via ssh

Previous Next

To reply to this bug, email your comments to 66168 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Malte Frank Gerdes <malte.f.gerdes <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: zsh home service breaks guix shell via ssh
Date: Sat, 23 Sep 2023 12:19:10 +0200

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²

Message #8 received at 66168 <at> debbugs.gnu.org (full text, mbox):

From: Saku Laesvuori <saku <at> laesvuori.fi>
To: Malte Frank Gerdes <malte.f.gerdes <at> gmail.com>
Cc: 66168 <at> debbugs.gnu.org
Subject: Re: bug#66168: zsh home service breaks guix shell via ssh
Date: Sun, 24 Sep 2023 18:27:08 +0300

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

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. 


> 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?

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 66168 <at> debbugs.gnu.org (full text, mbox):

From: Malte Frank Gerdes <malte.f.gerdes <at> gmail.com>
To: Saku Laesvuori <saku <at> laesvuori.fi>
Cc: 66168 <at> debbugs.gnu.org
Subject: Re: bug#66168: zsh home service breaks guix shell via ssh
Date: Sun, 24 Sep 2023 20:48:44 +0200

Saku Laesvuori <saku <at> laesvuori.fi> writes:

> [[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.

>> 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²

Message #14 received at 66168 <at> debbugs.gnu.org (full text, mbox):

From: Saku Laesvuori <saku <at> laesvuori.fi>
To: Malte Frank Gerdes <malte.f.gerdes <at> gmail.com>
Cc: 66168 <at> debbugs.gnu.org
Subject: Re: bug#66168: zsh home service breaks guix shell via ssh
Date: Mon, 25 Sep 2023 17:56:34 +0300

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

> > ```
> > $ 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.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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