Current proposal to make /bin/sh the default shell for root

As FreeBSD's /bin/sh also supports completion its pointless to stick to TCSH (or CSH) as the default shell. We can keep them in base for historic reasons tho.

TCSH/CSH are terrible for scripting or even many simple 'one liners' in interactive mode fail to work.

I never use them and I always switch to ZSH.

IMHO as ZSH license is MIT the FreeBSD should import ZSH into FreeBSD base and make ZSH the default shell.
Regards.
 
I understand why there are two (because sh is more spartan) but never understood why there is csh AND tcsh (these are the same right?). It's obvious the base system needs a shell, which shell that is quickly descends into a preference. Do we use bash? (no because of the GNU license). What about zsh or ksh? Or any other shell? Might as well pick one and develop it to our needs. I think the issue with outsourcing complex behaviour to the ports and keeping the base as 'spartan' as possible is you risk everything functional being external to FreeBSD. I don't much see the point in that, it's one of the design flaws of linux imo. I do agree with keeping the system compact but it's not like we're running on 8 bit micro controllers, the existence of a decent shell in the base system isn't going to hurt anyone and it's not bulky compile times either.
 
csh(1) was the original shell that came with BSD. At one point (sometime during 4.x I believe) the shell was updated/upgraded to tcsh(1) to include more features. As the tcsh executable is also backwards compatible with csh it doesn't make sense to maintain two separate shells. The same thing is done with bash on RedHat for example, bash is backwards compatible with sh (well, mostly anyway) and so on RedHat /bin/sh and /bin/bash point to the same file.
 
I don't really care what the default root shell is. I often use /bin/sh as root without having to change anything. Just login to a lower level account which has the shell that you want, then enter su -m (short for su -m root), and you're there.

I do this to develop scripts that will run with root privileges, or to preserve my present working directory, or to use environment variables I've exported in ~/.shrc. Otherwise su - will usually suffice.

I've noticed at least one working difference between bash and sh. With bash, I can use leng=$(expr length str) leng=$(expr length $str) to get the length of a string, but with sh, I must use leng=${#str}.

On Debian, /bin/sh is the same as /bin/dash. It's not fully compatible with FreeBSD's /bin/sh, but it's still closer than bash.
 
