choose shell for item 8 in /usr/local/sbin/opnsense-shell

Started by tessus, January 09, 2026, 12:48:08 AM

Previous topic - Next topic
In the /usr/local/sbin/opnsense-shell script that is used as the shell for the root user, the shell when selecting menu entry 8 is hard-coded to /bin/csh.

I would like to use bash (/usr/local/bin/bash) instead.

Can you please point me to the correct repo for this script so that I can submit a PR? I am thinking of reading a file (e.g. /etc/opnsense-shell) and in case the file exists and has a CMD_SHELL var, it will be used. Otherwise the current default is used. We can discuss the specifics in the PR.

What do you think?

If at all, why not create a setting that is stored in config.xml and can be switched between bash, sh, tcsh and others?
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Yes, this is a very nice idea. However, I am great with backend and scripts, but suck at anything with UI and/or frontend.

To answer your question: I don't know how to do that.

How about adding to root's .cshrc something like e.g.

test -x /usr/local/bin/bash && exec /usr/local/bin/bash -l
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Spawning bash from .cshrc is a rather nasty hack, I'd rather avoid. But that's just me.

The issue is I do not know which files are overwritten when packages are updated, otherwise I'd just update the /usr/local/sbin/opnsense-shell locally. But it is part of the opnsense package, so I think the file is overwritten during every upgrade.
My idea to use an optional file with a CMD_SHELL var in /etc/ or /etc/defaults/ seems the most logical solution that adheres to Unix philosophy. But maybe I am wrong.

I don't really want to discuss this on this forum, since it doesn't understand markup. It's way easier to do that in a PR.

I only needed to know the repo, because I wanted to avoid searching for it on gh, which I have done now. So this topic is now obsolete.



Building a complex solution for a problem that doesn't exist for 99.9% of the users to allow to chose a shell that is not even installed by default in a very tiny shell script that offers a bit of convenience shows how impractical the request is.

Why not set the admin shell to bash? Why not use a separate admin user with bash shell and sudo su for the console menu?  These types of setups have been supported for many years already.


Cheers,
Franco

I don't think that adding one line to a script is a complex solution. What I don't understand is that hardcoding a specific shell is considered the normal way of doing things.

Anyway, if a PR that adds one line to a script won't be accepted, because it is deemed too complex or too high of a maintenance burden there is no need to create one, is there?

Don't get me wrong, I have already used the workarounds you mentioned (all but spawning bash from the .cshrc), but I actually like the menu and overview the opnsense-shell script provides. I'm just not a fan of csh.

Too bad, I guess I will have to patch opnsense-shell every time there is an update.

I just don't think you get away with a one line change because it already indicates that it omits important documentation. If you have a suggestion a GitHub PR is perfect to discuss. Keeping this maintainable for the future may also add a line of code or two. People will use it and forget and run into issues and report them here in years to come. We need to think about it now.


Cheers,
Franco

Yep, my thoughts exactly (using GH to discuss). And, btw, I am not going to be angry, if a PR is not merged. I just feel more comfortable discussing features and code on GH, since it's a lot easier to reference code.

You know what, I'll open a PR and let's go from there.