svn commit: r343416 - head/bin/sh

[Edward Napierala]

The aliases are gone, let's continue on the remaining bits below.

On 0125T0539, Rodney W. Grimes wrote:
> > pt., 25 sty 2019 o 11:24 Rodney W. Grimes
> > <freebsd at pdx.rh.cn85.dnsmgr.net> napisa?(a):
> > >
> > > > On 0124T1555, Rodney W. Grimes wrote:
> > > > > > Author: trasz
> > > > > > Date: Thu Jan 24 23:34:51 2019
> > > > > > New Revision: 343416

[..]

> > > People that want a Borne shell type interactive shell
> > > invariable choose bash, ksh or some other shell, not
> > > our /bin/sh which is lean mean and a fast machine
> > > because the base system uses it so much.
> > 
> > That's true.  But we discourage using shells from ports/packages
> > as root shell. 
> 
> I am not so sure on that, it use to be more so because /bin/sh
> was statically linked and needed no lib's to run, well that
> is gone out the window.  There is also the issue that other
> shells are installed into /usr/local/bin, which may or may
> not be mounted (less likely now that zfs and be's are all
> the rage.)  Most of the reasons to discourage a pkg root
> shell are now gone.

Yeah.  Still, the commit doesn't make it in any way harder,
and provides a more familiar default.

> > The easiest thing for a new user to do if they want
> > a Bourne-compatible shell for root is to just use chsh(1).  And
> > here's what happens: you get greeted with an alien-looking
> > (new folks usually come from Linux or OSX background) '$'
> If that is alien looking then they need some education on
> how the tool they are using works and how to use it.

It is alien, because it's different from their experience
from other systems they are used to.  Sure, they will know
it is _a_ prompt.  It's just that they'll consider it quite
weird and not very useful, in particular the lack of directory
part.

There's also the consistency argument - our tcsh doesn't use
a plain '%'.

> > prompt.  Which is not a problem, of course, just define PS1,
> > and perhaps some aliases, in a newly created /root/.shrc.
> > Except... that doesn't work, despite the fact that it works just
> > fine for accounts other than root, and that's also how you would
> > fix it with bash.  And then you end up having to read the sh(1)
> > manual page to discover the ENV.
> Or read the .profile of there user account and actually
> understand some of these details.  IMHO this is about user
> education and rather than dumb the system down we should
> try to raise the level of knowledge.

I think this is the main point of disagreement.  Sure, learning
is good, but I'm a big fan of providing useful defaults if possible.
Our default csh prompt - now also used by sh - is a pretty good,
imho.  And it's not just FreeBSD that's been using it (with csh)
for years - Ubuntu comes with something pretty close.

[..]

> > > I am sure there are a few of us around that would actually
> > > like to see the ones left go away and view them as contamination
> > > to what should be the domain of a site administrator or
> > > personal taste.
> > >
> > > Just as some of us would really rather have
> > >         cd home
> > > return the proper error rather than doing some
> > > magic when there is not a ./home to cd into.
> > > And having ls .. ; cd ..; ls give 2 different outputs
> > > is just.. well something that should confuse the
> > > heck out of a new user, yet seems completely fine
> > > to have in the system.  Note the above becomes
> > > a fatal mistake when the second ls is a rm
> > > with wild cards.
> > 
> > That's a historical mistake we can't really fix, I'm afraid,
> > unless we want to break compatibility with other systems.
> 
> I seriously doubt that are a lot of people depending
> on cd home to do what it does, most would be lazy
> like me and type cd ~.

This is somewhat orthogonal to the main topic.  But it's not
about 'cd home' at all; it's the result of an architectural
problem in Unix kernel that most shells try to work around.

> > > Howerver I do understand the need to assist the new person
> > > or less informed that do not pack an emacs size environment
> > > with them that there are nifty things they can do
> > > to make life easier.  Perhaps making more extensive
> > > comments in the skel files, or even adding pointers in them
> > > to a set of /usr/share/example/ files?  Perhaps pointers
> > > in roots .files to the skel files as "for a better example
> > > of what can be done in this file see foo".
> > 
> > I'd expect pretty much every user new to FreeBSD to already
> > know about what they can do with shell files.  And there's
> > plenty of advice for that too, including the sources mentioned
> > by Cy.
> > 
> > There are two things, however: first, they don't neccessarily
> > know about things specific to FreeBSD sh(1), such as requiring
> > the ENV to be set to actually read the ~/.shrc.
> 
> Is that only the freebsd shell, I thought most shells need
> special stuff done to get them to do much more than processes
> .profile.

Bash - which is what I'd expect most new users to have experience
with - reads ~/.bashrc automatically, without the ENV.  (Bash is
somewhat weird, and so the ~/.bash_profile usually sources ~/.bashrc,
but that's unrelated).  Zsh reads ~/.zshrc automatically as well.
So yeah, new users probably don't expect they have to set something
in ~/.profile.

> > And second, it's just nice to new users to make stuff just a tiny
> > bit more familiar looking.  This includes installing the file they can
> > edit (/root/.shrc), and setting the prompt to something that
> > resembles other systems.  That's exactly what we do for csh(1).
> 
> I am ok installing .shrc, I am ok putting a commented ENV in
> /root/.profile to say uncomment this if you want .shrc to be
> read for interactive shells.
> 
> Document document document, but changing the existing very
> long standing behavior in the name of "just nice to new users"
> at the cost of agitating many of the current users is no
> good.

Can the change actually break anything for existing users?
It doesn't affect existing installs.  It doesn't affect people
who run the default root shell (tcsh), nor folks who use shells
from ports/packages.  And it doesn't affect the ones who actually
have their own /root/.shrc to copy over.  My understanding is that
the only ones affected are the current users who depend on _not_
having /root/.shrc despite using sh(1) as their root shell.

And for folks who do have their own tree with their preferred
/root/.shrc to "make distribution" from, it should actually make
their diff to upstream smaller.

> As to prompts, well, those are very personalized things
> and vary more than the colors of bike sheds, best left
> to the site or personal admin.

Again, my arguments for doing this are being more familiar
to newcomers and being consistent with ourselves in the remaining
three cases (csh(1) for both root and non-root users, and sh(1)
for non-root users).

> > > > > This is really the domain of a systems administrator to
> > > > > decide and making work for them to clean this out is
> > > > > not going to make them happy.
> > > >
> > > > Problem is, we're in a strage situation where we ship with
> > > > root shell which is just broken - basic shell syntax doesn't
> > > > work - and the out-of-box alternative provides you with
> > > > a VMS prompt.  Not the best first impression to make, I'd say.
> > >
> > > Huh?  Now I think you have gone off the other end,
> > > would you please explain how some alias in .shrc fix anything
> > > broken with /bin/sh or roots use of it?
> > >
> > > Can you expand on exactly what syntax this commit fixes please?
> > 
> > The way this commit fixes syntax problems of the default root
> > shell (which is csh(1)) is that you can easily change the root shell
> > and end up with something that looks just like before, but this
> > time accepting the Bourne syntax.  That's how it works for non-root
> > users; this commit makes the same apply to root.
> 
> That is not a syntax problem.  That is a difference of the fact that
> roots environment is pretty sanitary and a users is not, and for good
> reason on the former.

It is a syntax problem:

trasz at v2:~ % while :; do date; sleep 1; done
while: Expression Syntax.
do: Command not found.
done: Command not found.

Obviously I'm not recommending changing the default root shell,
but this commit makes it easier for the user to change theirs.

[..]