${#str} works in bash (should be posix)
bash can do some proprietary "expansions" like substring and replace
Code:
z>echo $TERM ${TERM: -2:3}
xterm-256color or
z>echo $TERM ${TERM: 0:5}
xterm-256color xterm
z>echo $TERM ${TERM/color/mono}
xterm-256color xterm-256mono
z>
 
${#str} works in bash (should be posix)
bash can do some proprietary "expansions" like substring and replace
Code:
z>echo $TERM ${TERM: -2:3}
xterm-256color or
z>echo $TERM ${TERM: 0:5}
xterm-256color xterm
z>echo $TERM ${TERM/color/mono}
xterm-256color xterm-256mono
z>
Yes, ${#str} is the more portable alternative. My point was that expr length doesn't work with /bin/sh on FreeBSD.
 
Funny that people actually care. I mean, one isn't actually supposed to login as root are they? You're supposed to use sudo or doas or su, right?

Me, I don't really care what shell is used for root interactive sessions. Any system level scripts should have whatever shebang they need.
As a user, I've been using csh/tcsh for so long I'm used to what I should and shouldn't do in it and it's not a limiting factor in my enjoyment of the system.
Also the proposal will only affect new installs of 14-CURRENT onward and you can always set the shell to what ever you want.
 
As FreeBSD's /bin/sh also supports completion its pointless to stick to TCSH (or CSH) as the default shell. We can keep them in base for historic reasons tho.

TCSH/CSH are terrible for scripting or even many simple 'one liners' in interactive mode fail to work.

I never use them and I always switch to ZSH.

IMHO as ZSH license is MIT the FreeBSD should import ZSH into FreeBSD base and make ZSH the default shell.
Regards.
OK, but then please with an easy way of switching off bracketed paste. I understand why others want/need this, but it breaks my workflow. Over the years I collected a countless number of minutes of system maintenance tasks. The minutes are text files in the form of interactive shell commands. These can be replayed step-by-step by dragging and dropping it line by line from the respective minute file into the Terminal window. Bracketed paste brakes this horribly, and I found no way to disable this with zsh.

Also nice would be the feature to navigate the commands in the history which start with a search term on the current command line. This is a very welcome feature in tcsh.

I do not endorse bash, however, switching off bracketed paste and adding the history-search described above is quite easy - we could use the following directives in .inputrc.
Code:
set enable-bracketed-paste off
"\e[A": history-search-backward
"\e[B": history-search-forward

If something alike would be possible for zsh, then let's go.
 
Why not? Only two dependencies (autoconf, automake), 809KB, also the name would play nice along with ZFS. There's something about Z in FreeBSD!
Why do we care about dependencies, when these are compile-time dependencies, the resulting binary is packaged in the base (so people don't need to recompile it unless thy want to), and the only two dependencies are things that most compilations need anyway?

Anyway, on the topic: I don't care. I can survive in (t)csh, but I don't enjoy it. If FreeBSD people want to include (t)csh for reasons of tradition or compatibility, I have no problem with that. If they switch the default root shell to something else, that is also fine; I can survive in most common shells, and on my systems I change the root shall to something I enjoy anyway.
 
OK, but then please with an easy way of switching off bracketed paste.
I think you can turn off bracketed paste in your terminal emulator. At least iTerm (on a Mac) has that option. Does that fix your problem?

BTW, I do exactly the same thing: I keep log files when doing system administration, and I cut and paste all relevant commands into the log files. My problem is that I have built myself roadblocks: I always record the commands in the format
Code:
# shell_command  # issued by root
# another_command  # Also issued by root
> shell_command  # issued by regular user
Which means that if I paste a multi-line sequence, the commands either are commented out, or consist of a redirect which causes syntax errors. I could start fixing that habit, but I have >20 years of accumulated log files with good comments, and it's too much work to go back and clean them all up.
 
I think you can turn off bracketed paste in your terminal emulator. At least iTerm (on a Mac) has that option. Does that fix your problem?

BTW, I do exactly the same thing: I keep log files when doing system administration, and I cut and paste all relevant commands into the log files. My problem is that I have built myself roadblocks: I always record the commands in the format
Code:
# shell_command  # issued by root
# another_command  # Also issued by root
> shell_command  # issued by regular user
Which means that if I paste a multi-line sequence, the commands either are commented out, or consist of a redirect which causes syntax errors. I could start fixing that habit, but I have >20 years of accumulated log files with good comments, and it's too much work to go back and clean them all up.
I use the Terminal app which comes with the OS, and there is not an option to turn off bracketed paste for a ssh session. Regarding your log-file format, this would be easy to resolve with sed(1).

sed -e 's|^# ||;s| # .*||' -i ".commented" logfile.txt

For more sophisticated regular expression text replacements, I am nowadays more productive using CotEditor on the Mac, because with sed, the shell (specially tcsh) requires funny escapes and I rarely get 'em right all on the first shot.
 
I'd be happier with zsh as well (probably the most feature-rich bourne shell). But IMHO, one dedicated interactive shell for base is enough, so this would mean removal of tcsh instead. Now, if people have strong feelings that a C shell should be present in a BSD for "historic reasons" … 🤷‍♂️

As for compatibility: Both bash and zsh are fully compatible (to bourne/POSIX). They just have additional features, but they can correctly execute a POSIX-compliant shell script. A C shell (or "esoteric" stuff like fish) can't do that.
 
The OpenBSD KSH is also fairly effective.
(https://github.com/ibara/oksh)

But I suppose frankly all of this stuff can be installed from ports. sh and csh are "good enough" in base.

I am also one of those heretics that installs bash(-static) in there anyway ;)
shells/oksh. There's also shells/mksh that it's similar and I like it.
Also, I'm fine with tcsh because I don't do extreme chimichangas as root, but having one of those would be good enough.
 
This is the only real response here, IMO. If you have an opinion, you can just change it. That's the point of the emphasis on "not removing from base."
Well, I have an opinion that a C shell in base is unnecessary 😈 but then, this emphasis on "no, I don't suggest removing it !!!!!111eleven" indicates that many people have strong emotions for keeping it (historical, traditional, ...).

I'm fine with that, I just build with WITHOUT_TCSH=yes 😏
 
I've not read anything other than the first post, so apologies for repeating or missing anything.

I don't mind it, I love tcsh and use it on Linux too for the past decade+ but unless on a very rare occasion like a testing container I do not change whatever the root shell is because I simply do not use it for anything after the initial setup after install. I would however prefer it was available for created users though but it's not a big job installing and changing that after install I guess.
 
Back
Top