Using es in a Bourne shell world

[wryun]

Thought it might be useful/interesting/cathartic to list a few pain points and how I've navigated around them (or not). And a record of some of the times I've annoyed people on the internet :)

• painful copying commands from places, mostly due to double quotes (and previously Allow '=' character in command arguments #41 - thanks @memreflect , I still frequently appreciate this one). e.g. I just raised https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057835 You can also work around it in most cases with a function like:

fn x {
  sh -c $^*
}

• sometimes programs look at SHELL and then decide it must be Bourne shell compatible: Version update fails on non-standard SHELL superfly/flyctl#1901
• older style gdm required hackery to get the es environment loaded: https://unix.stackexchange.com/questions/46045/how-do-you-set-up-the-environment-for-es
• gnome-session now somehow gets the environment from the login shell, but then likes to filter out some of variables (incl. just long ones because of a glib bug): https://gitlab.gnome.org/GNOME/glib/-/issues/2824
• Python virtualenvs don't have an 'es' activation script. It's basically good enough to just put the venv bin directory in your path, or you can write something like (requiring 'exit' to leave the venv, and it's your responsbility to put the VIRTUAL_ENV variable in your prompt):

fn a {
  /bin/bash --init-file <{cat $1/bin/activate; echo 'exec es'}
}                               

• relatedly, poetry shell falls back to using /bin/sh because it doesn't know what to do about es (and even specifying SHELL won't seem to make it behave, though I haven't looked deeply into it)

[mwgamera]

Programs using system shouldn't be a problem unless you put es under /bin/sh, but trying to make guesses about $SHELL is indeed asking for trouble.
An inverse of that gdm one is something like dircolors or anything else that wants you to eval its output to set some variables with export commands and wrong quoting:

eval ``(){env -i PATH\=$PATH sh -c 'eval $(perl -Mlocal::lib); es -c vars'}

[wryun]

Ah, yes, that flyctl issue made me think it might affect system(), but of course it's sensibly defined. I'll edit my original text. I'm now semi-tempted to see how far you could make a basic Linux system run without /bin/sh (definitely a pointless exercise in masochism).

[hyphenrf]

So far, the incompatibility annoyances haven't been much, so I haven't invested in proper automated solutions to them -- mostly ad-hoc hand-rolled solutions whenever they come up. es is my login shell and not much more, the system shell obviously remains /bin/sh, via busybox. Here are a few edits I've done:

I'm an OCaml programmer, and similar to python/poetry, opam doesn't have es shell hooks. I had to write my own function to be able to use opam without pain:

fn empty {~ $*}

if {! empty `{which opam}} {
   fn opam-env {
      let (options = $*; ifs = \n)
      for (i=`{opam env $options |sed '/^#/d;s/; export.*//'})
          eval $i
      return 0
   }
}

it is then used with %prompt to auto-update the environment, like the actual opam shell hook does.

I've also translated my /etc/profile* code manually to load init scripts of various installed programs late on login. Most notably, I have nix installed as a user package manager, and it executes some init code in profile. I've translated that code to es as a function and left it unloaded. I only enable the nix environment when I need to use nix, which isn't often. I did this mainly because the code causes a segfault on subshells(!) but I haven't gotten to the reason behind that. It's been on my backlog for a long while and I was planning to open an issue once I've investigated. This actually reminded me of that. But this is rather off-topic anyway.

[jpco]

I haven't run into many of the same problems as you all, probably because I don't use as fancy a development environment (kids these days with their venvs and their opams!)

I have, however, run into the "how do I run .esrc on graphical login?" problem. My answer for a long time was the bad "turn .esrc into the fresh-terminal startup script" hack. Now my answer is primarily the "just don't use graphical login" workaround. Not very sophisticated. I should take a page from your book, @wryun, and actually be a good citizen. :)

I've also hit the "no /etc/profile* at login" problem, enough that my .esrc has a couple variables I wouldn't otherwise need to set myself. I wonder if there's some simple way to make that work automagically, though -- call out to a /bin/sh script to run all the /etc/profile* scripts and then get its environment either with env or some /proc/$pid/environ hackery.

Something like this?

for (assign = `` \n {env -i /bin/sh -c '. /etc/profile && env'}) {
  let ((var val) = <={~~ $assign *=*}) {
    $var = $val
  }
}

You get a little noise sometimes, like _ or SHLVL, but that's easy to filter out (and/or use something like dash that does less). I'm sure there's something wrong with this -- maybe env -i is too limiting? Just looking in profile.d I see that locale.sh does some logic based on its environment. Maybe es -pc {/bin/sh ...} would work better than env -i /bin/sh ....