Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: fallback shell #6

Open
RGBCube opened this issue May 15, 2024 · 6 comments
Open

Feature request: fallback shell #6

RGBCube opened this issue May 15, 2024 · 6 comments

Comments

@RGBCube
Copy link

RGBCube commented May 15, 2024

If the main shell exits with an exit code, a fallback shell could be launched. Pretty useful if you use unstable shells that decide to explode every few months.

This could be done by parsing the environment variable and splitting by : and every time a shell exits with an exit code that isn't 0, the next one gets launched

@RGBCube
Copy link
Author

RGBCube commented May 15, 2024

Also for this to work, noshell needs to accept an environment variable instead of a file to work, it could check for the variable if the files don't exist

@viperML viperML closed this as not planned Won't fix, can't repro, duplicate, stale May 15, 2024
@viperML viperML reopened this May 15, 2024
@RGBCube
Copy link
Author

RGBCube commented May 15, 2024

Tfw you've already created a more efficient replacement @ https://github.com/RGBCube/crash in Zig

@Rutherther
Copy link
Contributor

Passing it as an environment variable seems a bit out of scope of noshell to me. As far as I understand noshell's primary objective is replacing login shell that can normally be configured only with root rights. When you are already in an environment, logged in, you can launch what shell you prefer using other means.

The problem is now that when you launch noshell as login shell, there is no user environment loaded in. It's thus impossible to add feature like this for a login shell.

Personally I would think having that logic coded into the executable that's started with noshell could be better. You can put your launcher script to ~/.config/shell that will try to launch multiple shells based on the exit codes. This can be launched by noshell. There you can resolve it for example with some kind of a configuration file. It seems to me like it's of a benefit to keep noshell itself as simple as possible, so there are less places it can fail at.

Of course, what could be feasible is falling back to the default shell, like sh is now, in case of an error, just the environment cannot work.

@RGBCube
Copy link
Author

RGBCube commented May 15, 2024

Login shells aren't init processes. Even those have environments.

environment.sessionVariables sets the environment vars before the login shell is run.

The way I am doing it in crash is to set it to .config/shell and then having users change that. An environment variable that defaults to .config/shell would be backwards compatible and would work with changing shells with SSH and setting fallback shells.

@Rutherther
Copy link
Contributor

I have not claimed there is no environment at all. Just that it's not the user's environment. Thus the stated goal of not having to change something as root is gone.

@viperML
Copy link
Owner

viperML commented May 22, 2024

I can understand that noshell can lock you out. But the env variable solution wouldn't be very useful for anything other than SSH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants