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

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 …




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):
– cherry picked from <https://cgit.freebsd.org/src/commit/?id=b315a7296d2a69883c483d79dfcb3860a0428f21>.
 
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?
 
… 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.
 
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).
 
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.
 
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.
 
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.
 
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 ?
 
… 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.
 
… 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:
 
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.
 
...
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.

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".
 
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
Code:
[\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
 
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.
 
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.
 
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? :D
 
Back
Top