bugmake - Bugs: bug #712, GNU make can't handle spaces in...

 
 

bug #712: GNU make can't handle spaces in pathnames

Submitter:  None
Submitted:  Wed 19 Jun 2002 11:04:51 PM UTC
Votes: 76
 
Severity:  2 - Minor Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  psmith Open/Closed:  Open
Component Version:  3.79.1 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 01 Mar 2021 04:08:34 PM UTC, comment #16: 

Just make a new main release. One that handles white-spaces and long paths.

Alberto Salvia Novella <es20490446e>
Mon 20 Apr 2015 05:48:34 AM UTC, comment #15: 

Would it be possible to have a special target .NULL_DELIMITED_LISTS to tell Make to use the null character as the list separator instead of whitespace?

That way we keep 100% backward compatability and also provide a simple way to support whitespace in filenames.  This would also allow more complex wildcard-ing such as:

    .NULL_DELIMITED_LISTS
   
    ...
   
    sources=$(shell find -name '*.in' {many predicates} -print0)
    targets=$(sources:%.in=%.out)
   
    ...
   
    %.out: %.in
        some-command < $^ > $@

Make would also automatically escape the whitespace in variables when building shell commands.

Mark K Cowan <markkc>
Sat 15 Feb 2014 04:23:00 PM UTC, comment #14: 

One approach to fixing this would be to add a new type of variable that is not expanded until the very last moment - when the dependency DAG and shell commands are to be generated. It would not be separated into tokens; rather, its contents would be treated as a single string that was verbatim incorporated into the filename or shell command to be used.

This is similar to how the shell supports any shell variable that is expanded within double quotes not being subject to word splitting and globbing.

Anonymous
Fri 02 Aug 2013 04:56:49 PM UTC, comment #13: 

My workaround is to use a target that generates a local symlink to the file with spaces:

.PRECIOUS: %.link
%.link:
ln -s "$$(echo $@ | sed -e 's/_dot_/./g' -e 's/_slash_/\//g' -e 's/_space_/ /g' -e 's/.link$$//')" $@

# should depend on ../Plugin Source/metadata/monitor.xml but gnumake doesn't support spaces!
.DELETE_ON_ERROR:
%.sql: %.sql.haml Makefile $(wildcard _*.sql.haml) _dot__dot__slash_Plugin_space_Source_slash_metadata_slash_monitor.xml.link

Anonymous
Wed 27 Feb 2013 04:55:12 AM UTC, comment #12: 

What's a pity the bug/limitation has lasted more than 10 years! I'd like to share my workaround here.

1. Replace all space by "+" before calling make functions and restore before the real procssing logic, e.g.
------------
SRC_NOSP=AA+Mgr/cpp1.cpp AA+Mgr/cpp2.cpp
$(info total $(words $(SRC_NOSP)) source files!)

OBJ_NOSP=$(patsubst %.cpp,$(ObjDir)/%.o,$(SRC_NOSP))
SRC=$(subst +,\ ,$(SRC_NOSP))
OBJ=$(subst +,\ ,$(OBJ_NOSP))

all: $(OBJ)
    ...
------------

2. As shell supports space by quote or escape, you can choose to use shell commands. And if necessary you can write your own script to handle words.
e.g.
Don't use:
 File=AA\ Mgr/cpp1.cpp
 SrcDir=$(dir $(File))
insteads,
 SrcDir=$(shell dirname '$(File)')

3. use quotes when you call shell
e.g.
------------
Src=AA\ Mgr/cpp1.cpp
%.o: %.cpp
   c++ '$<' -o '$@'
------------


However, I wonder why supporting space breaking the compatibility if space is escaped by '\'? Was '\' used as common char on old system?

And how about the tradeoff that making new flag/switch to keep compatibility?

I'm looking forwards to the fix of this bug.

Jian

Jian <skyshore>
Mon 12 Sep 2011 12:44:19 AM UTC, comment #11: 

bug #31614 closed as a duplicate of this bug

Paul D. Smith <psmith>
Group administrator
Tue 02 Jun 2009 11:53:59 AM UTC, comment #10: 

If we can't handle quoting properly in a backwards compatible manner... then is it feasible to add (yet another?) flag/switch/special target/etc to request proper handling of quoting?

grumble Lost the text I typed.

Anonymous
Sun 01 Jul 2007 10:22:25 PM UTC, comment #9: 

"How hard is it to handle quoting properly?" - impossible if we wish to maintain backward compatibility.

As Paul said nearly 4 years ago, make works in terms of "words" which are whitespace separated.

The quotation that starts this comment is viewed by make as 8 words  , the first of which is 4 characters long, a double quote followed by the letters 'H', 'o' and 'w'.

"Heck, even DOS can accept quoted arguments.". Does it? I type

echo "fred x"

and it returns

"fred x"

rather than the

fred x

I would expect. And if I try and create a file called a"b from the command line it fails, if I try from wordpad it tells me the name is invalid. Unix allows any characters in components of filenames except NUL and /. Whilst this is very flexible it also causes problems. The people who wrote unix recognised this, and in their next operating system they restricted the characters permitted in filenames to not allow control characters and the normal whitespace characters. At the same time they extended the valid characters to include things like alpha α, which are outside the traditional ASCII character set.

Icarus Sparry <icarus>
Fri 29 Jun 2007 11:44:52 PM UTC, comment #8: 

