svn commit: r343416 - head/bin/sh

Edward Napierala trasz at freebsd.org
Fri Jan 25 12:41:23 UTC 2019


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.  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) '$'
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.

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

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

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

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

> 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 :-)


More information about the svn-src-all mailing list