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 <[email protected]> Sent: Friday, 21 May 2021 5:04 PM To: Ronald Hoogenboom <[email protected]> Cc: [email protected]; [email protected] Subject: Re: basename function in 4.3 cygwin > From: Ronald Hoogenboom <[email protected]> > Date: Fri, 21 May 2021 14:46:00 +0000 > > 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.
