Date: Wed, 09 Jan 2019 11:55:33 -0700 From: Ian Lepore <ian@freebsd.org> To: rgrimes@freebsd.org, Edward Napierala <trasz@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r342881 - head/share/skel Message-ID: <8065ff94389d86d5c427e5cca14af3a37311fa0e.camel@freebsd.org> In-Reply-To: <201901091808.x09I81S1009440@pdx.rh.CN85.dnsmgr.net> References: <201901091808.x09I81S1009440@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-01-09 at 10:08 -0800, Rodney W. Grimes wrote: > > ?r., 9 sty 2019 o 16:41 Rodney W. Grimes > > <freebsd@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 -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8065ff94389d86d5c427e5cca14af3a37311fa0e.camel>