lorri shell tracking issue

[grahamc]

• Bring back lorri shell which does an immediate, blocking evaluation, pins the GC root, and executes the user's $SHELL in the lorri-generated environment lorri shell #295
• If lorri shell fails, suggest to the user that they re-run with -v to get error output. Not great, but quick win until we get to Show Nix failure logs to user #296.
• Users need to know they're in a lorri shell with some sort of PS1-like manipulation (user-customization not in scope at this time) lorri shell #295 (comment)
• Allow a user to open a cached lorri shell with no evaluation or build with --cached. If lorri shell fails (or takes a "long time"), suggest this option automatically. If the user runs with --cached without a cached evaluation, it should exit non-zero.
• Users need to know why lorri shell failed, if it did (Show Nix failure logs to user #296)
• release notes

---

Spawn the user's shell like this:

$ lorri shell  ===== this command should stay running and not exec() itself away
   -> build env
   -> Command::spawn(bash --load-our-fancy-profile ~/.cache/lorri/gcroot/whatever -- exec /path/to/lorri start-user-shell $SHELL)
        -> bash ===== this command should exec() itself away
             -> source ~/.cache/lorri/gcroot/whatever
             -> lorri start-user-shell "$SHELL"  ===== this command should exec() itself away and NOT use temporary directories or threads
                   -> how_do_we_setup_for_($SHELL)? -> Command
                   -> https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.exec the Command result

This way we can do per-$SHELL switching, and have safe execution in the shell environment without having to pass a deeply quoted string of things for our middle level bash to run. Make sure to use std::env::current_exe for the path to lorri.

[Profpatsch]

I like that we can have a nix-shell but with the user’s shell instead.

[curiousleo]

Users need to know they're in a lorri shell with some sort of PS1-like manipulation (user-customization not in scope at this time)

We've already established that this requires per-shell handling, because shells take different approaches to the configuration of the prompt line. What I've found now is that even for bash and zsh, it's not going to be as easy setting "PS1" using Command::env since they source init scripts by default on startup, which in almost all cases overwrite the value of "PS1".

nix-shell does this by first explicitly sourcing bash init scripts then overwriting the value of PS1 and finally starting bash with the generated file using --rcfile.

I can't think of any other way that makes sure the PS1 is set by lorri while also respecting the user's setup (except for PS1, of course) - and even then it is possible to break this: NixOS/nix#1268 (comment).

Relevant flags:

bash: --rcfile <file> sources instead of the normal startup files - this is what nix-shell uses in combination with explicitly sourcing the default scripts
zsh: -f disables sourcing default startup files
fish: --init-command allows execution of commands at startup
elvish: ?
tcsh: ?