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



## trev (Sep 22, 2021)

For those who would not otherwise see it - From the FreeBSD Current mailing list:



> Date: Wed, 22 Sep 2021 10:36:45 +0200
> From: Baptiste Daroussin <bapt@FreeBSD.org>
> To: current@freebsd.org, arch@FreeBSD.org
> Subject: [HEADSUP] making /bin/sh the default shell for root
> ...


----------



## SirDice (Sep 22, 2021)

It's a good thing those improvements have been made because the current sh(1) is rather spartan when it comes to interactive use.


----------



## eternal_noob (Sep 22, 2021)

Finally.
Csh Programming Considered Harmful


----------



## SirDice (Sep 22, 2021)

eternal_noob said:


> Finally.
> Csh Programming Considered Harmful


Nobody used or uses csh(1) for scripting. That's not even a debate. Root's default shell has nothing to do with this either.


----------



## zirias@ (Sep 22, 2021)

> Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!



Kind of funny, this anticipation of zealots  pkg-base is probably sooo far 



SirDice said:


> Nobody used or uses csh(1) for scripting. That's not even a debate.



Uhm … I've even seen it here on the forums.


----------



## kpedersen (Sep 22, 2021)

"as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh."

This is a bit of a poor argument. There are so few unix platforms left that FreeBSD pretty much gets to make its own rules these days


----------



## zirias@ (Sep 22, 2021)

IOW screw POSIX


----------



## SirDice (Sep 22, 2021)

Zirias said:


> Uhm … I've even seen it here on the forums.


I meant in the OS. None of the scripts are csh(1), they're all sh(1) scripts.


----------



## obsigna (Sep 22, 2021)

In the last days, I ran through a major overhauling of my websites, and I used sed(1) for batch changing/adding/deleting tags and attributes of hundreds of pages. I became tired of figuring out what's the escape sequence for example of \" in tcsh, and initially I entered sh(1) before sediting. Lately, I abandoned tcsh and switched to bash. Look, I tried hard to stay away from this GNU stuff, but tcsh is simply a PITA when it comes to more sophisticated commands.


----------



## Geezer (Sep 22, 2021)

Default shell: sh
Default editor: ee


----------



## a6h (Sep 22, 2021)

I've been using sh(1) with "-o vi" option for a long time. Recently, I've changed my default (Normal user) to the ksh(1). In short, I think the proposal is a good one.

Back in the FreeBSD 6.2, I was using tcsh(1) for a short period of time. I had this false impression that it must have something to do with C language. I was wrong!


----------



## Jose (Sep 22, 2021)

Zirias said:


> IOW screw POSIX


1996 called. They want their headline back.

I tried to like tcsh(1) and then I discovered that you can't redirect stderr by itself. So the very common idiom I use `2> /dev/null` is simply not possible without an ugly hack that's impossible for me to remember.


----------



## sidetone (Sep 22, 2021)

I rather the default stay with csh than sh, or it use mksh or another implementation of ksh.

I need auto-completion for some commands.


----------



## Jose (Sep 22, 2021)

sidetone said:


> I rather the default stay with csh than sh, or it use an implementation of mksh.
> 
> I need auto-completion for some commands.


That has been added to sh(1) as Baptiste's email notes.


----------



## sidetone (Sep 22, 2021)

I have to see it first. sh had history, where I can use an arrow key, but it toggled through the whole history, instead of starting at those that matched the first typed letters.

I'm more comfortable with mksh or another ksh than anything else.

When I used mksh as default, I had to remember to reinstall it when I upgraded, or I wouldn't be able to make fixes or would have problems continuing setting up. I stick with csh, because of this.


----------



## zirias@ (Sep 22, 2021)

Jose said:


> 1996 called. They want their headline back.


Just in case, that was sarcasm. POSIX mandates /bin/sh is a bourne shell. So making it also the default shell for root is kind of what you'd expect.


----------



## SirDice (Sep 22, 2021)

sidetone said:


> sh had history, where I can use an arrow key, but it toggled through the whole history, instead of starting at those that matched the first typed letters.


History isn't (or wasn't) persistent either. Not sure what "support for history as described by POSIX." actually means. Does that include persistent history?


----------



## sidetone (Sep 22, 2021)

SirDice said:


> Does that include persistent history?


I don't know.

When I type in complex commands for csh or mksh, I can type part of it, then use my arrow keys to get auto-completion or history that starts with the matches of what I typed this time.

