From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Dec 2010 21:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 7617@debbugs.gnu.org X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.129210409011119 (code B ref -1); Sat, 11 Dec 2010 21:49:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Dec 2010 21:48:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRXIX-0002tI-OI for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:48:10 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRXIV-0002t3-Li for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:48:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRXOP-0006L0-Dp for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:54:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:38593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRXOP-0006Kp-4a for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:54:13 -0500 Received: from [140.186.70.92] (port=47902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRXON-0003z3-Lc for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRXOM-0006Jw-BY for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:11 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]:46851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRXOL-0006Il-VG for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:10 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBBLs5Yr012919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Dec 2010 21:54:06 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBBLrx8w004678 for ; Sat, 11 Dec 2010 21:54:02 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 866376331292104419; Sat, 11 Dec 2010 13:53:39 -0800 Received: from dradamslap1 (/10.159.220.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Dec 2010 13:53:38 -0800 From: "Drew Adams" Date: Sat, 11 Dec 2010 13:53:38 -0800 Message-ID: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003C_01CB993A.D0BA3C10" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcuZfd3SOme47opfReix3lhmOPcFJw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) This is a multi-part message in MIME format. ------=_NextPart_000_003C_01CB993A.D0BA3C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit emacs -Q (expand-file-name "share/" "~/today//usr/") -> c:/today/usr/share/. (On my Windows laptop, `~' is just `c:/'.) IOW, multiple consecutive slashes are collapsed to one. This is not the behavior I want. This behavior started in Emacs 21; in Emacs 20 no such removal of slashes occurs. I would consider this loss of slashes a bug. But I see that comments in the current C code indicate that it is intentional (but not _why_). I'm not great at reading C code, but I see these comments in the Emacs 24 code: /* We want to replace multiple `/' in a row with a single slash. */ else if (p > nm && IS_DIRECTORY_SEP (p[0]) && IS_DIRECTORY_SEP (p[1])) And later on: /* Now canonicalize by removing `//', `/.' and `/foo/..' if they appear. */ ... /* Collapse multiple `/' in a row. */ In the Emacs 20 C code the equivalent comment says only this: /* Now canonicalize by removing /. and /foo/.. if they appear. */ I don't have C source for Emacs 21, but the behavior of 21 indicates that that is when the change was made, presumably intentionally. I searched the change logs but found no mention of this change or why it was made. Given that the change was presumably intentional (but why?), you might not be disposed to consider this a bug. I imagine you might argue that the second arg to `expand-file-name' in this case is not a valid directory name, so all bets are off wrt the behavior - or something like that. Or perhaps you will argue that `expand*' is supposed to give you a canonicalized file name, and a name such as "c:/today//usr/share/" cannot be said to be canonicalized. IOW, I imagine there can be arguments that defend the current (Emacs 21+) behavior. But shouldn't `expand-file-name' do the right thing if the second arg is in fact `file-directory-p'? For a user on GNU/Linux with $HOME = /home/toto": (file-directory-p "~/today//usr") -> nil, but (file-directory-p "~//usr/") --> t, and we have the same problem: (expand-file-name "foo" "~//usr/") -> "/home/toto/usr/foo" Surely the behavior here is buggy, no? The result should be "/home/toto//usr/foo", I would think. It seems like any special treatment of double slashes should only be an interactive treatment (e.g. ignore or remove everything up to the second consecutive slash). _Why should_ `expand-file-name' collapse multiple consecutive slashes into a single slash? I would start with that questiom. What is the rationale for that Emacs 21 change wrt Emacs 20. In case it helps, I've attached the Emacs 20 code for `expand-file-name'. Finally, I need the Emacs 20 behavior for this for some of my code. If you decide not to change the behavior for this in Emacs, can you suggest a good way (in Lisp) to get the behavior I want - i.e., the Emacs 20 behavior? I can try to work around this by substituting something for multiple consecutive slashes, so that `expand*' won't collapse them, and then substituting back again to get the slashes, but that is a truly gross and fragile hack. I'm open to better suggestions. Thanks. Oh, and another thing. This behavior of `expand-file-name' is not documented. If the decision is to keep this behavior, then the doc should let users know that the function does this. See the doc string - it describes everything the function does (including `.' removal etc.) - except this. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-12-06 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' ------=_NextPart_000_003C_01CB993A.D0BA3C10 Content-Type: application/octet-stream; name="emacs-20-dot-7-expand-file-name.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="emacs-20-dot-7-expand-file-name.c" DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0,=0A= "Convert filename NAME to absolute, and canonicalize it.\n\=0A= Second arg DEFAULT-DIRECTORY is directory to start with if NAME is = relative\n\=0A= (does not start with slash); if DEFAULT-DIRECTORY is nil or missing,\n\=0A= the current buffer's value of default-directory is used.\n\=0A= File name components that are `.' are removed, and \n\=0A= so are file name components followed by `..', along with the `..' = itself;\n\=0A= note that these simplifications are done without checking the = resulting\n\=0A= file names in the file system.\n\=0A= An initial `~/' expands to your home directory.\n\=0A= An initial `~USER/' expands to USER's home directory.\n\=0A= See also the function `substitute-in-file-name'.")=0A= (name, default_directory)=0A= Lisp_Object name, default_directory;=0A= {=0A= unsigned char *nm;=0A= =0A= register unsigned char *newdir, *p, *o;=0A= int tlen;=0A= unsigned char *target;=0A= struct passwd *pw;=0A= #ifdef VMS=0A= unsigned char * colon =3D 0;=0A= unsigned char * close =3D 0;=0A= unsigned char * slash =3D 0;=0A= unsigned char * brack =3D 0;=0A= int lbrack =3D 0, rbrack =3D 0;=0A= int dots =3D 0;=0A= #endif /* VMS */=0A= #ifdef DOS_NT=0A= int drive =3D 0;=0A= int collapse_newdir =3D 1;=0A= int is_escaped =3D 0;=0A= #endif /* DOS_NT */=0A= int length;=0A= Lisp_Object handler;=0A= =0A= CHECK_STRING (name, 0);=0A= =0A= /* If the file name has special constructs in it,=0A= call the corresponding file handler. */=0A= handler =3D Ffind_file_name_handler (name, Qexpand_file_name);=0A= if (!NILP (handler))=0A= return call3 (handler, Qexpand_file_name, name, default_directory);=0A= =0A= /* Use the buffer's default-directory if DEFAULT_DIRECTORY is omitted. = */=0A= if (NILP (default_directory))=0A= default_directory =3D current_buffer->directory;=0A= if (! STRINGP (default_directory))=0A= default_directory =3D build_string ("/");=0A= =0A= if (!NILP (default_directory))=0A= {=0A= handler =3D Ffind_file_name_handler (default_directory, = Qexpand_file_name);=0A= if (!NILP (handler))=0A= return call3 (handler, Qexpand_file_name, name, default_directory);=0A= }=0A= =0A= o =3D XSTRING (default_directory)->data;=0A= =0A= /* Make sure DEFAULT_DIRECTORY is properly expanded.=0A= It would be better to do this down below where we actually use=0A= default_directory. Unfortunately, calling Fexpand_file_name = recursively=0A= could invoke GC, and the strings might be relocated. This would=0A= be annoying because we have pointers into strings lying around=0A= that would need adjusting, and people would add new pointers to=0A= the code and forget to adjust them, resulting in intermittent bugs.=0A= Putting this call here avoids all that crud.=0A= =0A= The EQ test avoids infinite recursion. */=0A= if (! NILP (default_directory) && !EQ (default_directory, name)=0A= /* Save time in some common cases - as long as default_directory=0A= is not relative, it can be canonicalized with name below (if it=0A= is needed at all) without requiring it to be expanded now. */=0A= #ifdef DOS_NT=0A= /* Detect MSDOS file names with drive specifiers. */=0A= && ! (IS_DRIVE (o[0]) && IS_DEVICE_SEP (o[1]) && IS_DIRECTORY_SEP = (o[2]))=0A= #ifdef WINDOWSNT=0A= /* Detect Windows file names in UNC format. */=0A= && ! (IS_DIRECTORY_SEP (o[0]) && IS_DIRECTORY_SEP (o[1]))=0A= #endif=0A= #else /* not DOS_NT */=0A= /* Detect Unix absolute file names (/... alone is not absolute on=0A= DOS or Windows). */=0A= && ! (IS_DIRECTORY_SEP (o[0]))=0A= #endif /* not DOS_NT */=0A= )=0A= {=0A= struct gcpro gcpro1;=0A= =0A= GCPRO1 (name);=0A= default_directory =3D Fexpand_file_name (default_directory, Qnil);=0A= UNGCPRO;=0A= }=0A= =0A= #ifdef VMS=0A= /* Filenames on VMS are always upper case. */=0A= name =3D Fupcase (name);=0A= #endif=0A= #ifdef FILE_SYSTEM_CASE=0A= name =3D FILE_SYSTEM_CASE (name);=0A= #endif=0A= =0A= nm =3D XSTRING (name)->data;=0A= =0A= #ifdef DOS_NT=0A= /* We will force directory separators to be either all \ or /, so make=0A= a local copy to modify, even if there ends up being no change. */=0A= nm =3D strcpy (alloca (strlen (nm) + 1), nm);=0A= =0A= /* Note if special escape prefix is present, but remove for now. */=0A= if (nm[0] =3D=3D '/' && nm[1] =3D=3D ':')=0A= {=0A= is_escaped =3D 1;=0A= nm +=3D 2;=0A= }=0A= =0A= /* Find and remove drive specifier if present; this makes nm absolute=0A= even if the rest of the name appears to be relative. Only look for=0A= drive specifier at the beginning. */=0A= if (IS_DRIVE (nm[0]) && IS_DEVICE_SEP (nm[1]))=0A= {=0A= drive =3D nm[0];=0A= nm +=3D 2;=0A= }=0A= =0A= #ifdef WINDOWSNT=0A= /* If we see "c://somedir", we want to strip the first slash after the=0A= colon when stripping the drive letter. Otherwise, this expands to=0A= "//somedir". */=0A= if (drive && IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= nm++;=0A= #endif /* WINDOWSNT */=0A= #endif /* DOS_NT */=0A= =0A= #ifdef WINDOWSNT=0A= /* Discard any previous drive specifier if nm is now in UNC format. */=0A= if (IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= {=0A= drive =3D 0;=0A= }=0A= #endif=0A= =0A= /* If nm is absolute, look for /./ or /../ sequences; if none are=0A= found, we can probably return right away. We will avoid allocating=0A= a new string if name is already fully expanded. */=0A= if (=0A= IS_DIRECTORY_SEP (nm[0])=0A= #ifdef MSDOS=0A= && drive && !is_escaped=0A= #endif=0A= #ifdef WINDOWSNT=0A= && (drive || IS_DIRECTORY_SEP (nm[1])) && !is_escaped=0A= #endif=0A= #ifdef VMS=0A= || index (nm, ':')=0A= #endif /* VMS */=0A= )=0A= {=0A= /* If it turns out that the filename we want to return is just a=0A= suffix of FILENAME, we don't need to go through and edit=0A= things; we just need to construct a new string using data=0A= starting at the middle of FILENAME. If we set lose to a=0A= non-zero value, that means we've discovered that we can't do=0A= that cool trick. */=0A= int lose =3D 0;=0A= =0A= p =3D nm;=0A= while (*p)=0A= {=0A= /* Since we know the name is absolute, we can assume that each=0A= element starts with a "/". */=0A= =0A= /* "." and ".." are hairy. */=0A= if (IS_DIRECTORY_SEP (p[0])=0A= && p[1] =3D=3D '.'=0A= && (IS_DIRECTORY_SEP (p[2])=0A= || p[2] =3D=3D 0=0A= || (p[2] =3D=3D '.' && (IS_DIRECTORY_SEP (p[3])=0A= || p[3] =3D=3D 0))))=0A= lose =3D 1;=0A= #ifdef VMS=0A= if (p[0] =3D=3D '\\')=0A= lose =3D 1;=0A= if (p[0] =3D=3D '/') {=0A= /* if dev:[dir]/, move nm to / */=0A= if (!slash && p > nm && (brack || colon)) {=0A= nm =3D (brack ? brack + 1 : colon + 1);=0A= lbrack =3D rbrack =3D 0;=0A= brack =3D 0;=0A= colon =3D 0;=0A= }=0A= slash =3D p;=0A= }=0A= if (p[0] =3D=3D '-')=0A= #ifndef VMS4_4=0A= /* VMS pre V4.4,convert '-'s in filenames. */=0A= if (lbrack =3D=3D rbrack)=0A= {=0A= if (dots < 2) /* this is to allow negative version numbers */=0A= p[0] =3D '_';=0A= }=0A= else=0A= #endif /* VMS4_4 */=0A= if (lbrack > rbrack &&=0A= ((p[-1] =3D=3D '.' || p[-1] =3D=3D '[' || p[-1] =3D=3D '<') &&=0A= (p[1] =3D=3D '.' || p[1] =3D=3D ']' || p[1] =3D=3D '>')))=0A= lose =3D 1;=0A= #ifndef VMS4_4=0A= else=0A= p[0] =3D '_';=0A= #endif /* VMS4_4 */=0A= /* count open brackets, reset close bracket pointer */=0A= if (p[0] =3D=3D '[' || p[0] =3D=3D '<')=0A= lbrack++, brack =3D 0;=0A= /* count close brackets, set close bracket pointer */=0A= if (p[0] =3D=3D ']' || p[0] =3D=3D '>')=0A= rbrack++, brack =3D p;=0A= /* detect ][ or >< */=0A= if ((p[0] =3D=3D ']' || p[0] =3D=3D '>') && (p[1] =3D=3D '[' || p[1] = =3D=3D '<'))=0A= lose =3D 1;=0A= if ((p[0] =3D=3D ':' || p[0] =3D=3D ']' || p[0] =3D=3D '>') && p[1] = =3D=3D '~')=0A= nm =3D p + 1, lose =3D 1;=0A= if (p[0] =3D=3D ':' && (colon || slash))=0A= /* if dev1:[dir]dev2:, move nm to dev2: */=0A= if (brack)=0A= {=0A= nm =3D brack + 1;=0A= brack =3D 0;=0A= }=0A= /* if /name/dev:, move nm to dev: */=0A= else if (slash)=0A= nm =3D slash + 1;=0A= /* if node::dev:, move colon following dev */=0A= else if (colon && colon[-1] =3D=3D ':')=0A= colon =3D p;=0A= /* if dev1:dev2:, move nm to dev2: */=0A= else if (colon && colon[-1] !=3D ':')=0A= {=0A= nm =3D colon + 1;=0A= colon =3D 0;=0A= }=0A= if (p[0] =3D=3D ':' && !colon)=0A= {=0A= if (p[1] =3D=3D ':')=0A= p++;=0A= colon =3D p;=0A= }=0A= if (lbrack =3D=3D rbrack)=0A= if (p[0] =3D=3D ';')=0A= dots =3D 2;=0A= else if (p[0] =3D=3D '.')=0A= dots++;=0A= #endif /* VMS */=0A= p++;=0A= }=0A= if (!lose)=0A= {=0A= #ifdef VMS=0A= if (index (nm, '/'))=0A= return build_string (sys_translate_unix (nm));=0A= #endif /* VMS */=0A= #ifdef DOS_NT=0A= /* Make sure directories are all separated with / or \ as=0A= desired, but avoid allocation of a new string when not=0A= required. */=0A= CORRECT_DIR_SEPS (nm);=0A= #ifdef WINDOWSNT=0A= if (IS_DIRECTORY_SEP (nm[1]))=0A= {=0A= if (strcmp (nm, XSTRING (name)->data) !=3D 0)=0A= name =3D build_string (nm);=0A= }=0A= else=0A= #endif=0A= /* drive must be set, so this is okay */=0A= if (strcmp (nm - 2, XSTRING (name)->data) !=3D 0)=0A= {=0A= name =3D make_string (nm - 2, p - nm + 2);=0A= XSTRING (name)->data[0] =3D DRIVE_LETTER (drive);=0A= XSTRING (name)->data[1] =3D ':';=0A= }=0A= return name;=0A= #else /* not DOS_NT */=0A= if (nm =3D=3D XSTRING (name)->data)=0A= return name;=0A= return build_string (nm);=0A= #endif /* not DOS_NT */=0A= }=0A= }=0A= =0A= /* At this point, nm might or might not be an absolute file name. We=0A= need to expand ~ or ~user if present, otherwise prefix nm with=0A= default_directory if nm is not absolute, and finally collapse /./=0A= and /foo/../ sequences.=0A= =0A= We set newdir to be the appropriate prefix if one is needed:=0A= - the relevant user directory if nm starts with ~ or ~user=0A= - the specified drive's working dir (DOS/NT only) if nm does not=0A= start with /=0A= - the value of default_directory.=0A= =0A= Note that these prefixes are not guaranteed to be absolute (except=0A= for the working dir of a drive). Therefore, to ensure we always=0A= return an absolute name, if the final prefix is not absolute we=0A= append it to the current working directory. */=0A= =0A= newdir =3D 0;=0A= =0A= if (nm[0] =3D=3D '~') /* prefix ~ */=0A= {=0A= if (IS_DIRECTORY_SEP (nm[1])=0A= #ifdef VMS=0A= || nm[1] =3D=3D ':'=0A= #endif /* VMS */=0A= || nm[1] =3D=3D 0) /* ~ by itself */=0A= {=0A= if (!(newdir =3D (unsigned char *) egetenv ("HOME")))=0A= newdir =3D (unsigned char *) "";=0A= nm++;=0A= #ifdef DOS_NT=0A= collapse_newdir =3D 0;=0A= #endif=0A= #ifdef VMS=0A= nm++; /* Don't leave the slash in nm. */=0A= #endif /* VMS */=0A= }=0A= else /* ~user/filename */=0A= {=0A= for (p =3D nm; *p && (!IS_DIRECTORY_SEP (*p)=0A= #ifdef VMS=0A= && *p !=3D ':'=0A= #endif /* VMS */=0A= ); p++);=0A= o =3D (unsigned char *) alloca (p - nm + 1);=0A= bcopy ((char *) nm, o, p - nm);=0A= o [p - nm] =3D 0;=0A= =0A= pw =3D (struct passwd *) getpwnam (o + 1);=0A= if (pw)=0A= {=0A= newdir =3D (unsigned char *) pw -> pw_dir;=0A= #ifdef VMS=0A= nm =3D p + 1; /* skip the terminator */=0A= #else=0A= nm =3D p;=0A= #ifdef DOS_NT=0A= collapse_newdir =3D 0;=0A= #endif=0A= #endif /* VMS */=0A= }=0A= =0A= /* If we don't find a user of that name, leave the name=0A= unchanged; don't move nm forward to p. */=0A= }=0A= }=0A= =0A= #ifdef DOS_NT=0A= /* On DOS and Windows, nm is absolute if a drive name was specified;=0A= use the drive's current directory as the prefix if needed. */=0A= if (!newdir && drive)=0A= {=0A= /* Get default directory if needed to make nm absolute. */=0A= if (!IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= newdir =3D alloca (MAXPATHLEN + 1);=0A= if (!getdefdir (toupper (drive) - 'A' + 1, newdir))=0A= newdir =3D NULL;=0A= }=0A= if (!newdir)=0A= {=0A= /* Either nm starts with /, or drive isn't mounted. */=0A= newdir =3D alloca (4);=0A= newdir[0] =3D DRIVE_LETTER (drive);=0A= newdir[1] =3D ':';=0A= newdir[2] =3D '/';=0A= newdir[3] =3D 0;=0A= }=0A= }=0A= #endif /* DOS_NT */=0A= =0A= /* Finally, if no prefix has been specified and nm is not absolute,=0A= then it must be expanded relative to default_directory. */=0A= =0A= if (1=0A= #ifndef DOS_NT=0A= /* /... alone is not absolute on DOS and Windows. */=0A= && !IS_DIRECTORY_SEP (nm[0])=0A= #endif=0A= #ifdef WINDOWSNT=0A= && !(IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= #endif=0A= #ifdef VMS=0A= && !index (nm, ':')=0A= #endif=0A= && !newdir)=0A= {=0A= newdir =3D XSTRING (default_directory)->data;=0A= #ifdef DOS_NT=0A= /* Note if special escape prefix is present, but remove for now. = */=0A= if (newdir[0] =3D=3D '/' && newdir[1] =3D=3D ':')=0A= {=0A= is_escaped =3D 1;=0A= newdir +=3D 2;=0A= }=0A= #endif=0A= }=0A= =0A= #ifdef DOS_NT=0A= if (newdir)=0A= {=0A= /* First ensure newdir is an absolute name. */=0A= if (=0A= /* Detect MSDOS file names with drive specifiers. */=0A= ! (IS_DRIVE (newdir[0])=0A= && IS_DEVICE_SEP (newdir[1]) && IS_DIRECTORY_SEP (newdir[2]))=0A= #ifdef WINDOWSNT=0A= /* Detect Windows file names in UNC format. */=0A= && ! (IS_DIRECTORY_SEP (newdir[0]) && IS_DIRECTORY_SEP (newdir[1]))=0A= #endif=0A= )=0A= {=0A= /* Effectively, let newdir be (expand-file-name newdir cwd).=0A= Because of the admonition against calling expand-file-name=0A= when we have pointers into lisp strings, we accomplish this=0A= indirectly by prepending newdir to nm if necessary, and using=0A= cwd (or the wd of newdir's drive) as the new newdir. */=0A= =0A= if (IS_DRIVE (newdir[0]) && newdir[1] =3D=3D ':')=0A= {=0A= drive =3D newdir[0];=0A= newdir +=3D 2;=0A= }=0A= if (!IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= char * tmp =3D alloca (strlen (newdir) + strlen (nm) + 2);=0A= file_name_as_directory (tmp, newdir);=0A= strcat (tmp, nm);=0A= nm =3D tmp;=0A= }=0A= newdir =3D alloca (MAXPATHLEN + 1);=0A= if (drive)=0A= {=0A= if (!getdefdir (toupper (drive) - 'A' + 1, newdir))=0A= newdir =3D "/";=0A= }=0A= else=0A= getwd (newdir);=0A= }=0A= =0A= /* Strip off drive name from prefix, if present. */=0A= if (IS_DRIVE (newdir[0]) && newdir[1] =3D=3D ':')=0A= {=0A= drive =3D newdir[0];=0A= newdir +=3D 2;=0A= }=0A= =0A= /* Keep only a prefix from newdir if nm starts with slash=0A= (//server/share for UNC, nothing otherwise). */=0A= if (IS_DIRECTORY_SEP (nm[0]) && collapse_newdir)=0A= {=0A= #ifdef WINDOWSNT=0A= if (IS_DIRECTORY_SEP (newdir[0]) && IS_DIRECTORY_SEP (newdir[1]))=0A= {=0A= newdir =3D strcpy (alloca (strlen (newdir) + 1), newdir);=0A= p =3D newdir + 2;=0A= while (*p && !IS_DIRECTORY_SEP (*p)) p++;=0A= p++;=0A= while (*p && !IS_DIRECTORY_SEP (*p)) p++;=0A= *p =3D 0;=0A= }=0A= else=0A= #endif=0A= newdir =3D "";=0A= }=0A= }=0A= #endif /* DOS_NT */=0A= =0A= if (newdir)=0A= {=0A= /* Get rid of any slash at the end of newdir, unless newdir is=0A= just / or // (an incomplete UNC name). */=0A= length =3D strlen (newdir);=0A= if (length > 1 && IS_DIRECTORY_SEP (newdir[length - 1])=0A= #ifdef WINDOWSNT=0A= && !(length =3D=3D 2 && IS_DIRECTORY_SEP (newdir[0]))=0A= #endif=0A= )=0A= {=0A= unsigned char *temp =3D (unsigned char *) alloca (length);=0A= bcopy (newdir, temp, length - 1);=0A= temp[length - 1] =3D 0;=0A= newdir =3D temp;=0A= }=0A= tlen =3D length + 1;=0A= }=0A= else=0A= tlen =3D 0;=0A= =0A= /* Now concatenate the directory and name to new space in the stack = frame */=0A= tlen +=3D strlen (nm) + 1;=0A= #ifdef DOS_NT=0A= /* Reserve space for drive specifier and escape prefix, since either=0A= or both may need to be inserted. (The Microsoft x86 compiler=0A= produces incorrect code if the following two lines are combined.) = */=0A= target =3D (unsigned char *) alloca (tlen + 4);=0A= target +=3D 4;=0A= #else /* not DOS_NT */=0A= target =3D (unsigned char *) alloca (tlen);=0A= #endif /* not DOS_NT */=0A= *target =3D 0;=0A= =0A= if (newdir)=0A= {=0A= #ifndef VMS=0A= if (nm[0] =3D=3D 0 || IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= #ifdef DOS_NT=0A= /* If newdir is effectively "C:/", then the drive letter will have=0A= been stripped and newdir will be "/". Concatenating with an=0A= absolute directory in nm produces "//", which will then be=0A= incorrectly treated as a network share. Ignore newdir in=0A= this case (keeping the drive letter). */=0A= if (!(drive && nm[0] && IS_DIRECTORY_SEP (newdir[0]) =0A= && newdir[1] =3D=3D '\0'))=0A= #endif=0A= strcpy (target, newdir);=0A= }=0A= else=0A= #endif=0A= file_name_as_directory (target, newdir);=0A= }=0A= =0A= strcat (target, nm);=0A= #ifdef VMS=0A= if (index (target, '/'))=0A= strcpy (target, sys_translate_unix (target));=0A= #endif /* VMS */=0A= =0A= /* ASSERT (IS_DIRECTORY_SEP (target[0])) if not VMS */=0A= =0A= /* Now canonicalize by removing /. and /foo/.. if they appear. */=0A= =0A= p =3D target;=0A= o =3D target;=0A= =0A= while (*p)=0A= {=0A= #ifdef VMS=0A= if (*p !=3D ']' && *p !=3D '>' && *p !=3D '-')=0A= {=0A= if (*p =3D=3D '\\')=0A= p++;=0A= *o++ =3D *p++;=0A= }=0A= else if ((p[0] =3D=3D ']' || p[0] =3D=3D '>') && p[0] =3D=3D p[1] = + 2)=0A= /* brackets are offset from each other by 2 */=0A= {=0A= p +=3D 2;=0A= if (*p !=3D '.' && *p !=3D '-' && o[-1] !=3D '.')=0A= /* convert [foo][bar] to [bar] */=0A= while (o[-1] !=3D '[' && o[-1] !=3D '<')=0A= o--;=0A= else if (*p =3D=3D '-' && *o !=3D '.')=0A= *--p =3D '.';=0A= }=0A= else if (p[0] =3D=3D '-' && o[-1] =3D=3D '.' &&=0A= (p[1] =3D=3D '.' || p[1] =3D=3D ']' || p[1] =3D=3D '>'))=0A= /* flush .foo.- ; leave - if stopped by '[' or '<' */=0A= {=0A= do=0A= o--;=0A= while (o[-1] !=3D '.' && o[-1] !=3D '[' && o[-1] !=3D '<');=0A= if (p[1] =3D=3D '.') /* foo.-.bar =3D=3D> bar. */=0A= p +=3D 2;=0A= else if (o[-1] =3D=3D '.') /* '.foo.-]' =3D=3D> ']' */=0A= p++, o--;=0A= /* else [foo.-] =3D=3D> [-] */=0A= }=0A= else=0A= {=0A= #ifndef VMS4_4=0A= if (*p =3D=3D '-' &&=0A= o[-1] !=3D '[' && o[-1] !=3D '<' && o[-1] !=3D '.' &&=0A= p[1] !=3D ']' && p[1] !=3D '>' && p[1] !=3D '.')=0A= *p =3D '_';=0A= #endif /* VMS4_4 */=0A= *o++ =3D *p++;=0A= }=0A= #else /* not VMS */=0A= if (!IS_DIRECTORY_SEP (*p))=0A= {=0A= *o++ =3D *p++;=0A= }=0A= else if (IS_DIRECTORY_SEP (p[0])=0A= && p[1] =3D=3D '.'=0A= && (IS_DIRECTORY_SEP (p[2])=0A= || p[2] =3D=3D 0))=0A= {=0A= /* If "/." is the entire filename, keep the "/". Otherwise,=0A= just delete the whole "/.". */=0A= if (o =3D=3D target && p[2] =3D=3D '\0')=0A= *o++ =3D *p;=0A= p +=3D 2;=0A= }=0A= else if (IS_DIRECTORY_SEP (p[0]) && p[1] =3D=3D '.' && p[2] =3D=3D = '.'=0A= /* `/../' is the "superroot" on certain file systems. */=0A= && o !=3D target=0A= && (IS_DIRECTORY_SEP (p[3]) || p[3] =3D=3D 0))=0A= {=0A= while (o !=3D target && (--o) && !IS_DIRECTORY_SEP (*o))=0A= ;=0A= /* Keep initial / only if this is the whole name. */=0A= if (o =3D=3D target && IS_ANY_SEP (*o) && p[3] =3D=3D 0)=0A= ++o;=0A= p +=3D 3;=0A= }=0A= else=0A= {=0A= *o++ =3D *p++;=0A= }=0A= #endif /* not VMS */=0A= }=0A= =0A= #ifdef DOS_NT=0A= /* At last, set drive name. */=0A= #ifdef WINDOWSNT=0A= /* Except for network file name. */=0A= if (!(IS_DIRECTORY_SEP (target[0]) && IS_DIRECTORY_SEP (target[1])))=0A= #endif /* WINDOWSNT */=0A= {=0A= if (!drive) abort ();=0A= target -=3D 2;=0A= target[0] =3D DRIVE_LETTER (drive);=0A= target[1] =3D ':';=0A= }=0A= /* Reinsert the escape prefix if required. */=0A= if (is_escaped)=0A= {=0A= target -=3D 2;=0A= target[0] =3D '/';=0A= target[1] =3D ':';=0A= }=0A= CORRECT_DIR_SEPS (target);=0A= #endif /* DOS_NT */=0A= =0A= return make_string (target, o - target);=0A= } ------=_NextPart_000_003C_01CB993A.D0BA3C10-- From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 15:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129216914415366 (code B ref 7617); Sun, 12 Dec 2010 15:53:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 15:52:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRoDn-0003zn-5S for submit@debbugs.gnu.org; Sun, 12 Dec 2010 10:52:23 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRoDl-0003za-EK for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 10:52:22 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PRoJe-00024G-P9; Sun, 12 Dec 2010 10:58:26 -0500 From: Eli Zaretskii In-reply-to: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> (drew.adams@oracle.com) References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> Message-Id: Date: Sun, 12 Dec 2010 10:58:26 -0500 X-Spam-Score: -6.5 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.5 (------) > From: "Drew Adams" > Date: Sat, 11 Dec 2010 13:53:38 -0800 > Cc: > > emacs -Q > > (expand-file-name "share/" "~/today//usr/") -> > c:/today/usr/share/. > > (On my Windows laptop, `~' is just `c:/'.) > > IOW, multiple consecutive slashes are collapsed to one. Correct. > This is not the behavior I want. This behavior started in Emacs 21; > in Emacs 20 no such removal of slashes occurs. Indeed, this change was made in preparation for release of Emacs 21.1: 2001-03-02 Gerd Moellmann * fileio.c (Fexpand_file_name): Collapse sequences of slashes to a single slash in the middle of file names. > I would consider this loss of slashes a bug. Please explain why you consider this a bug. foo//bar is at best equivalent to foo/bar, and at worst simply fails various system calls and naive Lisp code that doesn't expect more than one slash in a row. > But I see that comments in > the current C code indicate that it is intentional (but not _why_). I didn't find any related discussions that would explain the immediate reasons for the above change. So I don't know (and certainly don't remember ;-) why it was made. But I do think it's the right behavior for expand-file-name, because other primitives and Lisp code normally expects a canonicalized file name, so it would make sense to have a single primitive that produces such canonicalized file names. > I don't have C source for Emacs 21, but the behavior of 21 indicates that > that is when the change was made, presumably intentionally. I searched > the change logs but found no mention of this change or why it was made. See above, for the change log, but it is not really helpful in saying why (nor should it be). I haven't found anything in NEWS, either. > Given that the change was presumably intentional (but why?), you might > not be disposed to consider this a bug. I imagine you might argue that > the second arg to `expand-file-name' in this case is not a valid > directory name, so all bets are off wrt the behavior - or something like > that. Or perhaps you will argue that `expand*' is supposed to give you > a canonicalized file name, and a name such as "c:/today//usr/share/" > cannot be said to be canonicalized. Right, on both counts. > But shouldn't `expand-file-name' do the right thing if the second arg is > in fact `file-directory-p'? > > For a user on GNU/Linux with $HOME = /home/toto": > (file-directory-p "~/today//usr") -> nil, but > (file-directory-p "~//usr/") --> t, and we have the same problem: > (expand-file-name "foo" "~//usr/") -> "/home/toto/usr/foo" > > Surely the behavior here is buggy, no? Sorry, I don't see a bug here. Please explain more. > The result should be "/home/toto//usr/foo", I would think. Not clear why. As I said, "/home/toto//usr/foo" is at best equivalent to "/home/toto/usr/foo", and at worst will simply fail in another place. So what does the former give you that the latter doesn't? > _Why should_ `expand-file-name' collapse multiple consecutive > slashes into a single slash? In order to produce a _canonicalized_ file name. > Finally, I need the Emacs 20 behavior for this for some of my code. Can you describe the use-case where the old behavior is needed? > Oh, and another thing. This behavior of `expand-file-name' is not documented. Well, one could argue that "canonicalized" does mean removing consecutive slashes, but I guess it's easy enough to say that explicitly in the doc string. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 17:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129217663926299 (code B ref 7617); Sun, 12 Dec 2010 17:58:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 17:57:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRqAg-0006q7-Ho for submit@debbugs.gnu.org; Sun, 12 Dec 2010 12:57:19 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRqAe-0006pu-Ln for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 12:57:17 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCI3NLh006672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 18:03:24 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCI3GxI027164; Sun, 12 Dec 2010 18:03:23 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 867118981292176986; Sun, 12 Dec 2010 10:03:06 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 10:03:06 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> Date: Sun, 12 Dec 2010 10:03:08 -0800 Message-ID: <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaFW1dEl4vIDG3Qgaz7+IAIdwRfQACNBoQ X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > Please explain why you consider this a bug. foo//bar is at best > equivalent to foo/bar, In what way is that _ever_ equivalent? Please show the equivalence for any of the OS's that Emacs supports. In interactive use, `...//abc...' is treated as just `/abc...' by Emacs. The prefix `.../' is ignored until you hit `RET'. And then the prefix is dropped when you enter the file name (`RET') - but only then. And that's appropriate. Other than when you actually hit `RET', the prefix should not be removed but simply ignored. Ignoring the prefix is a user convenience. Dropping it when you hit `RET' guarantees that the caller (e.g. a file-system utility) never sees it. So much for treating the `...//abc...' as `/abc...'. As to collapsing multiple consecutive slashes, which is something completely different - what is the rationale for that? You claim that `foo//bar' is equivalent to `foo/bar'. Where do you get that? Unix? GNU/Linux? Windows? VMS? I don't think so. If they were equivalent, the Emacs would transform `...//abc...' to just `.../abc...' when you hit `RET', not transform it to `/abc...'. Try changing that behavior and see how many Emacs users give you their opinion about how equivalent `//' and `/' are. ;-) > and at worst simply fails various system calls > and naive Lisp code that doesn't expect more than one slash in a row. Red herring. When such a name is actually _entered_ (`RET') the prefix `.../' is removed. So there is no way that system calls see such a name. And arguing on the basis of some supposed "naive Lisp code" is pretty weak. Which Lisp code currently depends on this collapsing? And you know, if you introduce _any_ change in behavior, no matter how bad, some Lisp code will eventually adapt to it and thus expect it. That is no argument at all. > > But I see that comments in > > the current C code indicate that it is intentional (but not _why_). > > I didn't find any related discussions that would explain the immediate > reasons for the above change. So I don't know (and certainly don't > remember ;-) why it was made. But I do think it's the right behavior > for expand-file-name, because other primitives and Lisp code normally > expects a canonicalized file name, so it would make sense to have a > single primitive that produces such canonicalized file names. Then please create a separate primitive the does just that. Currently, there is no way to maintain the integrity of the user's input if that input is passed through `expand-file-name' to do what the doc says `expand*' does. Currently, using `expand*' on input can easily change perfectly valid input (valid for Emacs, since it ignores and ultimately removes the prefix `.../') into input that is invalid (represents no file at all). IOW, please separate this slash-collapsing from what `expand-file-name' is actually _documented_ to do - there is nothing about slash collapsing in `expand*'s contract with its users. Make a separate function `collapse-slashes' which does (only) that, if you like. Then the cleaned-up `expand-file-name' can be used alone on user input without changing valid references to actual files into non-matches. Or if you prefer, leave `expand*' the way it is (but document the slash-collapsing), and create another primitive that does only what `expand*' is documented as doing: everything except the slash-collapsing. That new primitive would ignore a `...//' prefix up to the second slash - the same way Emacs ignores it during input. That primitive would simply expand the file name wrt the dir argument, removing `.' etc. as documented now - in sum, exactly what we _say_ `expand*' does, and no more. I don't really care which is done: clean up `expand*' or provide a new function that does what we _say_ `expand*' does (and what it actually did prior to Emacs 21). Either way I will have a function I can call to get the currently _documented_ `expand*' behavior (and only that). I will be able to apply it to user input and know that I haven't suddenly moved the target of the input from one file to another (probably nonexistent) one. > > But shouldn't `expand-file-name' do the right thing if the > > second arg is in fact `file-directory-p'? > > > > For a user on GNU/Linux with $HOME = /home/toto": > > (file-directory-p "~/today//usr") -> nil, but > > (file-directory-p "~//usr/") --> t, and we have the same problem: > > (expand-file-name "foo" "~//usr/") -> "/home/toto/usr/foo" > > > > Surely the behavior here is buggy, no? > > Sorry, I don't see a bug here. Please explain more. > > > The result should be "/home/toto//usr/foo", I would think. > > Not clear why. As I said, "/home/toto//usr/foo" is at best equivalent > to "/home/toto/usr/foo", It is not equivalent - neither at best nor at worst - not at all. In Emacs, file-name input `/home/toto//usr/foo' is interpreted as `/usr/foo' when you enter it. That _is_ an equivalence (for Emacs file-name input). The former is not valid for the file system, of course, but in Emacs the two names are _equivalent as input_. Assuming the file `/usr/foo' exists, `/home/toto//usr/foo' targets it validly (in Emacs). But `/home/toto/usr/foo' is not valid: Most likely no such file exists, and if it did exist it would anyway not be the same file as `/usr/foo'. That's the point. Valid file-name input (for Emacs) is in this case changed by `expand-file-name' into invalid input (invalid in the sense of not representing the same file). Not good; a bug. > and at worst will simply fail in another > place. So what does the former give you that the latter doesn't? See above. It maintains the integrity of the user's input: `/home/toto//usr/foo' is, as Emacs file-name input, equivalent to `/usr/foo'. `/home/toto/usr/foo' is _not_ equivalent. > > _Why should_ `expand-file-name' collapse multiple consecutive > > slashes into a single slash? > > In order to produce a _canonicalized_ file name. "Canonicalization" should not change which file is targeted. Just because you call the behavior "canonicalization" does not mean that the transformation is a good one. That's a word game. If the user's input targets file `/usr/foo', true canonicalization should not change the target to `/home/toto/usr/foo', which is something completely different. > > Finally, I need the Emacs 20 behavior for this for some of my code. > > Can you describe the use-case where the old behavior is needed? No, and it is irrelevant. I need the behavior of `expand-file-name' minus the slash-collapsing part. It does not matter why I need such a function. If `expand-file-name' were defined in Lisp I would just gather the part of it that I need into a new function. But I cannot do that because it is in C. But why is it in C, BTW? Is that really necessary? If you argue that some parts of it deal with platform issues and so are better handled in C, then I ask why not leave only those parts in C and move the actual logic of the function - what it is documented as _doing_, to Lisp? Expansion of the file name, removal of `.' etc. could be done in Lisp with if necessary sub-calls to C primitives to perform any platform-dependent stuff that cannot be done in Lisp. When Emacs code is in C it is much more difficult for users to (re)use it. > > Oh, and another thing. This behavior of `expand-file-name' > > is not documented. > > Well, one could argue that "canonicalized" does mean removing > consecutive slashes, No, one cannot argue that honestly. You could define any transformation you like, call it "canonicalization", and then claim that all of its behavior is documented as soon as you have simply said that it "canonicalizes". That's completely disingenuous. > but I guess it's easy enough to say that explicitly in the doc string. Please add this missing information to the doc string, if you refuse to see the misbehavior bug. And I hope I can get some information about how, in Lisp, to get the `expand*' behavior minus the target-changing slash-collapsing. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 19:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 7617@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921821341823 (code B ref 7617); Sun, 12 Dec 2010 19:29:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 19:28:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRrbK-0000TL-3A for submit@debbugs.gnu.org; Sun, 12 Dec 2010 14:28:54 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRrbH-0000T8-78 for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 14:28:51 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LDB00300Y65AH00@a-mtaout21.012.net.il> for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 21:33:16 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.142.197]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDB0031SYBF0470@a-mtaout21.012.net.il>; Sun, 12 Dec 2010 21:33:16 +0200 (IST) Date: Sun, 12 Dec 2010 21:33:32 +0200 From: Eli Zaretskii In-reply-to: <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> X-012-Sender: halo1@inter.net.il Message-id: <83k4jeu6pf.fsf@gnu.org> References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: <7617@debbugs.gnu.org> > Date: Sun, 12 Dec 2010 10:03:08 -0800 > > > Please explain why you consider this a bug. foo//bar is at best > > equivalent to foo/bar, > > In what way is that _ever_ equivalent? Please show the equivalence for any of > the OS's that Emacs supports. On Unix and GNU/Linux -- always, in the sense that file-related system calls will treat them the same. On Windows -- sometimes, depending on the implementation of the standard C library. > In interactive use, `...//abc...' is treated as just `/abc...' by Emacs. The > prefix `.../' is ignored until you hit `RET'. And then the prefix is dropped > when you enter the file name (`RET') - but only then. And that's appropriate. > Other than when you actually hit `RET', the prefix should not be removed but > simply ignored. That's right, but I was talking about non-interactive uses. I believe in interactive use, Emacs still does what you (and I) expect. > Then please create a separate primitive the does just that. Feel free to file a separate feature request for that. > Currently, there is no way to maintain the integrity of the user's input if that > input is passed through `expand-file-name' to do what the doc says `expand*' > does. If all you need is ignore everything before the double slash, there are easier ways than asking to change a primitive. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921845555663 (code B ref 7617); Sun, 12 Dec 2010 20:10:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:09:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsEM-0001TF-Bc for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:09:14 -0500 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsEL-0001T3-3e for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:09:13 -0500 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 9DF8A1853B92; Sun, 12 Dec 2010 21:15:21 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id 5D6E81C00174; Sun, 12 Dec 2010 21:15:21 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 08801CA2A0; Sun, 12 Dec 2010 21:15:20 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> X-Yow: Somewhere in Tenafly, New Jersey, a chiropractor is viewing ``Leave it to Beaver''! Date: Sun, 12 Dec 2010 21:15:20 +0100 In-Reply-To: <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 10:03:08 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > In interactive use, `...//abc...' is treated as just `/abc...' by > Emacs. This has nothing to do with expand-file-name, this is the function of substitute-in-file-name. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921849546289 (code B ref 7617); Sun, 12 Dec 2010 20:16:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:15:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsKn-0001dO-O7 for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:15:54 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsKl-0001dB-Ia for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:15:52 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCKLwEv011656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 20:22:00 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCKLn28016030; Sun, 12 Dec 2010 20:21:56 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 867200041292185289; Sun, 12 Dec 2010 12:21:29 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 12:21:29 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> Date: Sun, 12 Dec 2010 12:21:31 -0800 Message-ID: <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83k4jeu6pf.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaM6tpi/aFtPJcRVK+Q306JFg8rwAAraGA X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > In interactive use, `...//abc...' is treated as just > > `/abc...' by Emacs. The prefix `.../' is ignored until > > you hit `RET'. And then the prefix is dropped > > when you enter the file name (`RET') - but only then. > > And that's appropriate. Other than when you actually > > hit `RET', the prefix should not be removed but > > simply ignored. > > That's right, but I was talking about non-interactive uses. I believe > in interactive use, Emacs still does what you (and I) expect. This is not about existing calls to `expand-file-name' in the vanilla Emacs sources. I am using the function `expand*' on user input (one operation among many), to do just what is advertised for `expand*' - just the kind of canonicalization that is described, which does not include collapsing consecutive slashes. `expand*' does not do what is documented for it. The choices - for this bug report - are to either fix that behavior or provide a function that does what we claim `expand*' does. That is what this bug report is about: providing that functionality, one way or the other. > > Then please create a separate primitive the does just that. > > Feel free to file a separate feature request for that. _This_ bug is about the need for a function that does that. The doc for `expand*' describes it as exactly that function. If you do not want to fix the `expand*' behavior to reflect its description, then please provide the function under a different name from `extract*'. You already have the doc string for it. ;-) I would think that you would want to fix the `extract*' behavior, since it can lead to changing which file is targeted. But if you do not want to face that, then please at least provide some other way to get the behavior that is documented. > > Currently, there is no way to maintain the integrity of the > > user's input if that input is passed through `expand-file-name' > > to do what the doc says `expand*' does. > > If all you need is ignore everything before the double slash, there > are easier ways than asking to change a primitive. You are just running away, Eli. (Why am I not surprised?) Stop inventing. I did not say that I need only to ignore everything before the double slash. If that were all I needed I would just do that in Lisp - no need for any Emacs primitive for that. I said (very clearly) that I need to do just what `expand*' is contracted to do - _everything_ that its doc says it does, and no more. You are ignoring the fact that collapsing consecutive slashes typically leads to changing which file is targeted. I gave a simple example, but you have nothing to say about it. That, to me, is a clear bug in the `expand*' behavior. But if you want to ignore that misbehavior, that's your privilege. I hope that you will at least provide the functionality I asked for, if only via a different function from `extract*'. Barring that, I hope you will tell me how, in Lisp, to get the effect that `expand*' is documented to have, that is, the effect that it had before Emacs 21. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Andreas Schwab'" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921853646943 (code B ref 7617); Sun, 12 Dec 2010 20:23:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:22:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsRP-0001nw-Lz for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:22:43 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsRO-0001nk-0k for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:22:42 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCKSn8t020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 20:28:50 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCKSTkK022073; Sun, 12 Dec 2010 20:28:39 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 847221481292185528; Sun, 12 Dec 2010 12:25:28 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 12:25:28 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com><022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> Date: Sun, 12 Dec 2010 12:25:30 -0800 Message-ID: <5B70283E151A42C1802C6F6C64ABA73B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaOVDSBD8SZVbuTJ6sRsaraNEkiQAAOHlQ X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > In interactive use, `...//abc...' is treated as just `/abc...' by > > Emacs. > > This has nothing to do with expand-file-name, this is the function of > substitute-in-file-name. I know that. I never said that `expand-file-name' removed the prefix or that it should remove the prefix. In fact I said clearly that it should not. I do not want to remove _any_ of the prefix, including its slash. I am not interested in obtaining the behavior of `substitute-file-name'. I am interested in obtaining the documented behavior of `expand-file-name', which does not include collapsing consecutive slashes. Can you tell me how to get that behavior? From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 7617@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921855717266 (code B ref 7617); Sun, 12 Dec 2010 20:27:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:26:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsUl-0001t9-1G for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:26:11 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsUi-0001sw-Ue for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:26:09 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LDC00L0005QQY00@a-mtaout23.012.net.il> for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 22:32:16 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.142.197]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDC00LJJ11RDDB0@a-mtaout23.012.net.il>; Sun, 12 Dec 2010 22:32:16 +0200 (IST) Date: Sun, 12 Dec 2010 22:32:32 +0200 From: Eli Zaretskii In-reply-to: <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> X-012-Sender: halo1@inter.net.il Message-id: <83fwu2u3z3.fsf@gnu.org> References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: <7617@debbugs.gnu.org> > Date: Sun, 12 Dec 2010 12:21:31 -0800 > > You are just running away, Eli. (Why am I not surprised?) > > Stop inventing. Sigh. > I did not say that I need only to ignore everything before the > double slash. You didn't say anything, actually. I have no idea what is the problem you are trying to solve, and you refuse to describe it. Sorry, I'm not interested in this conversation anymore, not with that attitude of yours. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921858157649 (code B ref 7617); Sun, 12 Dec 2010 20:31:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:30:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsYh-0001zI-G5 for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:30:15 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsYe-0001z6-M9 for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:30:13 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 6D1851C1DA06; Sun, 12 Dec 2010 21:36:21 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id 5C2C91C00174; Sun, 12 Dec 2010 21:36:21 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 23FA9CA2A0; Sun, 12 Dec 2010 21:36:21 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <5B70283E151A42C1802C6F6C64ABA73B@us.oracle.com> X-Yow: YOU'D cry too if it happened to YOU!! Date: Sun, 12 Dec 2010 21:36:21 +0100 In-Reply-To: <5B70283E151A42C1802C6F6C64ABA73B@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 12:25:30 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > Can you tell me how to get that behavior? Whatfor? I cannot think of _any_ useful use. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921858567702 (code B ref 7617); Sun, 12 Dec 2010 20:31:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:30:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsZL-00020B-Qp for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:30:56 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsZK-0001zz-6k for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:30:54 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCKb1PW027598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 20:37:03 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCKXXWU031779; Sun, 12 Dec 2010 20:36:59 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 847229031292186215; Sun, 12 Dec 2010 12:36:55 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 12:36:55 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <83fwu2u3z3.fsf@gnu.org> Date: Sun, 12 Dec 2010 12:36:57 -0800 Message-ID: <5CBC02387DE341A2AA9AD92ADB0D85C8@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fwu2u3z3.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaO6wF0+DAVQENRXOZc9XYTYgYwQAAJLdA X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > Sigh. Sigh, indeed. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 7617@debbugs.gnu.org, drew.adams@oracle.com Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921860127958 (code B ref 7617); Sun, 12 Dec 2010 20:34:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:33:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsbr-00024J-5x for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:33:31 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsbp-000247-Iy for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:33:30 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LDC00L0019DWH00@a-mtaout23.012.net.il> for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 22:39:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.142.197]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDC00LS41DLRX10@a-mtaout23.012.net.il>; Sun, 12 Dec 2010 22:39:22 +0200 (IST) Date: Sun, 12 Dec 2010 22:39:38 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83ei9mu3n9.fsf@gnu.org> References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: Eli Zaretskii > Date: Sun, 12 Dec 2010 10:58:26 -0500 > Cc: 7617@debbugs.gnu.org > > I guess it's easy enough to say that explicitly in the doc string. Done. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921861568177 (code B ref 7617); Sun, 12 Dec 2010 20:36:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:35:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRseC-00027q-Ed for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:35:56 -0500 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRseB-00027c-JI for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:35:55 -0500 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 57D501844255; Sun, 12 Dec 2010 21:42:04 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id 26D561C00109; Sun, 12 Dec 2010 21:42:04 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id F3F37CA2A0; Sun, 12 Dec 2010 21:42:03 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> X-Yow: Now that I have my ``APPLE,'' I comprehend COST ACCOUNTING!! Date: Sun, 12 Dec 2010 21:42:03 +0100 In-Reply-To: <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 12:21:31 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > `expand*' does not do what is documented for it. It canonicalizes the file name. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Andreas Schwab'" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12921862208281 (code B ref 7617); Sun, 12 Dec 2010 20:37:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:37:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsfD-00029V-Kx for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:37:00 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsfC-00029J-4o for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:36:58 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCKh5sD000654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 20:43:06 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCKcw5L011085; Sun, 12 Dec 2010 20:43:04 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 847233311292186577; Sun, 12 Dec 2010 12:42:57 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 12:42:57 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com><022D0B344DB64B2A9E1B771B0695237E@us.oracle.com><5B70283E151A42C1802C6F6C64ABA73B@us.oracle.com> Date: Sun, 12 Dec 2010 12:42:59 -0800 Message-ID: <92BFE40D08B74D85969BB4A8137DF91A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaPD6mgeajiR5LR5CSyMvq1blmDgAACUkA X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > Can you tell me how to get that behavior? > > Whatfor? I cannot think of _any_ useful use. The class of useful uses is not limited to those you can think of, your Excellency. But I take it that you have nothing to say about how to obtain this behavior in Lisp. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129218727811506 (code B ref 7617); Sun, 12 Dec 2010 20:55:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:54:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRswH-0002zV-Lt for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:54:38 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRswD-0002yz-Mt for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:54:35 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 6620B1C08CFD; Sun, 12 Dec 2010 22:00:42 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id 568891C00165; Sun, 12 Dec 2010 22:00:42 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 28B84CA2A0; Sun, 12 Dec 2010 22:00:42 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <5B70283E151A42C1802C6F6C64ABA73B@us.oracle.com> <92BFE40D08B74D85969BB4A8137DF91A@us.oracle.com> X-Yow: BRYLCREAM is CREAM O' WHEAT in another DIMENSION.. Date: Sun, 12 Dec 2010 22:00:42 +0100 In-Reply-To: <92BFE40D08B74D85969BB4A8137DF91A@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 12:42:59 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) So you cannot name any useful use? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129218748312261 (code B ref 7617); Sun, 12 Dec 2010 20:59:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 20:58:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRszb-0003Bh-3D for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:58:03 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRszZ-0003B0-UM for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 15:58:02 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id D4ECE1C08CFA; Sun, 12 Dec 2010 22:04:10 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id CB0EB1C0010C; Sun, 12 Dec 2010 22:04:10 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id A13BFCA2A0; Sun, 12 Dec 2010 22:04:10 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> X-Yow: My CODE of ETHICS is vacationing at famed SCHROON LAKE in upstate New York!! Date: Sun, 12 Dec 2010 22:04:10 +0100 In-Reply-To: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> (Drew Adams's message of "Sat, 11 Dec 2010 13:53:38 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > The result should be "/home/toto//usr/foo", I would think. That is not a canonical file name, Your Royal Highness. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 22:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129219299125420 (code B ref 7617); Sun, 12 Dec 2010 22:30:02 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 22:29:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRuQR-0006bx-9P for submit@debbugs.gnu.org; Sun, 12 Dec 2010 17:29:51 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRuQQ-0006bl-3O for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 17:29:51 -0500 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBCMZvTC000422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Dec 2010 22:35:58 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBCMHZMx012948; Sun, 12 Dec 2010 22:35:56 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 867283271292193319; Sun, 12 Dec 2010 14:35:19 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 14:35:18 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> Date: Sun, 12 Dec 2010 14:35:20 -0800 Message-ID: <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83k4jeu6pf.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaM6tpi/aFtPJcRVK+Q306JFg8rwAFDGjw X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > On Unix and GNU/Linux -- always, in the sense that file-related system > calls will treat them the same. On Windows -- sometimes, depending on > the implementation of the standard C library. A last attempt to communicate, in hopes that you actually were trying to understand but I didn't explain myself well enough. I understand that a file system might treat ...//... the same as .../.... From a file-system point of view, the two might well be equivalent (the file system ignores the extra slash). But Emacs treats ...//... in the minibuffer as a file name that is equivalent to /... - as far as user input is concerned, ...//... is equivalent to /.... And as user input .../... generally targets a very different file than does ...//... - they are not equivalent. So the question for `expand-file-name' is what kind of file-name arguments is it supposed to handle - what are the arguments to `expand-file-name' expected to be? If we say that they must be strings acceptable to the file system, then the current behavior is correct, and the only fix needed for `expand-file-name' is wrt the doc (mention the slash collapse and say what forms the args must take - and what happens if they are not of the right form). If we say that the args can be any strings that Emacs accepts as file names during input, then the story is different, and the proper fix is the behavior I suggested (the Emacs 20 behavior). In that case, `expand-file-name' is more tolerant, accepting a wider class of strings. And in that case, the resultant canonicalization does not necessarily produce a file name acceptable to the file system, even if it produces a name acceptable as file-name input for Emacs. (Just as, in the other case, canonicalization of ...//... generally makes the name target the wrong file.) IOW, the question here is about the purpose of `expand*'. The behavior changed from Emacs 20 to 21, with apparently no record of why. My code that DTRT in Emacs 20 breaks with later versions because of this change, so I'm looking for a solution. My own need here remains the same regardless of what is decided about the intention wrt `expand*'s args. I need a function that has the latter behavior (but it need not be named `expand-file-name'). Besides a workable but ugly replace-regexp-in-string hack that saves and restores consecutive slashes around a call to `expand-file-name', I don't see a good way to do that. In this case, consider this bug report a request for such a function (enhancement request). And also in this case - i.e., if it is decided that the input args must be acceptable to the file system, that constraint on the args should be documented. And we should say what the function does/returns otherwise (e.g., say that it is undefined - i.e., that it is defined only in the case where the args are acceptable names for the file system). If we tell users that the args must be of a form acceptable by the current file system, then we should also tell them what happens otherwise (raise an error?...). From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 23:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129219684931060 (code B ref 7617); Sun, 12 Dec 2010 23:35:01 +0000 Received: (at 7617) by debbugs.gnu.org; 12 Dec 2010 23:34:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRvQf-00084u-DQ for submit@debbugs.gnu.org; Sun, 12 Dec 2010 18:34:09 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRvQc-00084V-Ic for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 18:34:07 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id B7D201C1DA06; Mon, 13 Dec 2010 00:40:15 +0100 (CET) Received: from igel.home (ppp-88-217-112-56.dynamic.mnet-online.de [88.217.112.56]) by mail.mnet-online.de (Postfix) with ESMTP id 8C8FB1C000BB; Mon, 13 Dec 2010 00:40:15 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 531D4CA2A0; Mon, 13 Dec 2010 00:40:15 +0100 (CET) From: Andreas Schwab References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> X-Yow: While my BRAINPAN is being refused service in BURGER KING, Jesuit priests are DATING CAREER DIPLOMATS!! Date: Mon, 13 Dec 2010 00:40:15 +0100 In-Reply-To: <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 14:35:20 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > IOW, the question here is about the purpose of `expand*'. Returning a canonicalized file name, as documented. > The behavior changed from Emacs 20 to 21, with apparently no record of > why. It's an obvious bug fix. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 00:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.12922010164722 (code B ref -1); Mon, 13 Dec 2010 00:44:02 +0000 Received: (at submit) by debbugs.gnu.org; 13 Dec 2010 00:43:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRwVs-0001E1-6X for submit@debbugs.gnu.org; Sun, 12 Dec 2010 19:43:36 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRwVl-0001Dr-NK for submit@debbugs.gnu.org; Sun, 12 Dec 2010 19:43:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRwbi-00039S-Gx for submit@debbugs.gnu.org; Sun, 12 Dec 2010 19:49:39 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:52226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRwbi-00039K-Es for submit@debbugs.gnu.org; Sun, 12 Dec 2010 19:49:38 -0500 Received: from [140.186.70.92] (port=49126 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRwbh-0003Lf-P1 for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 19:49:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRwbg-00038k-NQ for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 19:49:37 -0500 Received: from mail-pw0-f41.google.com ([209.85.160.41]:39690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRwbg-00038O-HF for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 19:49:36 -0500 Received: by pwj8 with SMTP id 8so742446pwj.0 for ; Sun, 12 Dec 2010 16:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vSI56ySA1n27OPfM3+IRJ5VPyxEmRI2KibVK36x5Gg0=; b=Vc+O/+FFsPWQIOSYMaq6JB/BvH01aq/gAUKixCwh1uxphjB3tTR3XnFojdAxcbymLw GspJ27ooAOJnCUkA4UpWE3YI9ZhAGnG2IsWgR5lhkfbH20VBGUgLDNsx9RvQz0vV3L41 ViFr+sob51TvpfI9RtlSawsFAzA1eLLx1UP2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jIyWrM6PL2vIebfnLPv4721gNnXWTD2IqBYQ2KxnHeKcLcpwnYZCt3p0rXlTVZ7zSk PU09rg0AiLZ9SxqFAE3ncFHtqZZ0BPyWRd3xIvTTGKi+y/KJx2orN3Qc5dbBXebmAY2l /M83mVWdC67yDo55fbOZuBNzmdrriLe5j7R64= Received: by 10.142.108.1 with SMTP id g1mr2683911wfc.9.1292201374711; Sun, 12 Dec 2010 16:49:34 -0800 (PST) Received: from [10.1.1.54] ([61.4.103.130]) by mx.google.com with ESMTPS id e14sm8137947wfg.8.2010.12.12.16.49.31 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 16:49:33 -0800 (PST) Message-ID: <4D056D8D.5040801@gnu.org> Date: Mon, 13 Dec 2010 08:49:17 +0800 From: Jason Rumney User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> In-Reply-To: <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) On 13/12/2010 02:03, Drew Adams wrote: > In interactive use, `...//abc...' is treated as just `/abc...' by Emacs. That is a convenient shortcut for interactive use. For expand-file-name it could open security holes where filename input is coming from untrusted sources, so code wants to ensure that the files given are contained in a safe directory. >>> Finally, I need the Emacs 20 behavior for this for some of my code. >>> >> Can you describe the use-case where the old behavior is needed? >> > No, and it is irrelevant. And you have just made this report irrelevant too, as the developers can see no valid reason to make the change you are requesting. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 03:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129221205424792 (code B ref 7617); Mon, 13 Dec 2010 03:48:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 03:47:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRzNt-0006Ro-UP for submit@debbugs.gnu.org; Sun, 12 Dec 2010 22:47:34 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRzNr-0006RU-EG for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 22:47:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisJAGsnBU1FpZA//2dsb2JhbACiZoEZecEIhUoEhGSOBQ X-IronPort-AV: E=Sophos;i="4.59,334,1288584000"; d="scan'208";a="85272046" Received: from 69-165-144-63.dsl.teksavvy.com (HELO ceviche.home) ([69.165.144.63]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 12 Dec 2010 22:53:40 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 85A436616B; Sun, 12 Dec 2010 22:53:40 -0500 (EST) From: Stefan Monnier Message-ID: References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> Date: Sun, 12 Dec 2010 22:53:40 -0500 In-Reply-To: <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> (Drew Adams's message of "Sun, 12 Dec 2010 12:21:31 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > I am using the function `expand*' on user input (one operation among > many), to do just what is advertised for `expand*' There-s your problem. You treat user input in a `read-file-name' as an actual file name (i.e. suitable to pass to functions like expand-file-name), whereas it is actually a different beast, closely related, but different: it has this "..// -> /" and ".../~ -> ~" rules, as well as env-var expansion (which also implies "$$ -> $" rewrite). And even these special rules depend on file-name-handlers so, e.g., they do not apply to URLs but other rules may aaply to other special filenames. I.e. the only safe thing to do is to first pass those strings through substitute-for-file-name. Stefan From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 04:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Stefan Monnier'" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129221442930293 (code B ref 7617); Mon, 13 Dec 2010 04:28:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 04:27:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS00C-0007sW-WF for submit@debbugs.gnu.org; Sun, 12 Dec 2010 23:27:09 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS00A-0007ry-KK for 7617@debbugs.gnu.org; Sun, 12 Dec 2010 23:27:07 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBD4XE4P015951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 04:33:15 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBD4Gq5e008819; Mon, 13 Dec 2010 04:33:13 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 847704691292214730; Sun, 12 Dec 2010 20:32:10 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Dec 2010 20:32:10 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com><022D0B344DB64B2A9E1B771B0695237E@us.oracle.com><83k4jeu6pf.fsf@gnu.org><0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> Date: Sun, 12 Dec 2010 20:32:12 -0800 Message-ID: <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuaeVZQjx1RFDzQRq6PX9lxfqTkpAAALAvw X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > I am using the function `expand*' on user input (one operation among > > many), to do just what is advertised for `expand*' > > There-s your problem. You treat user input in a `read-file-name' > as an actual file name (i.e. suitable to pass to functions like > expand-file-name), "Suitable to pass to functions like expand-file-name" is precisely the question that you are begging. That suitability is completely undefined so far. Part of this bug report asks that you document (a) just what is acceptable to `expand-file-name' as "file-name" syntax (for each arg) and (b) what happens if the arg is a string that is not of acceptable file-name syntax. For (a) it is no doubt enough to say that it is whatever syntax is acceptable by the current file system (if that is in fact the answer). But that should be stated explicitly, along with a description of (b). > whereas it is actually a different beast, closely > related, but different: it has this "..// -> /" and ".../~ -> > ~" rules, as well as env-var expansion (which also implies > "$$ -> $" rewrite). And even these special rules depend on > file-name-handlers so, e.g., they do not apply to URLs but other > rules may aaply to other special filenames. I.e. the only safe > thing to do is to first pass those strings through > substitute-for-file-name. Please read what I wrote. I am looking for a function that gives the behavior that is documented for `expand-file-name'. That's all. I do not want the slash-collapsing that also occurs but is (was before now) undocumented. And I do not want any of the input-transforming behavior provided by `read-file-name' or `substitute-in-file-name'. (I do not see any `substitute-for-filename' function; I assume you meant `*-in-*'.) In particular, I do not want ...// prefix removal or env var substitution. I've stated several times already that I am not looking for the behavior of `substitute-in-file-name'. If you do not regard the undocumented slash-collapsing of `expand-file-name' as a bug, then I am obviously looking for a different function. In any case, its documented behavior (= the Emacs 20 behavior) is exactly what I am looking for. Do you know a good way to get that behavior in Lisp? I am getting it now by calling `expand-file-name' within an envelope that restores any consecutive slashes that get removed, but I'm looking for something less ugly. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 05:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12922171003989 (code B ref 7617); Mon, 13 Dec 2010 05:12:01 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 05:11:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS0hH-00012H-MB for submit@debbugs.gnu.org; Mon, 13 Dec 2010 00:11:40 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS0hF-00011y-Cz for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 00:11:38 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PS0nA-0006i0-MK; Mon, 13 Dec 2010 00:17:44 -0500 From: Eli Zaretskii In-reply-to: <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> (drew.adams@oracle.com) References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> Message-Id: Date: Mon, 13 Dec 2010 00:17:44 -0500 X-Spam-Score: -6.5 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.5 (------) > From: "Drew Adams" > Cc: <7617@debbugs.gnu.org> > Date: Sun, 12 Dec 2010 14:35:20 -0800 > > So the question for `expand-file-name' is what kind of file-name > arguments is it supposed to handle - what are the arguments to > `expand-file-name' expected to be? For predictable behavior, the argument must have semantics of a valid file name for the underlying filesystem. In particular, a series of slashes is interpreted as the filesystem would interpret them. > Besides a workable but ugly replace-regexp-in-string hack that saves > and restores consecutive slashes around a call to > `expand-file-name', I don't see a good way to do that. If you seek suggestions for how to solve your problem in a non-ugly way, please tell more about the problem. It's clear that one _solution_ to that problem is to have the old behavior of expand-file-name. But that behavior is gone and will not come back. To suggest other solutions, we need to understand the problem. > And also in this case - i.e., if it is decided that the input args > must be acceptable to the file system, that constraint on the args > should be documented. I think that saying "file names" is enough for a doc string--after all, every programmer knows what is a valid file name. The ELisp manual says a few more words about that. Putting this kind of detail into a doc string of every file-oriented function would be excessive. > And we should say what the function > does/returns otherwise (e.g., say that it is undefined - i.e., that > it is defined only in the case where the args are acceptable names > for the file system). If we tell users that the args must be of a > form acceptable by the current file system, then we should also tell > them what happens otherwise (raise an error?...). If the argument doesn't have a valid file-name semantics, all bets are off. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 05:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, monnier@iro.umontreal.ca Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.12922174234779 (code B ref 7617); Mon, 13 Dec 2010 05:18:01 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 05:17:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS0mV-0001Ey-Bl for submit@debbugs.gnu.org; Mon, 13 Dec 2010 00:17:03 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS0mS-0001EJ-6w for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 00:17:00 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PS0sN-0007El-F3; Mon, 13 Dec 2010 00:23:07 -0500 From: Eli Zaretskii In-reply-to: <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> (drew.adams@oracle.com) References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com><022D0B344DB64B2A9E1B771B0695237E@us.oracle.com><83k4jeu6pf.fsf@gnu.org><0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> Message-Id: Date: Mon, 13 Dec 2010 00:23:07 -0500 X-Spam-Score: -6.5 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.5 (------) > From: "Drew Adams" > Cc: "'Eli Zaretskii'" , <7617@debbugs.gnu.org> > Date: Sun, 12 Dec 2010 20:32:12 -0800 > > Please read what I wrote. I'm sure he did. Stefan is telling you that perhaps you run the string through expand-file-name too early, before massaging it in some way that gives a valid file name. Or maybe that you should run expand-file-name only on parts of the file name, the parts that _are_ valid file names. > I am looking for a function that gives the behavior that is > documented for `expand-file-name'. `concat' comes to mind. And if that's not what you want, please consider describing the problem you are trying to solve. > Do you know a good way to get that behavior in Lisp? Call expand-file-name on parts of a file name, then `concat' them together (with any number of slashes that you want)? From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129225153424306 (code B ref 7617); Mon, 13 Dec 2010 14:46:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 14:45:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS9ef-0006Jy-Rj for submit@debbugs.gnu.org; Mon, 13 Dec 2010 09:45:34 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS9ed-0006Ji-QD for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 09:45:32 -0500 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDEpexS032641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 14:51:42 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDEpeGO016603; Mon, 13 Dec 2010 14:51:40 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 849343511292251898; Mon, 13 Dec 2010 06:51:38 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 06:51:37 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <9CD33585D0844F0D957F8D72E13087B7@us.oracle.com> Date: Mon, 13 Dec 2010 06:51:39 -0800 Message-ID: <63C872A67A614E2EBEB3344231DEA88F@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuahRaPA6WyaLnEQCORlYiP8ZxMWQATIX/A X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > Besides a workable but ugly replace-regexp-in-string hack that saves > > and restores consecutive slashes around a call to > > `expand-file-name', I don't see a good way to do that. > > If you seek suggestions for how to solve your problem in a non-ugly > way, please tell more about the problem. It's clear that one > _solution_ to that problem is to have the old behavior of > expand-file-name. But that behavior is gone and will not come back. > To suggest other solutions, we need to understand the problem. The behavior is no longer provided by `expand*'. But that behavior is what I want to achieve, in Lisp. Achieving that behavior is the problem. I understand that `expand*' is no longer the solution. > > And we should say what the function > > does/returns otherwise (e.g., say that it is undefined - i.e., that > > it is defined only in the case where the args are acceptable names > > for the file system). If we tell users that the args must be of a > > form acceptable by the current file system, then we should also tell > > them what happens otherwise (raise an error?...). > > If the argument doesn't have a valid file-name semantics, all bets are > off. Then that's what we should tell users: If either arg is not a file name acceptable to the file system then the behavior is undefined (aka we have no idea what will happen). This is not obvious - since we demand valid file names and produce a canonical name, one might well wonder what happens otherwise, whether we raise an error, for example. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 14:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129225159124407 (code B ref 7617); Mon, 13 Dec 2010 14:47:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 14:46:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS9fb-0006Lc-4F for submit@debbugs.gnu.org; Mon, 13 Dec 2010 09:46:31 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PS9fZ-0006LQ-Gk for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 09:46:29 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDEqcqG002786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 14:52:40 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDEW9M9012214; Mon, 13 Dec 2010 14:52:36 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 869300591292251901; Mon, 13 Dec 2010 06:51:41 -0800 Received: from dradamslap1 (/10.159.218.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 06:51:40 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com><022D0B344DB64B2A9E1B771B0695237E@us.oracle.com><83k4jeu6pf.fsf@gnu.org><0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> Date: Mon, 13 Dec 2010 06:51:42 -0800 Message-ID: <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuahdetWM76GacVTa6s4ZvfEzgoZwATDMqg X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > perhaps you run the string through expand-file-name too early, > before massaging it in some way that gives a valid file name. I do not want to change the strings into valid file names. That should be clear by now. > Or maybe that you should run expand-file-name only on parts > of the file name, the parts that _are_ valid file names. That's one possibility, I suppose. But I'm not really eager to analyze string inputs to try to discover pieces that might be valid file names for various operating systems. And it's not clear what that would mean in terms of the expansion I'm after (which is exactly the expansion of `expand*' minus the slash collapsing). But I recognize what you suggest as a possibility. Likewise, removing any ignorable prefix temporarily, expanding, and reapplying the prefix. Such approaches seem messier than what I'm doing now, which at least leverages `expand*' (for its OS knowledge and expansion function), and then undoes the slash collapsing. > Call expand-file-name on parts of a file name, then `concat' them > together (with any number of slashes that you want)? See above. I appreciate your trying to help, however. From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 15:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 7617@debbugs.gnu.org, monnier@iro.umontreal.ca Reply-To: Eli Zaretskii Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129225307026804 (code B ref 7617); Mon, 13 Dec 2010 15:12:01 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 15:11:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSA3S-0006yH-1I for submit@debbugs.gnu.org; Mon, 13 Dec 2010 10:11:10 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSA3Q-0006y4-4b for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 10:11:09 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LDD00A00H0KRA00@a-mtaout22.012.net.il> for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 17:17:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDD009VEH4S8FG0@a-mtaout22.012.net.il>; Mon, 13 Dec 2010 17:17:17 +0200 (IST) Date: Mon, 13 Dec 2010 17:17:16 +0200 From: Eli Zaretskii In-reply-to: <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> X-012-Sender: halo1@inter.net.il Message-id: <83wrndhfcz.fsf@gnu.org> References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: , <7617@debbugs.gnu.org> > Date: Mon, 13 Dec 2010 06:51:42 -0800 > > And it's not clear what that would mean in terms of the expansion I'm after > (which is exactly the expansion of `expand*' minus the slash collapsing). But after the expansion, wouldn't you remove everything up to and including the double slash? If so, why do you need the expansion, if most of it will be thrown away? And if you don't remove the part up to the double slash, then why do you need to keep the double slash? From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 15:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: 7617@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129225492729609 (code B ref 7617); Mon, 13 Dec 2010 15:43:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 15:42:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSAXO-0007hW-MQ for submit@debbugs.gnu.org; Mon, 13 Dec 2010 10:42:07 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSAXL-0007h1-MF for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 10:42:04 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDFmCui028784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 15:48:13 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDFmARk011327; Mon, 13 Dec 2010 15:48:10 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 849530541292255269; Mon, 13 Dec 2010 07:47:49 -0800 Received: from dradamslap1 (/10.159.255.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 07:47:48 -0800 From: "Drew Adams" References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> <83wrndhfcz.fsf@gnu.org> Date: Mon, 13 Dec 2010 07:47:49 -0800 Message-ID: <62A30B68351D478582F85071F8D2909C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83wrndhfcz.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: Acua2NbyUUpmSZpSS2GYmeuNfcDpcgAAXqsg X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > And it's not clear what that would mean in terms of the > > expansion I'm after (which is exactly the expansion of > > `expand*' minus the slash collapsing). > > But after the expansion, wouldn't you remove everything up to and > including the double slash? No, not at all. If I wanted to remove the prefix I would use `substitute-in-file-name'. > If so, why do you need the expansion, if > most of it will be thrown away? And if you don't remove the part up > to the double slash, then why do you need to keep the double slash? This is raw user input. I want to keep the prefix, if any, as it is (modulo ~ and any other changes `expand*' makes except for slash collapsing). I don't ever remove the prefix. Emacs (e.g. file-name reading) handles (ignores/removes) the prefix when the user finally hits RET. E.g., I want this behavior, with ~ = /home/toto": (expand-file-name "foo" "~//usr/") -> "/home/toto//usr/foo" Likewise, if double slashes appear in the first arg I want them preserved. As I said, "exactly the expansion of `expand*' minus the slash collapsing". It's OK. I can go with what I have now. And I can keep looking or experiment with other approaches such as temporarily removing the prefix (if any) and sewing it back on. I get the message that I haven't missed some obviously better solution. And I get the message that the `expand*' behavior will not be changed (including, e.g., adding an optional arg that inhibits slash collapsing). Thanks for adding mention of slash collapsing to the doc string. I hope you will also consider mentioning that a valid file name is expected and anything else results in undefined behavior. Feel free to close the bug now. From unknown Sat Jun 14 18:51:34 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: "Drew Adams" Subject: bug#7617: closed (Re: bug#7617: 24.0.50; `expand-file-name': removal of slashes) Message-ID: References: <83vd2xhcka.fsf@gnu.org> <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> X-Gnu-PR-Message: they-closed 7617 X-Gnu-PR-Package: emacs Reply-To: 7617@debbugs.gnu.org Date: Mon, 13 Dec 2010 16:12:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1292256722-32190-1" This is a multi-part message in MIME format... ------------=_1292256722-32190-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #7617: 24.0.50; `expand-file-name': removal of slashes which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 7617@debbugs.gnu.org. --=20 7617: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D7617 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1292256722-32190-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 7617-done) by debbugs.gnu.org; 13 Dec 2010 16:11:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSB07-0008Mi-7O for submit@debbugs.gnu.org; Mon, 13 Dec 2010 11:11:47 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSB04-0008MS-TI for 7617-done@debbugs.gnu.org; Mon, 13 Dec 2010 11:11:46 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LDD00C00JIU3G00@a-mtaout20.012.net.il> for 7617-done@debbugs.gnu.org; Mon, 13 Dec 2010 18:17:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDD00CCKJXG5D10@a-mtaout20.012.net.il>; Mon, 13 Dec 2010 18:17:42 +0200 (IST) Date: Mon, 13 Dec 2010 18:17:41 +0200 From: Eli Zaretskii Subject: Re: bug#7617: 24.0.50; `expand-file-name': removal of slashes In-reply-to: <62A30B68351D478582F85071F8D2909C@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83vd2xhcka.fsf@gnu.org> References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> <83wrndhfcz.fsf@gnu.org> <62A30B68351D478582F85071F8D2909C@us.oracle.com> X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 7617-done Cc: 7617-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: , <7617@debbugs.gnu.org> > Date: Mon, 13 Dec 2010 07:47:49 -0800 > > This is raw user input. I want to keep the prefix, if any, as it is (modulo ~ > and any other changes `expand*' makes except for slash collapsing). I don't > ever remove the prefix. Emacs (e.g. file-name reading) handles > (ignores/removes) the prefix when the user finally hits RET. But then why do you need to expand it? why not keep it as the user typed it, ~/ and whatnot? You can then expand it when the user hits RET, like Emacs does normally. > I get the message that I haven't missed some obviously better solution. I'm still not in a position to judge, since I don't know enough about what you are trying to accomplish. > Thanks for adding mention of slash collapsing to the doc string. I hope you > will also consider mentioning that a valid file name is expected and anything > else results in undefined behavior. Feel free to close the bug now. Done, on both counts. ------------=_1292256722-32190-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 11 Dec 2010 21:48:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRXIX-0002tI-OI for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:48:10 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRXIV-0002t3-Li for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:48:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRXOP-0006L0-Dp for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:54:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:38593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRXOP-0006Kp-4a for submit@debbugs.gnu.org; Sat, 11 Dec 2010 16:54:13 -0500 Received: from [140.186.70.92] (port=47902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRXON-0003z3-Lc for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRXOM-0006Jw-BY for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:11 -0500 Received: from rcsinet10.oracle.com ([148.87.113.121]:46851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRXOL-0006Il-VG for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2010 16:54:10 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBBLs5Yr012919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Dec 2010 21:54:06 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBBLrx8w004678 for ; Sat, 11 Dec 2010 21:54:02 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 866376331292104419; Sat, 11 Dec 2010 13:53:39 -0800 Received: from dradamslap1 (/10.159.220.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Dec 2010 13:53:38 -0800 From: "Drew Adams" To: Subject: 24.0.50; `expand-file-name': removal of slashes Date: Sat, 11 Dec 2010 13:53:38 -0800 Message-ID: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003C_01CB993A.D0BA3C10" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcuZfd3SOme47opfReix3lhmOPcFJw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) This is a multi-part message in MIME format. ------=_NextPart_000_003C_01CB993A.D0BA3C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit emacs -Q (expand-file-name "share/" "~/today//usr/") -> c:/today/usr/share/. (On my Windows laptop, `~' is just `c:/'.) IOW, multiple consecutive slashes are collapsed to one. This is not the behavior I want. This behavior started in Emacs 21; in Emacs 20 no such removal of slashes occurs. I would consider this loss of slashes a bug. But I see that comments in the current C code indicate that it is intentional (but not _why_). I'm not great at reading C code, but I see these comments in the Emacs 24 code: /* We want to replace multiple `/' in a row with a single slash. */ else if (p > nm && IS_DIRECTORY_SEP (p[0]) && IS_DIRECTORY_SEP (p[1])) And later on: /* Now canonicalize by removing `//', `/.' and `/foo/..' if they appear. */ ... /* Collapse multiple `/' in a row. */ In the Emacs 20 C code the equivalent comment says only this: /* Now canonicalize by removing /. and /foo/.. if they appear. */ I don't have C source for Emacs 21, but the behavior of 21 indicates that that is when the change was made, presumably intentionally. I searched the change logs but found no mention of this change or why it was made. Given that the change was presumably intentional (but why?), you might not be disposed to consider this a bug. I imagine you might argue that the second arg to `expand-file-name' in this case is not a valid directory name, so all bets are off wrt the behavior - or something like that. Or perhaps you will argue that `expand*' is supposed to give you a canonicalized file name, and a name such as "c:/today//usr/share/" cannot be said to be canonicalized. IOW, I imagine there can be arguments that defend the current (Emacs 21+) behavior. But shouldn't `expand-file-name' do the right thing if the second arg is in fact `file-directory-p'? For a user on GNU/Linux with $HOME = /home/toto": (file-directory-p "~/today//usr") -> nil, but (file-directory-p "~//usr/") --> t, and we have the same problem: (expand-file-name "foo" "~//usr/") -> "/home/toto/usr/foo" Surely the behavior here is buggy, no? The result should be "/home/toto//usr/foo", I would think. It seems like any special treatment of double slashes should only be an interactive treatment (e.g. ignore or remove everything up to the second consecutive slash). _Why should_ `expand-file-name' collapse multiple consecutive slashes into a single slash? I would start with that questiom. What is the rationale for that Emacs 21 change wrt Emacs 20. In case it helps, I've attached the Emacs 20 code for `expand-file-name'. Finally, I need the Emacs 20 behavior for this for some of my code. If you decide not to change the behavior for this in Emacs, can you suggest a good way (in Lisp) to get the behavior I want - i.e., the Emacs 20 behavior? I can try to work around this by substituting something for multiple consecutive slashes, so that `expand*' won't collapse them, and then substituting back again to get the slashes, but that is a truly gross and fragile hack. I'm open to better suggestions. Thanks. Oh, and another thing. This behavior of `expand-file-name' is not documented. If the decision is to keep this behavior, then the doc should let users know that the function does this. See the doc string - it describes everything the function does (including `.' removal etc.) - except this. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-12-06 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' ------=_NextPart_000_003C_01CB993A.D0BA3C10 Content-Type: application/octet-stream; name="emacs-20-dot-7-expand-file-name.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="emacs-20-dot-7-expand-file-name.c" DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0,=0A= "Convert filename NAME to absolute, and canonicalize it.\n\=0A= Second arg DEFAULT-DIRECTORY is directory to start with if NAME is = relative\n\=0A= (does not start with slash); if DEFAULT-DIRECTORY is nil or missing,\n\=0A= the current buffer's value of default-directory is used.\n\=0A= File name components that are `.' are removed, and \n\=0A= so are file name components followed by `..', along with the `..' = itself;\n\=0A= note that these simplifications are done without checking the = resulting\n\=0A= file names in the file system.\n\=0A= An initial `~/' expands to your home directory.\n\=0A= An initial `~USER/' expands to USER's home directory.\n\=0A= See also the function `substitute-in-file-name'.")=0A= (name, default_directory)=0A= Lisp_Object name, default_directory;=0A= {=0A= unsigned char *nm;=0A= =0A= register unsigned char *newdir, *p, *o;=0A= int tlen;=0A= unsigned char *target;=0A= struct passwd *pw;=0A= #ifdef VMS=0A= unsigned char * colon =3D 0;=0A= unsigned char * close =3D 0;=0A= unsigned char * slash =3D 0;=0A= unsigned char * brack =3D 0;=0A= int lbrack =3D 0, rbrack =3D 0;=0A= int dots =3D 0;=0A= #endif /* VMS */=0A= #ifdef DOS_NT=0A= int drive =3D 0;=0A= int collapse_newdir =3D 1;=0A= int is_escaped =3D 0;=0A= #endif /* DOS_NT */=0A= int length;=0A= Lisp_Object handler;=0A= =0A= CHECK_STRING (name, 0);=0A= =0A= /* If the file name has special constructs in it,=0A= call the corresponding file handler. */=0A= handler =3D Ffind_file_name_handler (name, Qexpand_file_name);=0A= if (!NILP (handler))=0A= return call3 (handler, Qexpand_file_name, name, default_directory);=0A= =0A= /* Use the buffer's default-directory if DEFAULT_DIRECTORY is omitted. = */=0A= if (NILP (default_directory))=0A= default_directory =3D current_buffer->directory;=0A= if (! STRINGP (default_directory))=0A= default_directory =3D build_string ("/");=0A= =0A= if (!NILP (default_directory))=0A= {=0A= handler =3D Ffind_file_name_handler (default_directory, = Qexpand_file_name);=0A= if (!NILP (handler))=0A= return call3 (handler, Qexpand_file_name, name, default_directory);=0A= }=0A= =0A= o =3D XSTRING (default_directory)->data;=0A= =0A= /* Make sure DEFAULT_DIRECTORY is properly expanded.=0A= It would be better to do this down below where we actually use=0A= default_directory. Unfortunately, calling Fexpand_file_name = recursively=0A= could invoke GC, and the strings might be relocated. This would=0A= be annoying because we have pointers into strings lying around=0A= that would need adjusting, and people would add new pointers to=0A= the code and forget to adjust them, resulting in intermittent bugs.=0A= Putting this call here avoids all that crud.=0A= =0A= The EQ test avoids infinite recursion. */=0A= if (! NILP (default_directory) && !EQ (default_directory, name)=0A= /* Save time in some common cases - as long as default_directory=0A= is not relative, it can be canonicalized with name below (if it=0A= is needed at all) without requiring it to be expanded now. */=0A= #ifdef DOS_NT=0A= /* Detect MSDOS file names with drive specifiers. */=0A= && ! (IS_DRIVE (o[0]) && IS_DEVICE_SEP (o[1]) && IS_DIRECTORY_SEP = (o[2]))=0A= #ifdef WINDOWSNT=0A= /* Detect Windows file names in UNC format. */=0A= && ! (IS_DIRECTORY_SEP (o[0]) && IS_DIRECTORY_SEP (o[1]))=0A= #endif=0A= #else /* not DOS_NT */=0A= /* Detect Unix absolute file names (/... alone is not absolute on=0A= DOS or Windows). */=0A= && ! (IS_DIRECTORY_SEP (o[0]))=0A= #endif /* not DOS_NT */=0A= )=0A= {=0A= struct gcpro gcpro1;=0A= =0A= GCPRO1 (name);=0A= default_directory =3D Fexpand_file_name (default_directory, Qnil);=0A= UNGCPRO;=0A= }=0A= =0A= #ifdef VMS=0A= /* Filenames on VMS are always upper case. */=0A= name =3D Fupcase (name);=0A= #endif=0A= #ifdef FILE_SYSTEM_CASE=0A= name =3D FILE_SYSTEM_CASE (name);=0A= #endif=0A= =0A= nm =3D XSTRING (name)->data;=0A= =0A= #ifdef DOS_NT=0A= /* We will force directory separators to be either all \ or /, so make=0A= a local copy to modify, even if there ends up being no change. */=0A= nm =3D strcpy (alloca (strlen (nm) + 1), nm);=0A= =0A= /* Note if special escape prefix is present, but remove for now. */=0A= if (nm[0] =3D=3D '/' && nm[1] =3D=3D ':')=0A= {=0A= is_escaped =3D 1;=0A= nm +=3D 2;=0A= }=0A= =0A= /* Find and remove drive specifier if present; this makes nm absolute=0A= even if the rest of the name appears to be relative. Only look for=0A= drive specifier at the beginning. */=0A= if (IS_DRIVE (nm[0]) && IS_DEVICE_SEP (nm[1]))=0A= {=0A= drive =3D nm[0];=0A= nm +=3D 2;=0A= }=0A= =0A= #ifdef WINDOWSNT=0A= /* If we see "c://somedir", we want to strip the first slash after the=0A= colon when stripping the drive letter. Otherwise, this expands to=0A= "//somedir". */=0A= if (drive && IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= nm++;=0A= #endif /* WINDOWSNT */=0A= #endif /* DOS_NT */=0A= =0A= #ifdef WINDOWSNT=0A= /* Discard any previous drive specifier if nm is now in UNC format. */=0A= if (IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= {=0A= drive =3D 0;=0A= }=0A= #endif=0A= =0A= /* If nm is absolute, look for /./ or /../ sequences; if none are=0A= found, we can probably return right away. We will avoid allocating=0A= a new string if name is already fully expanded. */=0A= if (=0A= IS_DIRECTORY_SEP (nm[0])=0A= #ifdef MSDOS=0A= && drive && !is_escaped=0A= #endif=0A= #ifdef WINDOWSNT=0A= && (drive || IS_DIRECTORY_SEP (nm[1])) && !is_escaped=0A= #endif=0A= #ifdef VMS=0A= || index (nm, ':')=0A= #endif /* VMS */=0A= )=0A= {=0A= /* If it turns out that the filename we want to return is just a=0A= suffix of FILENAME, we don't need to go through and edit=0A= things; we just need to construct a new string using data=0A= starting at the middle of FILENAME. If we set lose to a=0A= non-zero value, that means we've discovered that we can't do=0A= that cool trick. */=0A= int lose =3D 0;=0A= =0A= p =3D nm;=0A= while (*p)=0A= {=0A= /* Since we know the name is absolute, we can assume that each=0A= element starts with a "/". */=0A= =0A= /* "." and ".." are hairy. */=0A= if (IS_DIRECTORY_SEP (p[0])=0A= && p[1] =3D=3D '.'=0A= && (IS_DIRECTORY_SEP (p[2])=0A= || p[2] =3D=3D 0=0A= || (p[2] =3D=3D '.' && (IS_DIRECTORY_SEP (p[3])=0A= || p[3] =3D=3D 0))))=0A= lose =3D 1;=0A= #ifdef VMS=0A= if (p[0] =3D=3D '\\')=0A= lose =3D 1;=0A= if (p[0] =3D=3D '/') {=0A= /* if dev:[dir]/, move nm to / */=0A= if (!slash && p > nm && (brack || colon)) {=0A= nm =3D (brack ? brack + 1 : colon + 1);=0A= lbrack =3D rbrack =3D 0;=0A= brack =3D 0;=0A= colon =3D 0;=0A= }=0A= slash =3D p;=0A= }=0A= if (p[0] =3D=3D '-')=0A= #ifndef VMS4_4=0A= /* VMS pre V4.4,convert '-'s in filenames. */=0A= if (lbrack =3D=3D rbrack)=0A= {=0A= if (dots < 2) /* this is to allow negative version numbers */=0A= p[0] =3D '_';=0A= }=0A= else=0A= #endif /* VMS4_4 */=0A= if (lbrack > rbrack &&=0A= ((p[-1] =3D=3D '.' || p[-1] =3D=3D '[' || p[-1] =3D=3D '<') &&=0A= (p[1] =3D=3D '.' || p[1] =3D=3D ']' || p[1] =3D=3D '>')))=0A= lose =3D 1;=0A= #ifndef VMS4_4=0A= else=0A= p[0] =3D '_';=0A= #endif /* VMS4_4 */=0A= /* count open brackets, reset close bracket pointer */=0A= if (p[0] =3D=3D '[' || p[0] =3D=3D '<')=0A= lbrack++, brack =3D 0;=0A= /* count close brackets, set close bracket pointer */=0A= if (p[0] =3D=3D ']' || p[0] =3D=3D '>')=0A= rbrack++, brack =3D p;=0A= /* detect ][ or >< */=0A= if ((p[0] =3D=3D ']' || p[0] =3D=3D '>') && (p[1] =3D=3D '[' || p[1] = =3D=3D '<'))=0A= lose =3D 1;=0A= if ((p[0] =3D=3D ':' || p[0] =3D=3D ']' || p[0] =3D=3D '>') && p[1] = =3D=3D '~')=0A= nm =3D p + 1, lose =3D 1;=0A= if (p[0] =3D=3D ':' && (colon || slash))=0A= /* if dev1:[dir]dev2:, move nm to dev2: */=0A= if (brack)=0A= {=0A= nm =3D brack + 1;=0A= brack =3D 0;=0A= }=0A= /* if /name/dev:, move nm to dev: */=0A= else if (slash)=0A= nm =3D slash + 1;=0A= /* if node::dev:, move colon following dev */=0A= else if (colon && colon[-1] =3D=3D ':')=0A= colon =3D p;=0A= /* if dev1:dev2:, move nm to dev2: */=0A= else if (colon && colon[-1] !=3D ':')=0A= {=0A= nm =3D colon + 1;=0A= colon =3D 0;=0A= }=0A= if (p[0] =3D=3D ':' && !colon)=0A= {=0A= if (p[1] =3D=3D ':')=0A= p++;=0A= colon =3D p;=0A= }=0A= if (lbrack =3D=3D rbrack)=0A= if (p[0] =3D=3D ';')=0A= dots =3D 2;=0A= else if (p[0] =3D=3D '.')=0A= dots++;=0A= #endif /* VMS */=0A= p++;=0A= }=0A= if (!lose)=0A= {=0A= #ifdef VMS=0A= if (index (nm, '/'))=0A= return build_string (sys_translate_unix (nm));=0A= #endif /* VMS */=0A= #ifdef DOS_NT=0A= /* Make sure directories are all separated with / or \ as=0A= desired, but avoid allocation of a new string when not=0A= required. */=0A= CORRECT_DIR_SEPS (nm);=0A= #ifdef WINDOWSNT=0A= if (IS_DIRECTORY_SEP (nm[1]))=0A= {=0A= if (strcmp (nm, XSTRING (name)->data) !=3D 0)=0A= name =3D build_string (nm);=0A= }=0A= else=0A= #endif=0A= /* drive must be set, so this is okay */=0A= if (strcmp (nm - 2, XSTRING (name)->data) !=3D 0)=0A= {=0A= name =3D make_string (nm - 2, p - nm + 2);=0A= XSTRING (name)->data[0] =3D DRIVE_LETTER (drive);=0A= XSTRING (name)->data[1] =3D ':';=0A= }=0A= return name;=0A= #else /* not DOS_NT */=0A= if (nm =3D=3D XSTRING (name)->data)=0A= return name;=0A= return build_string (nm);=0A= #endif /* not DOS_NT */=0A= }=0A= }=0A= =0A= /* At this point, nm might or might not be an absolute file name. We=0A= need to expand ~ or ~user if present, otherwise prefix nm with=0A= default_directory if nm is not absolute, and finally collapse /./=0A= and /foo/../ sequences.=0A= =0A= We set newdir to be the appropriate prefix if one is needed:=0A= - the relevant user directory if nm starts with ~ or ~user=0A= - the specified drive's working dir (DOS/NT only) if nm does not=0A= start with /=0A= - the value of default_directory.=0A= =0A= Note that these prefixes are not guaranteed to be absolute (except=0A= for the working dir of a drive). Therefore, to ensure we always=0A= return an absolute name, if the final prefix is not absolute we=0A= append it to the current working directory. */=0A= =0A= newdir =3D 0;=0A= =0A= if (nm[0] =3D=3D '~') /* prefix ~ */=0A= {=0A= if (IS_DIRECTORY_SEP (nm[1])=0A= #ifdef VMS=0A= || nm[1] =3D=3D ':'=0A= #endif /* VMS */=0A= || nm[1] =3D=3D 0) /* ~ by itself */=0A= {=0A= if (!(newdir =3D (unsigned char *) egetenv ("HOME")))=0A= newdir =3D (unsigned char *) "";=0A= nm++;=0A= #ifdef DOS_NT=0A= collapse_newdir =3D 0;=0A= #endif=0A= #ifdef VMS=0A= nm++; /* Don't leave the slash in nm. */=0A= #endif /* VMS */=0A= }=0A= else /* ~user/filename */=0A= {=0A= for (p =3D nm; *p && (!IS_DIRECTORY_SEP (*p)=0A= #ifdef VMS=0A= && *p !=3D ':'=0A= #endif /* VMS */=0A= ); p++);=0A= o =3D (unsigned char *) alloca (p - nm + 1);=0A= bcopy ((char *) nm, o, p - nm);=0A= o [p - nm] =3D 0;=0A= =0A= pw =3D (struct passwd *) getpwnam (o + 1);=0A= if (pw)=0A= {=0A= newdir =3D (unsigned char *) pw -> pw_dir;=0A= #ifdef VMS=0A= nm =3D p + 1; /* skip the terminator */=0A= #else=0A= nm =3D p;=0A= #ifdef DOS_NT=0A= collapse_newdir =3D 0;=0A= #endif=0A= #endif /* VMS */=0A= }=0A= =0A= /* If we don't find a user of that name, leave the name=0A= unchanged; don't move nm forward to p. */=0A= }=0A= }=0A= =0A= #ifdef DOS_NT=0A= /* On DOS and Windows, nm is absolute if a drive name was specified;=0A= use the drive's current directory as the prefix if needed. */=0A= if (!newdir && drive)=0A= {=0A= /* Get default directory if needed to make nm absolute. */=0A= if (!IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= newdir =3D alloca (MAXPATHLEN + 1);=0A= if (!getdefdir (toupper (drive) - 'A' + 1, newdir))=0A= newdir =3D NULL;=0A= }=0A= if (!newdir)=0A= {=0A= /* Either nm starts with /, or drive isn't mounted. */=0A= newdir =3D alloca (4);=0A= newdir[0] =3D DRIVE_LETTER (drive);=0A= newdir[1] =3D ':';=0A= newdir[2] =3D '/';=0A= newdir[3] =3D 0;=0A= }=0A= }=0A= #endif /* DOS_NT */=0A= =0A= /* Finally, if no prefix has been specified and nm is not absolute,=0A= then it must be expanded relative to default_directory. */=0A= =0A= if (1=0A= #ifndef DOS_NT=0A= /* /... alone is not absolute on DOS and Windows. */=0A= && !IS_DIRECTORY_SEP (nm[0])=0A= #endif=0A= #ifdef WINDOWSNT=0A= && !(IS_DIRECTORY_SEP (nm[0]) && IS_DIRECTORY_SEP (nm[1]))=0A= #endif=0A= #ifdef VMS=0A= && !index (nm, ':')=0A= #endif=0A= && !newdir)=0A= {=0A= newdir =3D XSTRING (default_directory)->data;=0A= #ifdef DOS_NT=0A= /* Note if special escape prefix is present, but remove for now. = */=0A= if (newdir[0] =3D=3D '/' && newdir[1] =3D=3D ':')=0A= {=0A= is_escaped =3D 1;=0A= newdir +=3D 2;=0A= }=0A= #endif=0A= }=0A= =0A= #ifdef DOS_NT=0A= if (newdir)=0A= {=0A= /* First ensure newdir is an absolute name. */=0A= if (=0A= /* Detect MSDOS file names with drive specifiers. */=0A= ! (IS_DRIVE (newdir[0])=0A= && IS_DEVICE_SEP (newdir[1]) && IS_DIRECTORY_SEP (newdir[2]))=0A= #ifdef WINDOWSNT=0A= /* Detect Windows file names in UNC format. */=0A= && ! (IS_DIRECTORY_SEP (newdir[0]) && IS_DIRECTORY_SEP (newdir[1]))=0A= #endif=0A= )=0A= {=0A= /* Effectively, let newdir be (expand-file-name newdir cwd).=0A= Because of the admonition against calling expand-file-name=0A= when we have pointers into lisp strings, we accomplish this=0A= indirectly by prepending newdir to nm if necessary, and using=0A= cwd (or the wd of newdir's drive) as the new newdir. */=0A= =0A= if (IS_DRIVE (newdir[0]) && newdir[1] =3D=3D ':')=0A= {=0A= drive =3D newdir[0];=0A= newdir +=3D 2;=0A= }=0A= if (!IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= char * tmp =3D alloca (strlen (newdir) + strlen (nm) + 2);=0A= file_name_as_directory (tmp, newdir);=0A= strcat (tmp, nm);=0A= nm =3D tmp;=0A= }=0A= newdir =3D alloca (MAXPATHLEN + 1);=0A= if (drive)=0A= {=0A= if (!getdefdir (toupper (drive) - 'A' + 1, newdir))=0A= newdir =3D "/";=0A= }=0A= else=0A= getwd (newdir);=0A= }=0A= =0A= /* Strip off drive name from prefix, if present. */=0A= if (IS_DRIVE (newdir[0]) && newdir[1] =3D=3D ':')=0A= {=0A= drive =3D newdir[0];=0A= newdir +=3D 2;=0A= }=0A= =0A= /* Keep only a prefix from newdir if nm starts with slash=0A= (//server/share for UNC, nothing otherwise). */=0A= if (IS_DIRECTORY_SEP (nm[0]) && collapse_newdir)=0A= {=0A= #ifdef WINDOWSNT=0A= if (IS_DIRECTORY_SEP (newdir[0]) && IS_DIRECTORY_SEP (newdir[1]))=0A= {=0A= newdir =3D strcpy (alloca (strlen (newdir) + 1), newdir);=0A= p =3D newdir + 2;=0A= while (*p && !IS_DIRECTORY_SEP (*p)) p++;=0A= p++;=0A= while (*p && !IS_DIRECTORY_SEP (*p)) p++;=0A= *p =3D 0;=0A= }=0A= else=0A= #endif=0A= newdir =3D "";=0A= }=0A= }=0A= #endif /* DOS_NT */=0A= =0A= if (newdir)=0A= {=0A= /* Get rid of any slash at the end of newdir, unless newdir is=0A= just / or // (an incomplete UNC name). */=0A= length =3D strlen (newdir);=0A= if (length > 1 && IS_DIRECTORY_SEP (newdir[length - 1])=0A= #ifdef WINDOWSNT=0A= && !(length =3D=3D 2 && IS_DIRECTORY_SEP (newdir[0]))=0A= #endif=0A= )=0A= {=0A= unsigned char *temp =3D (unsigned char *) alloca (length);=0A= bcopy (newdir, temp, length - 1);=0A= temp[length - 1] =3D 0;=0A= newdir =3D temp;=0A= }=0A= tlen =3D length + 1;=0A= }=0A= else=0A= tlen =3D 0;=0A= =0A= /* Now concatenate the directory and name to new space in the stack = frame */=0A= tlen +=3D strlen (nm) + 1;=0A= #ifdef DOS_NT=0A= /* Reserve space for drive specifier and escape prefix, since either=0A= or both may need to be inserted. (The Microsoft x86 compiler=0A= produces incorrect code if the following two lines are combined.) = */=0A= target =3D (unsigned char *) alloca (tlen + 4);=0A= target +=3D 4;=0A= #else /* not DOS_NT */=0A= target =3D (unsigned char *) alloca (tlen);=0A= #endif /* not DOS_NT */=0A= *target =3D 0;=0A= =0A= if (newdir)=0A= {=0A= #ifndef VMS=0A= if (nm[0] =3D=3D 0 || IS_DIRECTORY_SEP (nm[0]))=0A= {=0A= #ifdef DOS_NT=0A= /* If newdir is effectively "C:/", then the drive letter will have=0A= been stripped and newdir will be "/". Concatenating with an=0A= absolute directory in nm produces "//", which will then be=0A= incorrectly treated as a network share. Ignore newdir in=0A= this case (keeping the drive letter). */=0A= if (!(drive && nm[0] && IS_DIRECTORY_SEP (newdir[0]) =0A= && newdir[1] =3D=3D '\0'))=0A= #endif=0A= strcpy (target, newdir);=0A= }=0A= else=0A= #endif=0A= file_name_as_directory (target, newdir);=0A= }=0A= =0A= strcat (target, nm);=0A= #ifdef VMS=0A= if (index (target, '/'))=0A= strcpy (target, sys_translate_unix (target));=0A= #endif /* VMS */=0A= =0A= /* ASSERT (IS_DIRECTORY_SEP (target[0])) if not VMS */=0A= =0A= /* Now canonicalize by removing /. and /foo/.. if they appear. */=0A= =0A= p =3D target;=0A= o =3D target;=0A= =0A= while (*p)=0A= {=0A= #ifdef VMS=0A= if (*p !=3D ']' && *p !=3D '>' && *p !=3D '-')=0A= {=0A= if (*p =3D=3D '\\')=0A= p++;=0A= *o++ =3D *p++;=0A= }=0A= else if ((p[0] =3D=3D ']' || p[0] =3D=3D '>') && p[0] =3D=3D p[1] = + 2)=0A= /* brackets are offset from each other by 2 */=0A= {=0A= p +=3D 2;=0A= if (*p !=3D '.' && *p !=3D '-' && o[-1] !=3D '.')=0A= /* convert [foo][bar] to [bar] */=0A= while (o[-1] !=3D '[' && o[-1] !=3D '<')=0A= o--;=0A= else if (*p =3D=3D '-' && *o !=3D '.')=0A= *--p =3D '.';=0A= }=0A= else if (p[0] =3D=3D '-' && o[-1] =3D=3D '.' &&=0A= (p[1] =3D=3D '.' || p[1] =3D=3D ']' || p[1] =3D=3D '>'))=0A= /* flush .foo.- ; leave - if stopped by '[' or '<' */=0A= {=0A= do=0A= o--;=0A= while (o[-1] !=3D '.' && o[-1] !=3D '[' && o[-1] !=3D '<');=0A= if (p[1] =3D=3D '.') /* foo.-.bar =3D=3D> bar. */=0A= p +=3D 2;=0A= else if (o[-1] =3D=3D '.') /* '.foo.-]' =3D=3D> ']' */=0A= p++, o--;=0A= /* else [foo.-] =3D=3D> [-] */=0A= }=0A= else=0A= {=0A= #ifndef VMS4_4=0A= if (*p =3D=3D '-' &&=0A= o[-1] !=3D '[' && o[-1] !=3D '<' && o[-1] !=3D '.' &&=0A= p[1] !=3D ']' && p[1] !=3D '>' && p[1] !=3D '.')=0A= *p =3D '_';=0A= #endif /* VMS4_4 */=0A= *o++ =3D *p++;=0A= }=0A= #else /* not VMS */=0A= if (!IS_DIRECTORY_SEP (*p))=0A= {=0A= *o++ =3D *p++;=0A= }=0A= else if (IS_DIRECTORY_SEP (p[0])=0A= && p[1] =3D=3D '.'=0A= && (IS_DIRECTORY_SEP (p[2])=0A= || p[2] =3D=3D 0))=0A= {=0A= /* If "/." is the entire filename, keep the "/". Otherwise,=0A= just delete the whole "/.". */=0A= if (o =3D=3D target && p[2] =3D=3D '\0')=0A= *o++ =3D *p;=0A= p +=3D 2;=0A= }=0A= else if (IS_DIRECTORY_SEP (p[0]) && p[1] =3D=3D '.' && p[2] =3D=3D = '.'=0A= /* `/../' is the "superroot" on certain file systems. */=0A= && o !=3D target=0A= && (IS_DIRECTORY_SEP (p[3]) || p[3] =3D=3D 0))=0A= {=0A= while (o !=3D target && (--o) && !IS_DIRECTORY_SEP (*o))=0A= ;=0A= /* Keep initial / only if this is the whole name. */=0A= if (o =3D=3D target && IS_ANY_SEP (*o) && p[3] =3D=3D 0)=0A= ++o;=0A= p +=3D 3;=0A= }=0A= else=0A= {=0A= *o++ =3D *p++;=0A= }=0A= #endif /* not VMS */=0A= }=0A= =0A= #ifdef DOS_NT=0A= /* At last, set drive name. */=0A= #ifdef WINDOWSNT=0A= /* Except for network file name. */=0A= if (!(IS_DIRECTORY_SEP (target[0]) && IS_DIRECTORY_SEP (target[1])))=0A= #endif /* WINDOWSNT */=0A= {=0A= if (!drive) abort ();=0A= target -=3D 2;=0A= target[0] =3D DRIVE_LETTER (drive);=0A= target[1] =3D ':';=0A= }=0A= /* Reinsert the escape prefix if required. */=0A= if (is_escaped)=0A= {=0A= target -=3D 2;=0A= target[0] =3D '/';=0A= target[1] =3D ':';=0A= }=0A= CORRECT_DIR_SEPS (target);=0A= #endif /* DOS_NT */=0A= =0A= return make_string (target, o - target);=0A= } ------=_NextPart_000_003C_01CB993A.D0BA3C10-- ------------=_1292256722-32190-1-- From unknown Sat Jun 14 18:51:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2010 20:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: 7617@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 7617-submit@debbugs.gnu.org id=B7617.129227248724713 (code B ref 7617); Mon, 13 Dec 2010 20:35:02 +0000 Received: (at 7617) by debbugs.gnu.org; 13 Dec 2010 20:34:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSF6d-0006QY-Kx for submit@debbugs.gnu.org; Mon, 13 Dec 2010 15:34:47 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSF6c-0006QK-55 for 7617@debbugs.gnu.org; Mon, 13 Dec 2010 15:34:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUJACIUBk1FpZA//2dsb2JhbACibIEcecNlhUoEhGSOBQ X-IronPort-AV: E=Sophos;i="4.59,337,1288584000"; d="scan'208";a="85340027" Received: from 69-165-144-63.dsl.teksavvy.com (HELO pastel.home) ([69.165.144.63]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 13 Dec 2010 15:40:57 -0500 Received: by pastel.home (Postfix, from userid 20848) id 2063D58CC2; Mon, 13 Dec 2010 15:40:57 -0500 (EST) From: Stefan Monnier Message-ID: References: <7F477A16FFA145E5AB532A96F55D5CDC@us.oracle.com> <022D0B344DB64B2A9E1B771B0695237E@us.oracle.com> <83k4jeu6pf.fsf@gnu.org> <0910543A74614DBD82DA14ED1B5E4D17@us.oracle.com> <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> <0C4C99D992E6435E9931DA26D1DD476E@us.oracle.com> <83wrndhfcz.fsf@gnu.org> <62A30B68351D478582F85071F8D2909C@us.oracle.com> Date: Mon, 13 Dec 2010 15:40:57 -0500 In-Reply-To: <62A30B68351D478582F85071F8D2909C@us.oracle.com> (Drew Adams's message of "Mon, 13 Dec 2010 07:47:49 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > E.g., I want this behavior, with ~ = /home/toto": > (expand-file-name "foo" "~//usr/") -> "/home/toto//usr/foo" I can't imagine why. If you want a more constructive answer, you're going to have to give us more context. Stefan