svn commit: r342881 - head/share/skel

[Rodney W. Grimes]

> ?r., 9 sty 2019 o 16:41 Rodney W. Grimes
> <freebsd at pdx.rh.cn85.dnsmgr.net> napisa?(a):
> >
> > > Author: trasz
> > > Date: Wed Jan  9 11:04:27 2019
> > > New Revision: 342881
> > > URL: https://svnweb.freebsd.org/changeset/base/342881
> > >
> > > Log:
> > >   Make sh(1) recognize the default $HOME.  By default /home
> > >   is a symlink; without this change, when you log in, sh(1)
> > >   won't realize the current directory (eg '/usr/home/test')
> > >   is the same as $HOME ('/home/test').
> >
> > Arguably it shouldnt know any of that.
> 
> sh(1) needs to know that in order to properly shorten the current
> directory path (in prompt) to "~" when you're there.

And imho it should not be doing that....
that is what leads to all this other un needed cruft.

~ is a human input shortcut, not a computer output shortcut

> 
> > Or that $Home is ~ either
> > I hate that if I "cd home" and there is not a directory
> > where I am at called home it takes me to ~/$home,s
> > that also has caused a few script debugging to be
> > a royal Pita having to force ./$variable to stop
> > home from being treated special.
> 
> But none of that seems related to the change above, does it?
It is all related as this is outgrowth of trying to make
the prompt spit out ~ when you are in $HOME.

> All the patch does is: if your current directory is $HOME, but
> it's spelled differently, run "cd".  The only thing that does, in turn,
> is making sh(1) set the $ENV variable, which it uses to track
> the current "logical working directory", eg /home/test. It cannot
> obtain that information otherwise, because getcwd(3) in that
> directory returns its "physical path", eg /usr/home/test.

It SHOULD spit out the results of getcwd and not some
logical interpretation of variables.  Do any OTHER cd's
through a symbolic link do such magic?

-- 
Rod Grimes                                                 rgrimes at freebsd.org