I tried sh again just now, and while I can type part of a command, my arrow key scrolls though all recent commands, regardless of what I typed.

When I'm using ImageMagick, I need to scroll from the point of a typed prefix to make minor adjustments, which is further back in history, than other commands. Also for any other command.


----------



## Deleted member 30996 (Sep 22, 2021)

kpedersen said:


> "as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh."
> 
> This is a bit of a poor argument. There are so few unix platforms left that FreeBSD pretty much gets to make its own rules these days


But, Mom, everybody's doing it...


----------



## zirias@ (Sep 22, 2021)

I didn't even know POSIX described a history feature. But I'm a bit amused by the expectation that people would go bananas if removal of tcsh from base might be discussed 

What a base system needs is a bourne shell. What it also needs is a (somewhat) comfortable interactive shell, cause there are situations when base is all you have at hands. So far so good. Making FreeBSD's /bin/sh more comfortable sounds like a nice idea to me. So you *might* think that tcsh *might* become superfluous. Haha…

Even then, what's the problem? You can use any shell you like anyways, and if you want a non-base shell for root, that's what the "toor" alias is for.


----------



## gpw928 (Sep 22, 2021)

I don't really think it matters what shell is assigned by default to the root account.
I have lived with `csh` there for a very long time, and managed to ignore it completely (at an ongoing cost of maintaining my own copy of `/bin/ksh`).
Opinions will vary on the most suitable replacement, and many will be dissatisfied, no matter what is chosen.
I have observed, several times, that I don't want to be using a strange shell with strange syntax (and desperately needing to refer to `man csh`) when the chips are down.
So I do think it matters (a lot) what shells are available for use in single user mode with the base system installed.
BSD systems have a very long history of using `csh` for root, but I do believe that `csh` has fallen into disuse (for good reasons).
Every other Unix variant I can think of uses a Bourne compatible shell for the root account (`bash`, `dash`, `ksh`, to mention a few).
So, I think a Bourne compatible shell is a good idea, but I'm not going to fight for any particular one.
Back when an RL02 disk was 10 MiB, limiting the size of the root was mandatory.  These days 100 GiB thumb drives can be had for $20.
I would fight to see a raft of common shells available in single user mode, so `exec /bin/ksh` or `exec /bin/bash` just rolled off the fingers...


----------



## leebrown66 (Sep 23, 2021)

Personally I find it incredibly confusing to have to use one syntax for interactive use and a different syntax for scripting.


----------



## rustbucket (Sep 23, 2021)

leebrown66 said:


> Personally I find it incredibly confusing to have to use one syntax for interactive use and a different syntax for scripting.



I 100% agree.

Even though I know both well, I unintentionally swap things; it gets a little annoying.


----------



## astyle (Sep 23, 2021)

Personally, I'm happy with sh(1) being the default right now. Yeah, it's a bit spartan, but that's the idea - I think you gotta keep it simple as much as practical. Other shells are actually available in ports, they can be installed on an 'as needed' basis to suit user preferences.


----------



## unitrunker (Sep 23, 2021)

If 'root' defaults to tcsh and 'toor' defaults to bash, how about 'otro' defaults to 'sh'?


----------



## astyle (Sep 23, 2021)

unitrunker said:


> If 'root' defaults to tcsh and 'toor' defaults to bash, how about 'otro' defaults to 'sh'?


Why the palindromes anagrams?

We can also add 'troo' for ksh and 'roto' for zsh, while we're at it


----------



## vermaden (Sep 23, 2021)

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.


----------



## mrbeastie0x19 (Sep 23, 2021)

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.


----------



## zirias@ (Sep 23, 2021)

mrbeastie0x19 said:


> never understood why there is csh AND tcsh (these are the same right?)


On FreeBSD, yes. Tcsh is just an improved C shell, and a C shell is canonically named csh, so csh is just an alias name here.

Pretty similar to what many GNU systems do, they make /bin/sh an alias for bash (which is technically correct because bash _is_ a bourne shell).


----------



## SirDice (Sep 23, 2021)

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.


----------



## Vull (Sep 23, 2021)

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.


----------



## covacat (Sep 23, 2021)

