Date: Fri, 25 Jan 2019 03:24:39 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Edward Tomasz Napierala <trasz@freebsd.org> Cc: rgrimes@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r343416 - head/bin/sh Message-ID: <201901251124.x0PBOd7i088150@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20190124224554.GA23558@v2>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > 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. 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. > > > 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. 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. 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". > > > 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? 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 ".". :-) -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201901251124.x0PBOd7i088150>