Hi, I had a bug report on my package: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983116
The discussion had reference to this bug here > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776663 Let me share my thought here too ... In very good old days, as long as you keep your root and daemon's account in the default shell (bash?), you didn't have much problem with chsh on user account. I am sure people use to use csh this way. Even then, there were some advocacy to use ksh/bash compatible shell, I suppose, to ensure proper and successful environment variables setteing or something :-) Once people started using X, choosing csh as the login shell via chsh became non- option. But people had false sense that the traditional chsh mechanism is right way to change login shell among bash/zsh (or POSIX shells). Making Xsession.d scripts bash/zsh compatible caused several bugs and their fixes in my im-config package which is a thin glue layer to choose i18n GUI keyboard input mechanism offered by one of several input module frameworks (ibus, fcitx, uim, SCIM, ...). I think the root cause of the problem is we choose to parse these system startup scripts with the shell chosen effectively by chsh command for interactive shell. I mean shell set in /etc/passwd. Before X, as long as we don't change login shell for the root and other daemon program's accounts from bash, we had no problem. With X, we started to say POSIX shell (no csh) should be chosen by chsh. Now we are facing another problem with Wayland and how shell use their startup code. To me, non-interactive shell used by Xsession or and other system configuration should be separately configurable from whatever interactive shell user desired to use in /etc/passwd. /usr/bin/sh should be the one for non-interactive shell but if it is difficult initially, I can live with /uar/bin/bash instead. Until someone with lots of energy and (social and technical) skill decides to work on separating these 2 shells on Debian system, I strongly recommend people to set so- called "login shell" always to /usr/bin/bash. If you want to use other shells (zsh, csh, fish, ...) for INTERACTIVE use, the easiest solution is to set it in your terminal program. Then there is no COMPATIBILITY nor PISIX problem. If you want to use non-bash for SSHed host, I suppose, adding something along the following in ~/.baahrc should be able to set INTERACTIVE login shell to non-bash ones. --- # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac exec /usr/bin/zsh -i --- .... It would be great, if chsh is made to control interactive shell. Until we sort out separation of "non-interactive system configuration shell" and "interactive console shell", there will be bugs caused by the differences even among so-called accepted shells (POSIX). I don't think adding work around will never solve this bug prone situation. This will involve some coordination with systemd/pam things, I don't have high hope and motivation. If anyone does, I will be happy. Until then, all I can say is chsh is a historic tool which has no practical use. Just use basj and use practical solution I mentioned above. Good luck. Osamu
