From owner-svn-src-all@freebsd.org Fri Jan 11 19:38:28 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA501149A882 for ; Fri, 11 Jan 2019 19:38:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BBAD82F6F for ; Fri, 11 Jan 2019 19:38:27 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1547235499; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=LjEZcoWID/iT/6hBgxuPvEnaSAUa0bDAQPRypEISWM2riJ6PD6r45qM5uuQu7H4aQqYYE7UFGMW2l FVrn0i4RtXX5aPGyNX3gcr94JrYMA9v2InkNSkmiLP8W8an0TTQ2/EPknGATrx+eDpPnNw5A+BIVZE VJIEa+AilHXtG2Rvyix8ASA+JsI5/VRkbq+AtEVIM8T1+ASLQ0ROULMOubMdx64vxY/F1B6/0is/LY e7SCpe1s318OPocFnd0HVG830i2nAkGpU8nkEKttUkretgwY+LaATY89PQYv7hwxBwLmvvX2dXyQAc kh7maDPO+aacsICDDxVgyTBBoQJM8gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=Si8pjOCWrUeiqnae4cOLEIaX4eqU+u5Zs/LhtPERRhE=; b=d2KQ4J9wfNYTk57Ycme7XuFMD5OFNLGoHDLlGkDNYyMTlvy3pAs69zt6Eh9FMNYjuEJmDRxWSa24c SU2pVDeTQKTv8Tp++D2pVH6/I6VgmVtK1hZ5fIWjpog4Szu+oj4jqOyZFfWWFYx0GmrrWD7KVXwvXO C72mEjfPBXiRgRsUshQ+iWAXoc5AJWnBnGmefSBPZqGvYU2uO368SVhcBTYf5oBfV2DXTqcwPgMlzf x4+GQKGs6zHr2WIgujEPEy31KmAKUS+GIUMFaqt5wwsBT649e6va2peK0s5x2nh8GMkGc+SIpfWjy8 lC5azJHsEbmv328L+RaqcGVoAPL7DIw== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=Si8pjOCWrUeiqnae4cOLEIaX4eqU+u5Zs/LhtPERRhE=; b=J7fs3X+GJdZD1LMYkpJnu+tyBy13ynkp+NUYr2CnGmvCjBmMT8DX4K6EcKPtTzvhR2KmDx3to+gEl 5B5IdgTd2BPinytb6IVB1/BpQT+xoNiM5O0zfZ41AJYvZ5UZV/Q7m6Y2/C1mg8mll6D1KKLZTlgIzo MljELMyCI9UOA0m5bw4ccUYXFcHNZW3ANTwWN/ihYwqzoa0RE1GRUyTZIqXGLR6qDeczFybeFwn8HT npG4l41p8OD5/BuVmSkIp9s2tf+C9M2lw6HXfq9wTIuwJXQcibdljrrYVIh/g2+ROKIX5BeCY0ZTAM wbpsSBKmUX9ugZjRipV3y/VwpZk+LuQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 7062b2b9-15d8-11e9-8a28-a1efd8da9a94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 7062b2b9-15d8-11e9-8a28-a1efd8da9a94; Fri, 11 Jan 2019 19:38:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x0BJcE28062480; Fri, 11 Jan 2019 12:38:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: svn commit: r342881 - head/share/skel From: Ian Lepore To: rgrimes@freebsd.org Cc: Edward Napierala , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Fri, 11 Jan 2019 12:38:14 -0700 In-Reply-To: <201901111835.x0BIZQZI022410@pdx.rh.CN85.dnsmgr.net> References: <201901111835.x0BIZQZI022410@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1BBAD82F6F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 19:38:29 -0000 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 > > > > 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