${#str} works in bash (should be posix)
bash can do some proprietary "expansions" like substring and replace

```
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>
```


----------



## Vull (Sep 23, 2021)

covacat said:


> ${#str} works in bash (should be posix)
> bash can do some proprietary "expansions" like substring and replace
> 
> ```
> ...


Yes, ${#str} is the more portable alternative. My point was that `expr length` doesn't work with /bin/sh on FreeBSD.


----------



## blackhaz (Sep 23, 2021)

vermaden said:


> IMHO as ZSH license is MIT the FreeBSD should import ZSH into FreeBSD base and make ZSH the default shell.


Why not? Only two dependencies (autoconf, automake), 809KB, also the name would play nice along with ZFS. There's something about Z in FreeBSD!


----------



## mer (Sep 23, 2021)

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.


----------



## obsigna (Sep 23, 2021)

vermaden said:


> 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.
> 
> ...


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.

```
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.


----------



## ralphbsz (Sep 23, 2021)

blackhaz said:


> 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.


----------



## ralphbsz (Sep 23, 2021)

obsigna said:


> 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

```
# 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.


----------



## obsigna (Sep 24, 2021)

ralphbsz said:


> 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
> 
> ...


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.


----------



## Beastie7 (Sep 24, 2021)

vermaden said:


> IMHO as ZSH license is MIT the FreeBSD should import ZSH into FreeBSD base and make ZSH the default shell.
> Regards.



I support this message. This is done on macOS too.


----------



## zirias@ (Sep 24, 2021)

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.


----------



## kpedersen (Sep 24, 2021)

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


----------



## Menelkir (Sep 24, 2021)

kpedersen said:


> 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.
> ...


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.


----------



## _martin (Sep 24, 2021)

obsigna said:


> OK, but then please with an easy way of switching off bracketed paste.


Try putting this into ~/.zshrc:   `zle_highlight+=(paste:none)`


----------



## msplsh (Sep 24, 2021)

Vull said:


> I don't really care what the default root shell is


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."


----------



## zirias@ (Sep 24, 2021)

msplsh said:


> 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`


----------



## _martin (Sep 24, 2021)

Zirias said:


> "no, I don't suggest removing it !!!!!111eleven"


I don't know why but when I read that this sketch popped up in my mind immediately.


----------



## rorgoroth (Sep 24, 2021)

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.


----------



## obsigna (Sep 24, 2021)

_martin said:


> Try putting this into ~/.zshrc:   `zle_highlight+=(paste:none)`


This does not disable bracketed paste as such, it disables the visual effect only. See also: https://forums.freebsd.org/threads/bracketed-paste.81314/post-522692

PS: The hacky way of disabling bracketed paste given in said post does work.


----------



## _martin (Sep 24, 2021)

obsigna said:


> This does not disable bracketed paste as such, it disables the visual effect only. See also: https://forums.freebsd.org/threads/bracketed-paste.81314/post-522692
> 
> PS: The hacky way of disabling bracketed paste given in said post does work.


I guess you are right. I was replying in that thread too. But as I had a second look there today it seems memreflect said this and way more before I did reply (not sure why I was replying there then to be honest).


----------



## Geezer (Sep 25, 2021)

grahamperrin said:


> This important proposal deserves focused discussion.
> 
> With respect: arguments about editors are excessively off-topic.



Yes, yes grahamperrin . Not that this is the first thread to go redshift.

Back to focus. The default shell needs to be lean and Bourne. Only sh. Argument finished.


----------



## grahamperrin@ (Sep 25, 2021)

Parallel discussion:

<https://old.reddit.com/r/freebsd/comments/ptnrco/-/>



trev said:


> From the FreeBSD Current mailing list:



<https://old.reddit.com/r/freebsd/comments/ptnrco/-/he7aguy/>


----------



## Deleted member 30996 (Sep 29, 2021)

Geezer said:


> Argument finished.


Said and done. Mark Solved. Report any further discussion as excessively off-topic, grahamenrri.

"The FreeBSD team is planning to change their operating system's default shell. Until recently the default shell for the root account was _csh_, but it is being changed to _/bin/sh_."






						DistroWatch.com: Put the fun back into computing. Use Linux, BSD.
					

News and feature lists of Linux and BSD distributions.




					distrowatch.com


----------



## grahamperrin@ (Oct 20, 2021)

UPDATING <https://cgit.freebsd.org/src/tree/UPDATING?id=6ae38ab45396edaea26b4725e0c7db8cffa5f208#n30>

RELNOTES <https://cgit.freebsd.org/src/tree/RELNOTES?id=1fca3dca2339cceda5efce0d6b87846faac3dba9#n13>


----------



## decuser (Oct 28, 2021)

I agree with astyle... and sh's minimalism is a positive in my book. bash is overkill and I just never really liked ksh, zsh, or csh or their derivatives.


----------



## Oleg_NYC (Jan 2, 2022)

Does the sh shell in the 13-STABLE branch have the same interactive features as the shell in the 14-CURRENT branch?


----------



## grahamperrin@ (Jan 2, 2022)

Switching from <https://cgit.freebsd.org/src/tree/RELNOTES?id=1fca3dca2339cceda5efce0d6b87846faac3dba9&h=stable/13#n13> to *stable/13* continues to show:



> `Release notes for FreeBSD 14.0.`



– so right now, I *don't trust cgit views* of things such as this.

Instead, let's check *GitHub* for the hash that's in the release note …










						sh(1): make it the default shell for the root user · freebsd/freebsd-src@d410b58
					

In the recent history sh(1) has gain the missing features for it to become a usable interractive shell: - command completion - persistent history support - improvements on the default bindings in e...




					github.com
				




It's in the main branch only.

The commit made no mention of MFC. I should not expect the change in any release of 13.⋯. Principle of least astonishment.


Next, maybe check whether sh has changed in stable/13 … <https://cgit.freebsd.org/src/log/?h=stable/13&qt=grep&q=sh(1)> finds (amongst other things): 

sh(1): autocomplete commands (2021-05-05)
– cherry picked from <https://cgit.freebsd.org/src/commit/?id=b315a7296d2a69883c483d79dfcb3860a0428f21>.


----------



## Oleg_NYC (Jan 2, 2022)

So, the "autocomplete commands" feature was backported into the 13-STABLE branch, but some of the improvements to the sh shell still haven't been backported?


----------



## grahamperrin@ (Jan 2, 2022)

Oleg_NYC said:


> … the improvements to the sh …



Any improvement in particular?

If you can suggest a keyword that is likely to be distinctive, seeking that word might find it in the history of commits.

(As an extreme comparison: seeking _sh_ naturally returns a huge number of results.)

Postscript

Sorry, I wasn't thinking straight.

If `/bin/sh` is the relevant part of _the tree_ i.e. `https://cgit.freebsd.org/src/tree/bin/sh?h=releng/13.0`, then <https://cgit.freebsd.org/src/log/bin/sh?h=releng/13.0> might be the answer; nothing more recent than 2020-04-01 2021-01-03. Again, POLA.


----------



## Oleg_NYC (Feb 7, 2022)

I reported this bug about sh: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261728 . If sh is ready for interactive use, why would such a bug still exist in it? Since Ubuntu's dash is also a variant of the Almquist shell, I wonder if it has the same bug.


----------



## ralphbsz (Feb 7, 2022)

You reported the bug in 14, which is not supported in this forum. But: I just reproduced the same bug in 12.3 in /bin/sh.

It would be very helpful if you could narrow the bug down in your bug report: What exactly causes it? My hunch is the presence of metacharacters (in this particular case the parens) that usually need to be quoted. So with much simpler test cases, does the same happen for a single paren? How about for a single greater or less sign, or a space?

The bug is not present in either tcsh (the stock version that ships with the FreeBSD base), or in bash (the standard package, up-to-date). I don't have time to figure out what other shells it exists in (since I don't have any shells other than the base ones + bash installed).


----------



## Alain De Vos (Feb 7, 2022)

Why not make oksh the default shell? It has very little requirements/libraries needed.


----------



## Oleg_NYC (Feb 7, 2022)

ralphbsz said:


> You reported the bug in 14, which is not supported in this forum. But: I just reproduced the same bug in 12.3 in /bin/sh.
> 
> It would be very helpful if you could narrow the bug down in your bug report: What exactly causes it? My hunch is the presence of metacharacters (in this particular case the parens) that usually need to be quoted. So with much simpler test cases, does the same happen for a single paren? How about for a single greater or less sign, or a space?
> 
> The bug is not present in either tcsh (the stock version that ships with the FreeBSD base), or in bash (the standard package, up-to-date). I don't have time to figure out what other shells it exists in (since I don't have any shells other than the base ones + bash installed).


