svn commit: r342881 - head/share/skel

[Ian Lepore]

On Fri, 2019-01-11 at 10:35 -0800, Rodney W. Grimes wrote:
> > On Wed, 2019-01-09 at 10:08 -0800, Rodney W. Grimes wrote:
> > > > ?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?
> > > 
> > 
> > ALL cd's through a symlink "do such magic". It's the difference
> > between
> > physical and logical path in bourne shell (and its descendents).
> > 
> >    revolution > mkdir /tmp/ian
> >    revolution > cd /tmp/ian
> > 
> >    revolution > mkdir -p a/b/c
> >    revolution > ln -s a/b/c c
> > 
> >    revolution > cd /tmp/ian/a/b/c; pwd -L; pwd -P
> >    /tmp/ian/a/b/c
> >    /tmp/ian/a/b/c
> > 
> >    revolution > cd /tmp/ian/c; pwd -L; pwd -P
> >    /tmp/ian/c
> >    /tmp/ian/a/b/c
> > 
> >    revolution > cd /tmp/ian/a/b/c; cd ..; pwd -P
> >    /tmp/ian/a/b
> > 
> >    revolution > cd /tmp/ian/c; cd ..; pwd -P
> >    /tmp/ian
> 
> The whole concept of logical cd/pwd is broken
> because it only works with cd, if you start
> to do ls and other commands the consistency
> of things like .. goes out the window!
> 
> 

What you seem to be implying is some kind of bug is what I consider to
be one of the strongest features of logical vs. physical paths in
bourne shell. Those of us who use it understand its behavior and work
with it instead of complaining about it. People who believe otherwise
tend to use other shells, I suspect.  Everybody wins.

-- Ian