How to other make's handle quoted strings? like NMAKE for example? do any POSIX make's handle quoted strings internally themselves at present?

J <now3d>
Fri 29 Jun 2007 06:23:30 PM UTC, comment #7: 

How about simply:

$(notdir "C:\Program Files\Company Name\Binary1.dll" "C:\Program Files\Company Name\Binary2.dll") 

I think it's pretty clear what should happen here.  How hard is it to support quoting properly?  After all most shells know how to quote intrinsically, and GNU make is creating shell scripts for most things.

Heck, even DOS can accept quoted arguments.  Same argument for targets.  If I expect spaces, I (should be able to):

"%.util" : "$(TEMP_PATH)/%.exe"
  cp "$*" "$(OUT_PATH)/$(notdir $*)"

Seems natural enough, is this type of thing I need to do in most batch/shell/scripts anyway.

Anonymous
Mon 24 Oct 2005 05:01:45 AM UTC, comment #6: 

I'm retitling this bug to be a catch-all for the fact that GNU make doesn't handle spaces will in pathnames, period: not just automatic variables but most everywhere.

Paul D. Smith <psmith>
Group administrator
Wed 09 Apr 2003 08:09:57 PM UTC, comment #5: 

The manual is pretty clear that all parsing is done in terms of words, and words are space separated.  It is less clear as to whether spaces can be escaped, or how.

>> It's not well known to anyone who's read the manual. If
>> it's true, then the file naming limitations of make should
>> be PROMINENTLY and EXHAUSTIVELY detailed in the docs.


Yes, they should be.

Paul D. Smith <psmith>
Group administrator
Wed 09 Apr 2003 05:41:57 PM UTC, comment #4: 

<<it's well-known that GNU make simply does not handle files with spaces (or colons for that matter) in their names well at all.>>

It's not well known to anyone who's read the manual. If it's true, then the file naming limitations of make should be PROMINENTLY and EXHAUSTIVELY detailed in the docs.

Spaces are as valid in Unix filenames as Windows, and there is no short name to fall back on there.

Anonymous
Wed 09 Apr 2003 05:40:59 PM UTC, comment #3: 

<<it's well-known that GNU make simply does not handle files with spaces (or colons for that matter) in their names well at all.>>

It's not well known to anyone who's read the manual. If it's true, then the file naming limitations of make should be PROMINENTLY and EXHAUSTIVELY detailed in the docs.

Spaces are as valid in Unix filenames as Windows, and there is no short name to fall back on there.

Anonymous
Sun 07 Jul 2002 05:42:29 PM UTC, comment #2: 

Whoops.  I thought I had a simple way to fix this, but I was wrong.  So, I'm reopening this bug.

However, it's well-known that GNU make simply does not handle files with spaces (or colons for that matter) in their names well at all.  I'm recategorizing this as an enhancement request, to be resolved if/when we come up with a solution for the other issues surrounding files with spaces.

Note that sometimes you can workaround this problems on Windows by using the short name for the directory or file, which does not contain spaces.  I realize this is a drag because this name can easily change "behind your back", but it's the best suggestion make can provide at the moment.

Paul D. Smith <psmith>
Group administrator
Sun 07 Jul 2002 05:24:17 PM UTC, comment #1: 

The automatic variables $(@D) etc. are simply shorthand for other functions such as $(dir $@), and that's exactly how they're implemented internally.  If $@ expands to text with embedded whitespace, the dir function treats it as multiple arguments and returns the directory component of each argument.

I'll fix this for the next release.

Paul D. Smith <psmith>
Group administrator
Wed 19 Jun 2002 11:04:51 PM UTC, original submission:  

Using make 3.79.1 on win32.  Same results using cmd.exe and sh.exe (zsh port to windows)

I create a directory named D:/a b

Create two files: target.txt and prereq.txt

Makefile contents:
D:/a\ b/target.txt : D:/a\ b/prereq.txt
echo $@
echo $(@D)
echo $(@F)

make output:
echo D:/a b/target.txt
D:/a b/target.txt
echo D: b
D: b
echo a target.txt
a target.txt

Inexplicable and bewildering.



Stephen Huntley
-email is unavailable-

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by es20490446e (Posted a comment)
  • -email is unavailable- added by cou929 (Voted in favor of this item)
  • -email is unavailable- added by markkc (Posted a comment)
  • -email is unavailable- added by ohnobinki (Voted in favor of this item)
  • -email is unavailable- added by skyshore (Posted a comment)
  • -email is unavailable- added by donpellegrino (Voted in favor of this item)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by icarus (Posted a comment)
  • -email is unavailable- added by now3d (Posted a comment)
  •  

    There are 76 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-18 cou929 Carbon-Copy- Added cou929
    2014-02-11 ohnobinki Carbon-Copy- Added ohnobinki
    2012-09-18 donpellegrino Carbon-Copy- Added donpellegrino
    2005-10-24 psmith SummaryAutomatic variables can't handle spaces in pathnames GNU make can't handle spaces in pathnames
    2003-04-09 psmith Severity3 - Normal None
        StatusFixed None
    2002-07-07 psmith Item GroupBug None
        Open/ClosedClosed None
        Fixed Release4.0 None
    2002-07-07 psmith StatusNone None
        Assigned toNone None
        Open/ClosedOpen None
        Operating SystemMS Windows None
        Fixed ReleaseNone None
        Closed on- -

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code