From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Date: Mon, 31 Aug 2020 17:58:17 +0300 Message-ID: <83sgc2x3p2.fsf@gnu.org> References: <693aa189-03fa-b963-89eb-ce19c51ba325@cs.ucla.edu> <83wo1jz32t.fsf@gnu.org> <83sgc7z220.fsf@gnu.org> <83r1rryrk0.fsf@gnu.org> <47047d69-91aa-fd0d-1510-64ba7c246970@cs.ucla.edu> <83a6yeynd1.fsf@gnu.org> <03a31052-795a-c169-c199-2b0f3ba88ec2@cs.ucla.edu> <83sgc5xq8k.fsf@gnu.org> <164450fe-7f86-e336-87d4-13c52e52c61c@cs.ucla.edu> <83eenoxm18.fsf@gnu.org> <6acf8cfa-6071-e7b1-3055-04292634bb39@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25855"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 26911@debbugs.gnu.org, mattiase@acm.org, michael.albinus@gmx.de, yegortimoshenko@gmail.com To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 31 16:59:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kClH5-0006cK-Mw for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 16:59:11 +0200 Original-Received: from localhost ([::1]:57058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kClH4-0004kz-O2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 10:59:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kClGw-0004iN-QW for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 10:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41779) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kClGw-0003rY-Hd for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 10:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kClGw-00031x-HM for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 10:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2020 14:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 26911-submit@debbugs.gnu.org id=B26911.159888592211603 (code B ref 26911); Mon, 31 Aug 2020 14:59:02 +0000 Original-Received: (at 26911) by debbugs.gnu.org; 31 Aug 2020 14:58:42 +0000 Original-Received: from localhost ([127.0.0.1]:53322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kClGb-000315-Pd for submit@debbugs.gnu.org; Mon, 31 Aug 2020 10:58:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33134) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kClGY-00030s-QJ for 26911@debbugs.gnu.org; Mon, 31 Aug 2020 10:58:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57435) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kClGT-0003q9-5C; Mon, 31 Aug 2020 10:58:33 -0400 Original-Received: from [176.228.60.248] (port=1344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kClGQ-00056Y-EV; Mon, 31 Aug 2020 10:58:32 -0400 In-Reply-To: <6acf8cfa-6071-e7b1-3055-04292634bb39@cs.ucla.edu> (message from Paul Eggert on Sun, 30 Aug 2020 14:39:28 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186772 Archived-At: > Cc: 26911@debbugs.gnu.org, mattiase@acm.org, michael.albinus@gmx.de, > yegortimoshenko@gmail.com > From: Paul Eggert > Date: Sun, 30 Aug 2020 14:39:28 -0700 > > This bug occurred because file-symlink-p calls expand-file-name which > incorrectly stripped trailing "/." from the file name before checking the file's > status. It is not expand-file-name's job to know about these subtleties. expand-file-name deals only with the syntax of file names. It doesn't know anything about the semantics of "." and ".." except that they can be removed to bring the file name to a standard form. It doesn't know whether a file is a directory or a symlink or something else; it doesn't even care if the file exists. It isn't supposed to hit the disk for its job. It is therefore perfectly valid for it to remove the trailing "/." without appending a slash. If file-symlink-p needs to handle such file names specially, it should do it in its own code. So this job should not be imposed on expand-file-name, and we should remove the code added for that purpose. > > I see no reason to require expand-file-name to preserve the > > trailing slash > > It's required because trailing slash affects how file names are interpreted on > GNU and other POSIXish platforms. It is not the job of expand-file-name to interpret file names. Lisp programs that need a directory's name to end in a slash should call file-name-as-directory, this is why we have that function. If we insist on appending the slash in all cases, then some code will benefit, but other code will break (and will need to call directory-file-name to avoid the breakage). There's no net win here, so we should not do this, either. expand-file-name is simply the wrong place for this kind of functionality, even before we consider its complexity. > > IMO the problem is immediately following the above snippet: > > > > /* Keep initial / only if this is the whole name. */ > > if (o == target && IS_ANY_SEP (*o) && p[3] == 0) > > ++o; > > > > This is very easy to fix without affecting any other uses of the > > function: we should consider one other case in addition to "only if / > > is the whole name" -- the case where this fails to DTRT with remote > > directories. > > Such a fix should be no problem for the GNU/POSIXish side, as that snippet is in > the DOS_NT code and any fixes there should affect only MS-Windows and DOS. I > don't know what a "remote directory" is in that context, though, so I can't give > specific advice. You are talking about the code after your changes, whereas I (and Michael at the time he wrote that) were talking about the code before your changes: then the above snippet affected all platforms. > Right now the code is needlessly hard to understand, and that makes > it hard to fix - something I encountered while trying to fix some of > the abovementioned bugs. It isn't hard for me to understand the current code, although it is indeed complex (because the job it does is not trivial). But the problem is not the complexity, the problem starts when we make changes there which are either not strictly necessary, or affect more use cases than the few we need to fix. That function works, and works well. Let's not make it less dependable than it is today. Anyway, I think I understand all the issues now, so I will work on fixing them soon in a way that will avoid unnecessary fallout. Thanks.