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.
Said and done. Mark Solved. Report any further discussion as excessively off-topic, grahamenrri.
github.com
/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 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.
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.
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.
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.Well, to quote Confucius, "I am one who is fond of antiquity, and earnest in seeking [knowledge] there".
[\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;dI 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.
This is nice, mind sharing the link to the PR?
