svn commit: r342881 - head/share/skel

[Cy Schubert]

On January 11, 2019 11:38:14 AM PST, Ian Lepore <ian at freebsd.org> wrote:
>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


Not just our Bourne shell IIRC Solaris and others as well.

One should compare this with the folks maintaining ksh93 at att/ast on github. 

-- 
Pardon the typos, small keyboard in use.
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.