It looks like sh doesn't like the presence of parentheses in filenames and that's why it refuses to tab-autocomplete the files that have them. A year or two years ago, people said that sh couldn't tab-autocomplete commands and I don't recall people saying that sh couldn't tab-autocomplete certain types of filenames too.


----------



## ralphbsz (Feb 7, 2022)

Oleg_NYC said:


> It looks like sh doesn't like the presence of parentheses in filenames and that's why it refuses to tab-autocomplete the files that have them. A year or two years ago, people said that sh couldn't tab-autocomplete commands and I don't recall people saying that sh couldn't tab-autocomplete certain types of filenames too.


It's more complicated. I just tried files abc, a(b, a)b and a*b, plus versions where the final "b" is replaced by "x". /bin/sh can autocomplete a(c, but not a)c or a*d. And it's not just the number of special characters, it can correctly autocomplete a(b(c versus a(b(x. There is a bug there, but it's not exactly clear to me what it is. To explore it systematically, you'd have to do a tree search of all strings that have one or more non-alphanumeric characters in them, and that includes special characters. Remember, the only character that does not exist in file names is "nul", all other 255 characters are possible. I have no idea how autocomplete would work with things like newline, backspace, or incomplete unicode sequences in the file name, and testing that would take hours.

Obnoxious side remark: I used to implement file systems for a living. One of the things I learned is that people who put strange special characters into their file names should all be shot. Or at least tickled until they laugh so hard they turn blue in the face. From an implementation point of view, it's trivial to allow people to create abominations like "a-with-accent, newline, i-without-dot-but-with-dot-accent, backspace, *" as a file name. Or the infamous directory whose first two file names are "-R" and "*" (both valid file names!). From a user point of view, these are catastrophically bad ideas.

Anyway, if you can update the bug with some observations of what patterns work and which don't, that may help the developer save some debugging time.


----------



## ralphbsz (Feb 7, 2022)

Alain De Vos said:


> Why not make oksh the default shell? It has very little requirements/libraries needed.


Because /bin/sh has been the default shell for about 40 or 50 years. There are zillions of shell scripts out there which depend on the exact behavior of sh. Sure, if these shell scripts were well-written and portable, they should only depend on the exact behavior that is guaranteed by standards or traditions, like the POSIX.2 shell, or the 7th edition Bourne shell (the closest thing all Unix variants have to a lowest common denominator). Changing the behavior of the default shell would needlessly break things.

If BSD were not BSD, but a new operating system created from scratch, then using a new shell would be fine. But BSD is BSD because it is standing on a 40- or 50-year tradition of technical excellence. One of those traditions is compatibility.

And given that /bin/sh is in base, it doesn't matter what requirements it has ... they are by definition in base.


----------



## Alain De Vos (Feb 7, 2022)

I agree testing all those scripts with a new shell would be alot of work.

What do you clearly mean by compatibility is a tradition ? And why would oksh be less compatible ?
Wikipedia :
Software compatibility can refer to the compatibility that a particular software has running on a particular CPU architecture such as Intel or PowerPC.
Compatibility has nothing to do with the number of scripts which are written in a certain "flavor" of shell syntax, no ?
Or do you mean scripts should be shell-agnostic , i.e. the lowest functionality, ie the highest probability of undetected errors ?


----------



## grahamperrin@ (Feb 7, 2022)

Alain De Vos said:


> … Compatibility has nothing to do with the number of scripts which are written in a certain "flavor" of shell syntax, no ? …



I'd say, the predominance and continuing dominance of sh, for this type of scripting, makes sh the sanest default; the default that is most likely to be compatible with most scripts.

I say that as someone whose preference is *not* sh.


----------



## grahamperrin@ (Feb 7, 2022)

ralphbsz said:


> … strange special characters into their file names …



Non-printing *U+000B* is my favourite. As a special character, a special snowflake, it caused hours days *months* of entertainment in a Microsoft Access database at the back end of a system that was mission critical to a number of colleagues at a former place of work. 

Whilst I can't _exactly_ recall the ultimately diagnosed cause of these back-end snowflakes (copying from Microsoft Word rings a bell), I certainly _do_ recall the sentiments of end users and me and the other IT support staff. Strange, special, smile-less sentiments. Smile-less until the day when I tired of the endless fannying around, exported from Excel then zapped on a Mac, which forced the snowflake characters to reveal their purdy little faces. 


In other news, the identity of my intentional question mark is no longer a secret, so: 

here's a shameless plug for *ZFS experts* to please cast your eyes over the real problem. TIA.


----------



## zirias@ (Feb 7, 2022)

decuser said:


> I agree with astyle... and sh's minimalism is a positive in my book. bash is overkill and I just never really liked ksh, zsh, or csh or their derivatives.


A bit different for me (I _like_ zsh for interactive use as it's feature-rich and still POSIX/bourne compatible, I don't like incompatible shells like anything csh...), but the conclusion is the same: /bin/sh as default shell is a good choice, and it now has a bare minimum of "interactive comfort" features, so using it won't be a complete PITA. A minimal, standard-conforming shell that's "usable enough" is a perfect choice for the default.


----------



## free-and-bsd (Feb 7, 2022)

Geezer said:


> ...
> Default editor: ee


Very human-like, I would say. OpenBSD install leaves you with ed )) To do them justice, even that much can not be used in that environment.



ralphbsz said:


> Because /bin/sh has been the default shell for about 40 or 50 years. There are zillions of shell scripts out there which depend on the exact behavior of sh. Sure, if these shell scripts were well-written and portable, they should only depend on the exact behavior that is guaranteed by standards or traditions, like the POSIX.2 shell, or the 7th edition Bourne shell (the closest thing all Unix variants have to a lowest common denominator). Changing the behavior of the default shell would needlessly break things.
> 
> If BSD were not BSD, but a new operating system created from scratch, then using a new shell would be fine. But BSD is BSD because it is standing on a 40- or 50-year tradition of technical excellence. One of those traditions is compatibility.
> 
> And given that /bin/sh is in base, it doesn't matter what requirements it has ... they are by definition in base.


Well, to quote Confucius, "I am one who is fond of antiquity, and earnest in seeking [knowledge] there".


----------



## covacat (Feb 7, 2022)

the problem with completion seems to be in libedit which comes from netbsd so blame them 

static const wchar_t break_chars[] = L" \t\n\"\\'`@$><=;|&{(";
patching it to

static const wchar_t break_chars[] = L" \t\n\"\\'`@$><=;|&{()}";
seems to work but it may have side effect (didn't analyzed it too deep)
i tested with the port devel/libedit which has the same problem
i just build the port with the patch and copied the resulting lib to some dir and use LD_LIBRARY_PATH and sh

```
[\t] [ns!root]/usr/ports/devel/libedit#ls file.\(mine\).
file.(mine).1.txt  file.(mine).2.txt
[\t] [ns!root]/usr/ports/devel/libedit#ls file.\(mine\).
file.(mine).1.txt  file.(mine).2.txt
[\t] [ns!root]/usr/ports/devel/libedit#ls file.\(mine\).
file.(mine).1.txt  file.(mine).2.txt
[\t] [ns!root]/usr/ports/devel/libedit#ls file.\(mine\).1.txt
file.(mine).1.txt
[\t] [ns!root]/usr/ports/devel/libedit#ls pkg-
pkg-descr  pkg-plist
[\t] [ns!root]/usr/ports/devel/libedit#ls pkg-
pkg-descr  pkg-plist
[\t] [ns!root]/usr/ports/devel/libedit#ls x\ y\
x y p  x y z
[\t] [ns!root]/usr/ports/devel/libedit#ls x\ y\
ls: x y : No such file or directory
[\t] [ns!root]/usr/ports/devel/libedit#ls 1\ 2\ \{\}\
1 2 {} 3  1 2 {} 4
[\t] [ns!root]/usr/ports/devel/libedit#ls 1\ 2\ \{\}\
ls: 1 2 {} : No such file or directory
[\t] [ns!root]/usr/ports/devel/libedit#ls aaa\;b\;*
aaa;b;c    aaa;b;d
```


----------



## Oleg_NYC (Feb 7, 2022)

ralphbsz said:


> Anyway, if you can update the bug with some observations of what patterns work and which don't, that may help the developer save some debugging time.


I am not that knowledgeable about working with computers, so it would be difficult for me to discover patterns, but I can see that sh doesn't like * and {} too.


----------



## Oleg_NYC (Mar 27, 2022)

Two days ago, pstef himself (yes, the same person who we have to thank for making command completion work) left his comments below my bug report. It looks like he fixed this bug for NetBSD and FreeBSD will cherry-pick this bug fix some time in the future.


----------



## astyle (Mar 27, 2022)

Oleg_NYC said:


> Two days ago, pstef himself (yes, the same person who we have to thank for making command completion work) left his comments below my bug report. It looks like he fixed this bug for NetBSD and FreeBSD will cherry-pick this bug fix some time in the future.


This is nice, mind sharing the link to the PR?


----------



## grahamperrin@ (Mar 28, 2022)

astyle said:


> the link





Oleg_NYC said:


> I reported this bug about sh: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261728 …


----------

