Feature: Layers / overlays / snapshots for env & shell config?

[akavel]

I will start from a "problem statement", a.k.a. the use case/user story: in existing shells (be it bash or zsh), I'm often in pain when I want to change something in my .bashrc/.zshrc. (Also similar in vim etc., but that's definitely not in scope.) I'd love if OSH had a feature that would let me reset and reload an older "layer" of my env (and ideally also config settings like setopt, aliases, etc.), but keeping any changes to it that were added after .bashrc, as well as the ones that existed before it was run. Currently, the only ways I know how to reload .bashrc in bash are:

• a) source ~/.bashrc — the disadvantages being:
  • CON: env vars that I removed from ~/.bashrc will stay in env until I restart bash
  • CON: changes to env that I did after .bashrc might get overridden
  • CON: some env vars may grow more and more every time (e.g. PATH=$PATH:something)
  • "PRO" (vs. (b)): my jobs are still live, any env changes I did afterwards may possibly still be active and not overridden
• b) exit bash & start new instance
  • PRO: vars that I removed in .bashrc are now cleaned up
  • CONs are even more than in (a): my jobs are kiled; I lose any changes to env done after .bashrc; etc....

My idea how this could possibly be solved, would be through "layering" (also known as "dynamic scoping" in Lisp-like or Forth-like languages, IIUC) of env variables (and other OSH config). This is an idea somewhat similar to Docker layers, or how Git commits are built underneath. This could (hopefully) come with an additional feature, where an earlier layer (i.e. the one created by .bashrc) could be rebuilt, and the later one(s) added back on top of it. This might also sound kinda similar to "git rebase". One tricky part could be that some later layers might be built off values from earlier ones, making them now out of sync; but I don't think this happens that often, and personally I would already find it to be a huge quality of life improvement even with this caveat.

Personally, I felt this pain enough times, that it would be a killer feature for me, one that would make me immediately try hard to switch from bash to OSH for interactive work.

Possibly related: #536 (sounds to me like a different, or maybe actually similar, idea for resolving the same use case?)

[andychu]

Sorry for the delay, I think this is a good idea. It probably falls somewhere between these two features:

• shell options are already a stack in Oil. You can do shopt --unset errexit { any code }
  • however there is a lot of other shell state. Like (global) variables are not a stack. You can't push and pop them. Nonlocal var references fall back on globals, even when we disable dynamic scope in Oil.
• "subinterpreters" #704 . Reifying the entire state of the shell.
  • Oil is pretty principled about state and I started documenting it here: https://github.com/oilshell/oil/blob/master/doc/interpreter-state.md

I would be interested in a concrete design that helps flush this out ... either by Wiki page or hacking up a prototype on the Python code. The code is designed to be flexible to support experiments like this.

FWIW personally I use tmux and different shell sessions, which is another way of containing state ...

[andychu]

I should also mention that to really reify state, you need containers, because some state lives outside the shell itself.

But containers aren't portable, so we should probably have something inside the shell...

[MayCXC]

here is an approach with POSIX sh: https://github.com/MayCXC/envy that uses a profile stack and shell subprocesses to do something similar @akavel