From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 15ED93858C78 for ; Fri, 14 Apr 2023 22:00:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 15ED93858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 6F37933E60; Fri, 14 Apr 2023 18:00:46 -0400 (EDT) Received: from naga.localdomain (62-47-129-209.adsl.highway.telekom.at [62.47.129.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id A51BA33E6E; Fri, 14 Apr 2023 18:00:45 -0400 (EDT) Date: Sat, 15 Apr 2023 00:00:44 +0200 (CEST) From: Gerald Pfeifer To: Sandra Loosemore , Joseph Myers cc: Joel Sherrill , gcc@gcc.gnu.org Subject: Re: "file name" vs "filename" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1988945704-1681509612=:4410" X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1988945704-1681509612=:4410 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Sun, 1 Apr 2018, Sandra Loosemore wrote: >> Our docs currently are about even and I think it would be good to >> settle on one? >> >>   % grep "filename" $GCC/gcc/doc/*.texi | wc -l >>   92 >>   % grep "file name" $GCC/gcc/doc/*.texi | wc -l >>   103 >> >> (Once we have consensus, I'll add that to codingconventions.html >> and start by making the web pages consistent.) >> > The C and C++ standards documents use "file name"; there are other places > ("bit-field") where the GCC manual has adopted the C standard terminology. > > In this case it might be more appropriate to adopt the POSIX conventions, > since I suspect most of the uses in the GCC documentation refer to the host > environment rather than the target language. This looks like the POSIX > glossary: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html > > Here "filename" is given as the correct spelling, except that that glossary > distinguishes between "filename" and "pathname" (a "filename" is the same as a > "pathname component"). So perhaps many of the "file name"/"filename" uses in > the GCC manual ought to be "pathname" instead? On Mon, 2 Apr 2018, Joseph Myers wrote: > See the GNU Coding Standards: > > Please do not use the term ``pathname'' that is used in Unix > documentation; use ``file name'' (two words) instead. We use the term > ``path'' only for search paths, which are lists of directory names. Based on this it appears "file name" is the one to follow, so I went ahead and documented this at https://gcc.gnu.org/codingconventions.html with a patch at https://gcc.gnu.org/pipermail/gcc-cvs-wwwdocs/2023/010210.html . Should we strive to use pathname (or path name) more broadly as Sandra wondered? I'm a bit hesitant... My next step is updating wwwdocs to consistently use "file name. Thoughts? Gerald --8323328-1988945704-1681509612=:4410--