Shells

From the fine manual :
Bourne shell-compatible sh(1) is the default user shell. The root shell is tcsh(1) by default on FreeBSD 13 and earlier and sh(1) on FreeBSD 14 and later.

Using latest 14.1 with most defaults.
Is the ! command (to execute a previous command from the shell history) not implemented in the sh shell ?
Do I miss something in the settings, or what is suggested/preferred workaround ?
Perhaps revert to tcsh instead of sh ?
Any disadvantages ?
Thx for any tips or clues.
 
Perhaps revert to tcsh instead of sh ?
Any disadvantages ?
Yes and No.
I do that right in installer when I drop to shell to finish up.
chsh -s /bin/tcsh user
I don't care for changes in history usage myself.
With sh you need to type a certain numbers of characters for autocompletion.
How is that better?
 
or what is suggested/preferred workaround ?
Cursor up, return

A lot of the funny special characters used in CLI programs and their components (like readline), such as control-H, J, K, L, exclamation mark, and so on, are remnants from when (serial-connected-) terminals had only alphabetic characters, plus shift and control.
 
Thanks for all the above. I often like to use :
# or $ : history | grep something, and then !number to repeat some command/s.
Personal preference is such a beautiful thing.
I'll change back to tcsh and see how it goes.
 
Advantage of ralphbsz's suggestion: You'll still use a POSIX-compliant shell. Shell scripts should always use POSIX-compliant syntax (for portability, to avoid confusion), so using something different as your interactive shell forces you to always remember the differences...

I think the C shell (implemented by tcsh) should completely vanish from base, it's not required for a complete and self-contained base system. People who want a C shell can install the (then resurrected) shells/tcsh port, like any other shell. BSD traditionalists might disagree.
 
[…] Is the ! command (to execute a previous command from the shell history) not implemented in the sh shell ? […]
?‍? I’ve looked it up again. POSIX™ defines no command ! to refer to “execute the last command”. ? Look, just logically speaking, this adds extra complexity: implementations would have to decide whether ! is the unary negation operator or referring to some history magic. POSIX™ remains rather spartanic.

What’s not implemented is the ! history number expansion in the $PS1 prompt, so you need to learn the commands’ serial numbers by other means. ☹️
[…] what is suggested/preferred workaround ? […]
It’s no workaround, since you do not work … around anything, but define an alias (since fc is a builtin(1)):​
sh:
# r like re-do
alias r='fc -s'
 
BSD traditionalists might disagree.
I wouldn't call me a 'traditionalist', but I disagree.
I've started to use sh and bash more the last couple of months. And I don't feel comfortable using it.
I'm not talking scripting, I'm talking using the CLI.

I'm doing nearly (allmost) all my stuff in the shell, TUI not GUI user, and find tcsh is quicker, shorter, more efficient in everyday's all tasks CLI usage, while to me sh/bash seems a bit more complicated, too long-winded, and bloated for everyday's CLI usage.
When you - the 'royal you', not you - do most of your stuff within GUI, you may not feel it, since you don't need to care about the shell's usage efficieny much anyway.
But shell-users do. A lot.
If you're used to tcsh's history usage and completion, you find sh/bash's way slow, complicated, so inefficient, and annoying.
 
I'm personally using zsh, which is most likely the "fattest" among the (optionally) POSIX-compliant shells. I've never had any complaints about performance or resource usage, it just works, and it works fast. It's so extremely customizable, I wouldn't claim to even understand all the possible options "only" around handling history, still it does exactly what I want. I'd be very surprised if you'd find some tcsh feature in that area that zsh can't provide in the same way.

But hey, as long as you don't mind the inconsistency between interactive and scripting use (as well as some general shortcomings of the C shell language, e.g. regarding file descriptors and redirects), that's good for you. ;)
 
I'm personally using zsh, which is most likely the "fattest" among the (optionally) POSIX-compliant shells. I've never had any complaints about performance or resource usage, it just works, and it works fast. It's so extremely customizable, I wouldn't claim to even understand all the possible options "only" around handling history, still it does exactly what I want. I'd be very surprised if you'd find some tcsh feature in that area that zsh can't provide in the same way.

But hey, as long as you don't mind the inconsistency between interactive and scripting use (as well as some general shortcomings of the C shell language, e.g. regarding file descriptors and redirects), that's good for you. ;)
eval "$(fzf --zsh)" it is amazing.
 
as long as you don't mind the inconsistency between interactive and scripting use
Yes, I agree.
If one is really fond with using the CLI more scripting-like, doing long, 'complicated' one-liners as every-task usage, and working a lot with shell's variables directly in the CLI, you better have a consistency.

