open https://gitlab.synchro.net/main/sbbs/-/issues/821

If, for some reason, the sysop changes a shell and it's no longer valid, a user will never be able to login. I would suggest that if the user's default shell cannot be found, try changing it to the default classic shell and/or pick the first in the list of shells available, assuming the user has the right privileges for one. This will avoid needlessly disrupting the user's session.

{width=438 height=171}
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5979

This is already how SBBS works: if the user's shell is no longer configured in SCFG->Command Shells (the sysop removed or renamed it), then the user's shell will default to the first configured shell they do have access to.

I think instead you're saying that the actual script file for the shell got deleted or moved?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5980

Yes, the script file got removed but the entry in scfg was still there.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5980

Yes, the script file got removed but the entry in scfg was still there. To clarify I had EOTL_JS in scfg but I deleted the eotl_js.js script. I was unable to login.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5995

This gets kind of convoluted:
1. What if the user only has access to one shell?
2. What if the other shell(s) the user has access to also have load/exec problems?
3. Should we loop forever trying to load/exec the shell or fail of n times for the same shell (keeping track of many attempts per shell)?

This is all getting kind of complicated to work-around a rare sysop-config issue.

As it is, an error is logged and the sysop is notified (hopefully) of the error, right? I think that's good enough.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5995

This gets kind of convoluted:
1. What if the user only has access to one shell?
2. What if the other shell(s) the user has access to also have load/exec problems?
3. Should we loop forever trying to load/exec the shell or fail after n times for the same shell (keeping track of how many attempts per shell)?

This is all getting kind of complicated to work-around a rare sysop-config issue.

As it is, an error is logged and the sysop is notified (hopefully) of the error, right? I think that's good enough.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5996

I would try just the classic shell before giving up. It comes standard with every sbbs setup and even if the sysop does mangle their own shell, classic should be available, at least. I'm not saying try every possible combination just if the code for the classic shell exists and it's accessible then do it.

Sure, it's a sysop induced error but it affects the users.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/821#note_5997

If not, just close it out.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/821
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)