[bug#54377] [PATCH 3/3] guix home: Add 'container' command.

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

>> +For example, this is how you would start an interactive shell in a
>
> s/interactive/login ?
>
> or interactive login shell

Yeah.  I thought that as a user, what matters is that it’s interactive;
the fact that it’s a “login shell” is more of an implementation detail,
and too few people understand what that means anyway.  :-)

[...]

>> +Additionally, you can run a command in that container, instead of
>> +spawning an interactive shell.  For instance, here is how you would
>
> In fact the sentence is correct, but gives a feeling that the shell
> won't be executed at all.  Don't know if we need to change it somehow.

I agree that the sentence is an approximation of how it does things, but
hopefully it gives a good idea of what it.

>> +  (display (G_ "
>> +  -N, --network          allow containers to access the network"))
>
> Is plural form intended?

(Copied from environment.scm.)  I think it’s grammatically OK.

>> +(define (user-shell)
>> +  (match (and=> (or (getenv "SHELL")
>
> Be aware that in some cases $SHELL can differ from the value in
> /etc/passwd.  For example I set SHELL to the full path to zsh and all
> interactive non-login shells are zsh for me, but my login shell is bash.

Agreed, that’s why I thought $SHELL should take precedence.  (I used
“SHELL=zsh guix home container …” and similar to test other shells.)

>> +                    (passwd:shell (getpwuid (getuid))))
>> +                basename)
>> +    ("zsh"  (file-append zsh "/bin/zsh"))
>> +    ("fish" (file-append fish "/bin/fish"))
>> +    ("gash" (file-append gash "/bin/gash"))
>> +    (_      (file-append bash "/bin/bash"))))
>
> Why we use hardcoded shell packages?

For reproducibility.

Initially I thought about using the actual $SHELL (as long as it’s in
the store).  However, that would make ‘guix home container’ stateful:
it’d provide different results depending on the environment.

I thought we’d rather avoid that.

> 1. The will be built in case user use a zsh-patched for example.

That’s the downside, yes.

I don’t have a good answer to that.  I guess I value reproducibility
more than customization in this case.

Perhaps we could eventually add a ‘--shell’ option or similar if that
helps, though.  WDYT?

>> +           (when term
>> +             ;; Preserve TERM for proper interactive use.
>> +             (setenv "TERM" term))
>
> Just a note: the shell can missbehave if terminfo files for current TERM
> isn't present in the container (for example terminal package was removed
> from home profile).  Idk how to properly cover this, but just letting
> you know.  We can use TERM=dumb, but I'm not sure if it worth it.

Good point.  In my tests preserving TERM was good enough for
Bash/Readline, Zsh, and less (all from an xterm).  I suppose problems
could happen with fancy curses apps and the like.

> Very cool feature!  Looking forward to add it to my workflow. 

Glad you like it!  It makes it easier to test new features or services,
much like using ‘guix system vm’ when testing Guix System changes.

Thanks for taking the time to review!

Ludo’.