Skip to content
This repository has been archived by the owner on May 21, 2019. It is now read-only.

Status of shells #1261

Open
Riebart opened this issue Oct 25, 2017 · 0 comments
Open

Status of shells #1261

Riebart opened this issue Oct 25, 2017 · 0 comments

Comments

@Riebart
Copy link

Riebart commented Oct 25, 2017

So I'm starting to poke at supporting the modern shells available on Windows (#800), and I'm currently blocked by some architectural decisions on how shell processes are spawned and how context is managed. I'm curious as to the status of whether Upterm is going to continue with developing a custom shell (#449) or whether I should invest time in restructuring how shells are invoked.

Specifically, to get WSL shells to work on Windows:

  • All references to a home directory need to be in the context of the shell not the OS/platform
  • The home directory will require invoking the shell either in the context of the Upterm process, or a clean slate with no propagated environment (and no configuration scripts) to get the home directory to use when resolving the configuration files for the shell with relative paths (relative to the home directory, that is).
  • Some shell providers, like Powershell, can do really complicated things like importing modules when invoked, and this takes time. Upterm enforcing a new process for every command may significantly hamper this featureset.

Some other comments:

  • Currently shells are spawned with some rather awkward semantics and process handling. This should be fixed and, if done right, could even allow Upterm to work inside a remote SSH shell (that is, the shell provider could be bash on a remote server). This would be really useful for people that work a lot on remote machines.
  • Different tabs should be able to have different shell providers.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant