From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: expand-file-name, DOS/Windows, and directory separator Date: Tue, 15 Feb 2022 11:39:47 -0800 Message-ID: <87wnhvdim4.fsf@ericabrahamsen.net> References: <87czjodn8m.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26596"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:DKTFfwwG0uGIMk0pkMgj0furJK0= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 15 20:51:13 2022 Return-path: Envelope-to: ged-emacs-devel@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 1nK3qy-0006hL-W7 for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Feb 2022 20:51:12 +0100 Original-Received: from localhost ([::1]:52876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nK3qx-0002Z8-Ve for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Feb 2022 14:51:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nK3g7-0003F3-CJ for emacs-devel@gnu.org; Tue, 15 Feb 2022 14:40:00 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:36512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nK3g5-0007zt-G9 for emacs-devel@gnu.org; Tue, 15 Feb 2022 14:39:59 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nK3g3-0002rC-3g for emacs-devel@gnu.org; Tue, 15 Feb 2022 20:39:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:286346 Archived-At: Stefan Monnier writes: > Eric Abrahamsen [2022-02-15 09:59:53] wrote: >> My reading of `expand-file-name' (I don't really speak C) is that, if we >> run it over a file path produced by an external process on a Windows > > I'll let Eli confirm that this is indeed guaranteed behavior, but I just > want to point out that the GNU convention (which we use) says these > aren't "path"s but "file names". Gotcha, I might have been trying to emphasize that it's the separators I was interested in. Anyway, point taken. Eli Zaretskii writes: >> From: Eric Abrahamsen >> Date: Tue, 15 Feb 2022 09:59:53 -0800 >> >> My reading of `expand-file-name' (I don't really speak C) is that, if we >> run it over a file path produced by an external process on a Windows >> machine -- meaning path strings where the directory separator might be a >> backward slash -- it will normalize that separator to a unix-style >> forward slash. It looks like fileio.c:1247 calls dostounix_filename, and >> I'm assuming that's what that does. >> >> Is that a correct assumption? > > Yes. > >> Can I rely on that behavior? > > I'd rather you didn't. Why do you need such an assumption? Emacs on > Windows can cope with file names that use any style of slashes. This is code dealing with search results in Gnus, and the absolute file names need to be broken up so we can work on their segments. Right now that's done with regexps, which is ugly and fragile, and I'm just looking for the confidence that: (file-name-split (expand-file-name "/")) Is going to return exactly the segments, no more no less, regardless of the system or separator type or whether there are multiple separators in a row, etc etc. No leftover slashes, no empty strings, all that. (Okay empty strings are fine, I guess `file-name-split' always returns one for absolute file names.)