Closed Gerschtli closed 4 years ago
That sounds very straightforward, because it is quite easy to extract it from /etc/passwd
somewhere in login-inner
and execute it instead of bash
; and, at the same time, very complicated, because there should be a recovery mechanism if the shell is broken.
/system/bin/sh
should be considered a valid fallback I think or try /bin/sh
at least, but this should not be to complicated.
The point is, I cannot clearly formulate a criteria to determine whether the user shell is broken or not. Once we have it, yeah, it's probably not that complicated.
Why bother with this question, when we have a failsafe version? I don't really know, what the failsafe one really is, but maybe the user could repair his installation this way?
Because the failsafe version drops one outside the nix-managed environment, and fixing it does not sound that simple when your only way to get into it is broken.
So, if I use, for example, xonsh
as your shell, make a syntax error in my .xonshrc
, and that .xonshrc
is managed with Nix, fixing it from the recovery env would require detangling some broken symlinks that make no sense to get to either that .xonshrc
or login-inner
.
Ah I get your point, that's indeed tricky.. It's like we should add a flag somewhere, that the app should use /bin/sh
instead of the configured shell. But I don't know, how this should be done..
Give the user the possibility to change the default shell. Changing the value in
/etc/passwd
is not enough, nix-on-droid-app needs to reads this value.