RE: basename function in 4.3 cygwin
I didn't see any different behavior whether the backslash preceded '?' or any normal character (hence the 'x' in my example). Maybe it is different with '*', I didn't check that and it is not my use-case. -Original Message- From: Eli Zaretskii Sent: Friday, 21 May 2021 5:58 PM To: Ronald Hoogenboom Cc: psm...@gnu.org; bug-make@gnu.org Subject: Re: basename function in 4.3 cygwin > From: Ronald Hoogenboom > CC: "psm...@gnu.org" , "bug-make@gnu.org" > > Date: Fri, 21 May 2021 15:17:53 + > > As I said, possibly not a bug, but a change in functionality nevertheless. > It is all about what you consider to be "the directory part" and this > consideration has apparently changed. Not in the native port of Make, it didn't (I just tried). Maybe in the Cygwin port, which I don't have. > The root cause of this is (as always) the dual meaning of a backslash: an > escape character or a path separator. Maybe a better way of escaping would be > single-quoting it. Note that in my real use-case, the character after the > backslash is a '?', which needs to be passed un-molested by the shell. I have > some weird experiences with single quoting in makefiles, though. AFAIK, the Windows port treats the backslash as a quote character where it makes sense (e.g., in wildcards).
Re: basename function in 4.3 cygwin
> From: Ronald Hoogenboom > CC: "psm...@gnu.org" , "bug-make@gnu.org" > Date: Fri, 21 May 2021 15:17:53 + > > As I said, possibly not a bug, but a change in functionality nevertheless. > It is all about what you consider to be "the directory part" and this > consideration has apparently changed. Not in the native port of Make, it didn't (I just tried). Maybe in the Cygwin port, which I don't have. > The root cause of this is (as always) the dual meaning of a backslash: an > escape character or a path separator. Maybe a better way of escaping would be > single-quoting it. Note that in my real use-case, the character after the > backslash is a '?', which needs to be passed un-molested by the shell. I have > some weird experiences with single quoting in makefiles, though. AFAIK, the Windows port treats the backslash as a quote character where it makes sense (e.g., in wildcards).
RE: basename function in 4.3 cygwin
As I said, possibly not a bug, but a change in functionality nevertheless. It is all about what you consider to be "the directory part" and this consideration has apparently changed. I realize that my statement about documenting it is unjust. Sorry about that. The info text for basename function hasn't changed between 3.81 and 4.x. The root cause of this is (as always) the dual meaning of a backslash: an escape character or a path separator. Maybe a better way of escaping would be single-quoting it. Note that in my real use-case, the character after the backslash is a '?', which needs to be passed un-molested by the shell. I have some weird experiences with single quoting in makefiles, though. -Original Message- From: Eli Zaretskii Sent: Friday, 21 May 2021 5:04 PM To: Ronald Hoogenboom Cc: psm...@gnu.org; bug-make@gnu.org Subject: Re: basename function in 4.3 cygwin > From: Ronald Hoogenboom > Date: Fri, 21 May 2021 14:46:00 + > > small makefile to produce what I mean: > cut here --- > TRY=APP.BA\x BPP.BB\y > > all: > @echo $(foreach x,$(TRY),$(firstword $(subst ., ,$x))) > > none: > @echo $(basename $(TRY)) > - cut here --- > > "make all" does my workaround "make none" does the 'native' basename. > > expect > APP BPP > > since 4.x window/cygwin > APP.BA\x BPP.BB\y This is according to the documentation: '$(basename NAMES...)' Extracts all but the suffix of each file name in NAMES. If the file name contains a period, the basename is everything starting up to (and not including) the last period. Periods in the directory part are ignored. If there is no period, the basename is the entire file name. For example, $(basename src/foo.c src-1.0/bar hacks) produces the result 'src/foo src-1.0/bar hacks'. "Periods in the directory part are ignored." Which is what you have: the file-name extensions are in the directory names, not the file names.
Re: basename function in 4.3 cygwin
> From: Ronald Hoogenboom > Date: Fri, 21 May 2021 14:46:00 + > > small makefile to produce what I mean: > cut here --- > TRY=APP.BA\x BPP.BB\y > > all: > @echo $(foreach x,$(TRY),$(firstword $(subst ., ,$x))) > > none: > @echo $(basename $(TRY)) > - cut here --- > > "make all" does my workaround "make none" does the 'native' basename. > > expect > APP BPP > > since 4.x window/cygwin > APP.BA\x BPP.BB\y This is according to the documentation: '$(basename NAMES...)' Extracts all but the suffix of each file name in NAMES. If the file name contains a period, the basename is everything starting up to (and not including) the last period. Periods in the directory part are ignored. If there is no period, the basename is the entire file name. For example, $(basename src/foo.c src-1.0/bar hacks) produces the result 'src/foo src-1.0/bar hacks'. "Periods in the directory part are ignored." Which is what you have: the file-name extensions are in the directory names, not the file names.
Re: basename function in 4.3 cygwin
> From: Paul Smith > Date: Fri, 21 May 2021 10:14:50 -0400 > > E.g., is "C:\foo\bar.biz\baz" not a valid file named "biz" in a > directory named "C:\foo\bar.biz" ? You mean, a file named "baz". Yes, this is a valid file name on MS-Windows. Directories can have file-name extensions.
Re: basename function in 4.3 cygwin
> From: Ronald Hoogenboom > CC: "bug-make@gnu.org" > Date: Fri, 21 May 2021 13:57:49 + > Accept-Language: en-US > > I checked the native windows port of gnu-make I have (x86_64-pc-msys, version > 4.2.1) and it exhibits the same behavior as what I see on cygwin. Apparently > this is not cygwin specific. > > Since you state that there were some changes done between 3.81 and 4.x with > regards to the backslash path separator, I guess that is what caused this > regression. What is the regression? can you show an example that can be reproduced and analyzed? The native Windows port of GNU Make interprets backslashes as directory separators, as expected. If this is what you see, it isn't a bug.
Re: basename function in 4.3 cygwin
On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > The difference happens when a suffix contains one or more > backslashes. This is sometimes needed to escape special behavior of > meta characters in the shell. The basename function in 3.81 would > return everything up to the last period like documented in the info > file, but the basename function in 4.3 apparently considers the > backslash in the suffix as a path separator (I guess...). Can you provide a repro case? I don't don't know much about Windows, but I don't understand how you can tell the difference between a "suffix containing backslashes" versus a directory that contains a suffix. Is it not allowed for a directory to contain a suffix in Windows or something? E.g., is "C:\foo\bar.biz\baz" not a valid file named "biz" in a directory named "C:\foo\bar.biz" ?
RE: basename function in 4.3 cygwin
I checked the native windows port of gnu-make I have (x86_64-pc-msys, version 4.2.1) and it exhibits the same behavior as what I see on cygwin. Apparently this is not cygwin specific. Since you state that there were some changes done between 3.81 and 4.x with regards to the backslash path separator, I guess that is what caused this regression. -Original Message- From: Eli Zaretskii Sent: Friday, 21 May 2021 3:45 PM To: psm...@gnu.org Cc: Ronald Hoogenboom ; bug-make@gnu.org Subject: Re: basename function in 4.3 cygwin > From: Paul Smith > Date: Fri, 21 May 2021 09:34:47 -0400 > > On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > > I have noticed a nasty difference in behavior between 4.3 and 3.81 > > versions of gnu-make in cygwin. > > > > I’m not sure if this qualifies as a bug per-se, but it is a nasty > > difference in behavior anyway. At least this should be documented in > > the info file. > > We don't develop or support (or document) the cygwin port of GNU make > on this list. If you can reproduce this behavior on the native > Windows port of GNU make (see the README.W32 for how to build it) then > we will definitely want to fix it. > > If it is only reproducible in the cygwin port but not the native > Windows port, please file an issue with the Cygwin development team. FWIW, I'd actually expect it to be the other way around: to hear that Make 3.81 considered a backslash to be a directory separator, whereas Make 4.3 did not. That's because some years ago the Cygwin developers decided they want no longer support native MS-Windows file names, only Posix- style file names. But other than that, I agree with Paul: this should probably be taken up with the Cygwin developers through their mailing list.
Re: basename function in 4.3 cygwin
> From: Paul Smith > Date: Fri, 21 May 2021 09:34:47 -0400 > > On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > > I have noticed a nasty difference in behavior between 4.3 and 3.81 > > versions of gnu-make in cygwin. > > > > I’m not sure if this qualifies as a bug per-se, but it is a nasty > > difference in behavior anyway. At least this should be documented in > > the info file. > > We don't develop or support (or document) the cygwin port of GNU make > on this list. If you can reproduce this behavior on the native Windows > port of GNU make (see the README.W32 for how to build it) then we will > definitely want to fix it. > > If it is only reproducible in the cygwin port but not the native > Windows port, please file an issue with the Cygwin development team. FWIW, I'd actually expect it to be the other way around: to hear that Make 3.81 considered a backslash to be a directory separator, whereas Make 4.3 did not. That's because some years ago the Cygwin developers decided they want no longer support native MS-Windows file names, only Posix- style file names. But other than that, I agree with Paul: this should probably be taken up with the Cygwin developers through their mailing list.
Re: basename function in 4.3 cygwin
On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > I have noticed a nasty difference in behavior between 4.3 and 3.81 > versions of gnu-make in cygwin. > > I’m not sure if this qualifies as a bug per-se, but it is a nasty > difference in behavior anyway. At least this should be documented in > the info file. We don't develop or support (or document) the cygwin port of GNU make on this list. If you can reproduce this behavior on the native Windows port of GNU make (see the README.W32 for how to build it) then we will definitely want to fix it. If it is only reproducible in the cygwin port but not the native Windows port, please file an issue with the Cygwin development team. Thanks!
