From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Date: Mon, 31 Aug 2020 11:15:35 -0700 Organization: UCLA Computer Science Department Message-ID: 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> <83sgc2x3p2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32540"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 26911@debbugs.gnu.org, mattiase@acm.org, michael.albinus@gmx.de, yegortimoshenko@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 31 20:16:28 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 1kCoM0-0008Mm-5U for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 20:16:28 +0200 Original-Received: from localhost ([::1]:49554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCoLz-00024P-4m for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 14:16:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCoLb-0001wu-Hc for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 14:16:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42102) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCoLa-0004gC-Pa for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 14:16:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCoLa-0007qn-Hy for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 14:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2020 18:16: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.159889774530153 (code B ref 26911); Mon, 31 Aug 2020 18:16:02 +0000 Original-Received: (at 26911) by debbugs.gnu.org; 31 Aug 2020 18:15:45 +0000 Original-Received: from localhost ([127.0.0.1]:53648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCoLI-0007qG-Qo for submit@debbugs.gnu.org; Mon, 31 Aug 2020 14:15:45 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCoLG-0007q3-DN for 26911@debbugs.gnu.org; Mon, 31 Aug 2020 14:15:43 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EE70F1600D4; Mon, 31 Aug 2020 11:15:36 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8j-wxZZgKUvL; Mon, 31 Aug 2020 11:15:36 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F23D31600E2; Mon, 31 Aug 2020 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3M4XM8T9az6R; Mon, 31 Aug 2020 11:15:35 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BF1FB1600D4; Mon, 31 Aug 2020 11:15:35 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: <83sgc2x3p2.fsf@gnu.org> Content-Language: en-US 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:186787 Archived-At: On 8/31/20 7:58 AM, Eli Zaretskii wrote: > expand-file-name deals only with the syntax of file names. Yes, but it does so under constraints imposed by semantics. This is why expand-file-name can't simply remove *all* slashes from file names (which would be just a "syntax" thing, no? :-). On GNU and other POSIXish systems, expand-file-names is entitled to do its syntactic manipulations only because because of the POSIX rules that "." means the working directory, leading "/" means the file name is absolute, trailing "/" means the file name is that of a directory, and so forth. expand-file-name can simplify "/./" to "/", even though it cannot always simplify "/." to "" (and it cannot simply remove *all* slashes :-), because expand-file-name's syntactic manipulations simplify the file name in a safe way that does not change the file name's meaning. (This principle has one well-documented exception for symbolic links that do not point to sibling directories, but that does not overturn the principle elsewhere.) > It is therefore perfectly valid for it to remove the trailing "/." > without appending a slash. Not at all. In many cases that would change the meaning of the file name, and expand-file-name is not supposed to do that. On GNU and POSIXish platforms it is valid to remove trailing "/." in some cases (e.g., "/foo//.") but it is definitely not valid to do it in all cases. > It is not the job of expand-file-name to interpret file names. That depends on what one means by "interpret". It is the job of expand-file-name to simplify file names under standard assumptions consistent with the underlying platform's behavior. If a "simplification" would disagree with the behavior of the underlying platform, that would cause needless confusion and expand-file-name should not do that. > 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. That is a separate point, and is not directly relevant to whether expand-file-name should change a file name's meaning by removing slashes from it. > If we insist on appending the slash in all cases Nobody is insisting on that. All I'm saying is that if the user has put a slash in a file name, expand-file-name should not remove the slash if the removal would change the file name's meaning. This is a simple principle that is easy to explain to users. No other principle would make nearly as much sense. >>> 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. Feel free to alter the code to fix these bugs in a different way. However, I expect any such fix will be simpler if starts with the current code (which fixes the bugs on GNU and other POSIX hosts) instead of with the older code (which does not).