svn commit: r342881 - head/share/skel

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Fri Jan 11 18:35:32 UTC 2019


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

# cd /tmp
# mkdir a
# cd a
# ln -s /usr/src
# ls
src
# cd src
# pwd
/tmp/a/src
# ls ..
bin                     lib32                   local                   sbin                    src-bhyve.8             src-structvm
include                 libdata                 obj                     share                   src-maxcpus             src-structvmaccessor
lib                     libexec                 ports                   src                     src-maxcpusDS           tests
# cd ..
# ls
src
# 

OMG, where did my system go????  :-)

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-head mailing list