It just feels to me, for the 'little things' which are most of my tasks, tcsh is easier/quicker to use than sh/bash.
After all it's a combination of personal taste, personal workstyle, and what one is used to.

I'm always open to be convinced by reasons, arguments, facts, and willing to change, and learn.
But I am also very sensitive about when time-honoured, well-tried standards shall be changed just because of 'it's just old fashioned tradition, only' - You, zirias@ didn't say so, nor ment it that way. You argument with facts, and reasons. I ment it generally - or: 'Everybody else is doing it otherwise.' Those are no reasons.

If what the majority does was best choice, we all use Windows, or maybe Ubuntu, only.
(You may also know the saying 'eat more shit; billions of flys cannot be mistaken.')
And to me this sh/bash topic sometimes smells a bit like that.
So I may be a bit sensitive about to preserve 'my' tcsh :cool:.
 
I personally wouldn't recommend using a POSIX incompatible shell (which btw also includes the recently quite popular fish) because I think it just avoids confusion when there's one syntax for everything, but you're free to prefer otherwise of course.

Just to give some more background on this:
But I am also very sensitive about when time-honoured, well-tried standards shall be changed just because of 'it's just old fashioned tradition, only'
In general, in the BSD world, we're very careful with changes, nothing is changed just for the sake of it. Still some changes just make sense. I can see mainly two reasons why tcsh is in FreeBSD's base:
  • C shells traditionally "always" came with BSD systems. Well, this one has no technical merit, so I'd argue we can disregard it. And the shell POSIX standardized is based on bourne (which had some technical reasons of course), so every compliant system needs such a shell anyways, typically in /bin/sh.
  • This /bin/sh in FreeBSD lacked almost any "interactive" features for a long time, to the extent of being practically unusable, while tcsh was always a pretty "comfortable" implementation of the C shell. With improvements to /bin/sh, this isn't an issue any more. It still doesn't have any "fancy" features, but certainly enough to make it usable, and the main purpose of having an interactive shell in base is to enable disaster recovery, for which it is certainly fit now, also reflected by the change of the default shell.
So, my argument is simply: We don't need tcsh (anymore) in base, and base should be kept somewhat minimal. This should certainly not mean to "ban" tcsh, there once was a port, and if it's really removed from base, of course the port should be resurrected.

Another btw, there's similar reasoning around sendmail in base. While it was necessary for a long time, it isn't necessary anymore nowadays, so I'd be in favor or removing it from base.
 
Thank you, zirias@
That's a good example why I value your posts:
You take the time to explain things comprehendable while elaborated, and summerized in a nutshell at the same time.

Also
In general, in the BSD world, we're very careful with changes, nothing is changed just for the sake of it.
is a very important sentence, fortify my confidence in FreeBSD.
 
I personally wouldn't recommend using a POSIX incompatible shell (which btw also includes the recently quite popular fish) because I think it just avoids confusion when there's one syntax for everything, but you're free to prefer otherwise of course.
I do all my work on my server from the CLI. I only use the GUI on my desktop machine (a Mac), and there mostly to run applications, such as mail, web browser, and technical things such as PC board layout or PDF file editing. But even on the Mac, I always have a shell window open, which I use for file management and navigation. For example, if I want to look at my most recent tax return, I would say "cd ~/Personal/Taxes/2023; ls; open form_1040.pdf".

I started with (t)csh when I first met Unix machines, in the late 80s, because most of then were BSD-based. But I knew from the start that writing scripts in csh is not good; that's why I switched to using (ba- or k-) sh in the 90s, when I used Unix machines intensely. I wanted the same syntax and semantics in scripts as on the command line. I regularly write somewhat complex 1-liners on the command line, and it's not unusual to see something like "find ... | grep ... | sed ... | awk '{...}'" with a 4-line awk script that transforms the input and prints totals.

I have friends who still swear by using tcsh on the command line, and they are very good at writing (ba-) sh scripts. I have friends who swear by using the Motif window and file manager, and on their desktop machine hardly ever need a shell window. I know there are a lot of styles of using computers, and tradition and having lots of practice is an important driver of how to do things.

For that reason, I think it would be a reasonable choice to leave tcsh (and sendmail) in base for several years (perhaps 5 or 10), so those people who have gotten accustomed to using them are not inconvenienced, and can rely on the better testing and easier integration of having them in base. But I also understand if the limited volunteer hours need to be used for something more important.
 
Back
Top