svn commit: r343416 - head/bin/sh

[Rodney W. Grimes]

> 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
> > > > > URL: https://svnweb.freebsd.org/changeset/base/343416
> > > > >
> > > > > Log:
> > > > >   Install .shrc for root, and set PS1 for the toor account.
> > > >
> > > > And a dozen other aliases :-(
> > >
> > > Six, and they are exactly the same as for ordinary users.
> >
> > Your right, I drifted to hyperbolie on that,
> > but 1 is too many in this case.
> 
> Okay, I don't have a problem with removing the default aliases.
> (And from all the aliases that are actually there in the default shrc,
> the only one I actually do like and use is "ll").
> 
> > > But yeah, I can see the point of not defining any aliases
> > > by default for the root user.  Would the change be acceptable
> > > if the aliases were commented out?  This would be still quite
> > > close to the situation for csh.
> >
> > There is also the issue that we are now going to open 1
> > more file every time an interactive /bin/sh is spawned,
> > and that file is full of comments, to me thats a waste
> > of cycles for probably 95% of the systems out there.
> 
> True, but I don't think that's even measurable, at least for
> interactive shells (as opposed to shells used to run scripts,
> for which the commit changes nothing).
> 
> > 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.

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

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

> 
> > > > Please do not contaiminate the prestine environment with
> > > > personal preferences.  In the start of the project we
> > > > did a great deal of work to remove and eliminate these
> > > > types of things, only the few csh aliases where retained.
> > >
> > > Indeed, and those are pretty much the same aliases.
> >
> > But those alias have never been there for sh, the few
> > we did keep was for historerical history, they had been
> > in roots .cshrc for a decade and people got upset when
> > we tried to remove them, thus we settled on just the
> > few people stated as being the most wanted and used.
> 
> They are there in share/skel/dot.shrc, just not for root.
> But again - I agree regarding the aliases.
> 
> > 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 ~.

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

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

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.

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

> 
> > And FYI, the $ prompt from a unix /bin/sh predates VMS
> > by a decade or so, so VMS copied unix on that one.  And
> > historically interactive prompts have been 1 character
> > since.. well.. interactive prompts appeared.
> >
> > .
> > .
> > .r pip/l
> > I miss my OS/8 ".".  :-)
> 
> Well, back them it could actually make a lot of sense; with
> a hardcopy terminal the "." prompt is just easier to ears :-)

-- 
Rod Grimes                                                 rgrimes at freebsd.org