X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org E496E3858C2C
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=tlinx.org
Authentication-Results:	sourceware.org; spf=pass smtp.mailfrom=tlinx.org
Message-ID:	<6123F067.2050505@tlinx.org>
Date:	Mon, 23 Aug 2021 12:00:55 -0700
From:	L A Walsh <cygwin AT tlinx DOT org>
User-Agent:	Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Symlink issue?
References:	<DM8PR09MB7095D974DB3B0E50CDB008FAA5C29 AT DM8PR09MB7095 DOT namprd09 DOT prod DOT outlook DOT com>
	<4438dd5c-3575-4c4a-2ca5-869c2c6e9373 AT cornell DOT edu>
	<2effc267-c2c7-f2e9-e01b-5490f5f37e9e AT towo DOT net>
	<4eb95271-5340-65a3-fb78-3e35271878b3 AT SystematicSw DOT ab DOT ca>
In-Reply-To:	<4eb95271-5340-65a3-fb78-3e35271878b3@SystematicSw.ab.ca>
X-Spam-Status:	No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On 2021/08/21 17:55, Brian Inglis wrote:
> On 2021-08-21 18:40, Thomas Wolff wrote:
> >
> >
> > Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin:
> >> On 8/21/2021 4:15 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin
> >> wrote:
> >>> Hi,
> >>> Please consider the following Cygwin session:
> >>> $ cd ~
> >> I don't know why bash completion suggests something different.  My
> >> guess (and it's only a guess) is that bash completion takes a
> >> shortcut for performance reasons.
---
    cd w/completion uses the physical path because completion
is an external "script", while "cd" alone uses bash's internal
"logical" dir.
 
> > The symlink/.. confusion is a dreadful trap since Unix times.
> > Unfortunately, bash completion does not consider path resolution, so
> > if any, it's a bash completion bug.
---
    Not a bug or trap.  It is a user choice to have 'cd' use logical paths
instead of physical paths, whereas completion uses physical paths.

You can get physical paths w/cd with "set -P", but most people find
logical paths more friendly:

/tmp> ln -s .. foo
/tmp> cd foo            # really cd's into '/'
/tmp/foo> cd ..         # but logically '/tmp/foo'
/tmp> set -P            # turns on physical paths w/cd
/tmp> cd foo            # now cd 'foo' puts you in physical '/'
/> cd -                 # go back to last dir before 'cd'
/tmp> set +P            # turn off physical paths (logical back on)
/tmp> cd foo
/tmp/foo> cd ..
/tmp> rm foo

Or, as previously suggested.  One time usage w/param to 'cd'.
(Don't alias this, would be rather confusing)
>
> Try using cd -P (via alias?) which may resolve physically if it works.
> Otherwise enjoy the quirks of cd via symlinks and .. resolution after.

It's not just '..', but also when you 'cd' into a mounted
file system, then completion and other utils _may_
show you the contents of the dir the file system is mounted on.




-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -