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

 
 

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

Submitted by:  None
Submitted on:  Wed 19 Jun 2002 11:04:51 PM UTC  
Votes:  75  
 
Severity: 2 - MinorItem Group: Enhancement
Status: NonePrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Open
Component Version: 3.79.1Operating System: Any
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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
-unavailable-

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 75 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 11 Feb 2014 06:48:12 AM UTCohnobinkiCarbon-Copy-=>Added ohnobinki
    Tue 18 Sep 2012 06:30:00 PM UTCdonpellegrinoCarbon-Copy-=>Added donpellegrino
    Mon 24 Oct 2005 05:01:45 AM UTCpsmithSummaryAutomatic variables can't handle spaces in pathnames=>GNU make can't handle spaces in pathnames
    Wed 09 Apr 2003 08:09:57 PM UTCpsmithSeverity3 - Normal=>(Error - Not Found)
      StatusFixed=>(Error - Not Found)
    Sun 07 Jul 2002 05:42:29 PM UTCpsmithItem GroupBug=>(Error - Not Found)
      Open/ClosedClosed=>(Error - Not Found)
      Fixed Release4.0=>(Error - Not Found)
    Sun 07 Jul 2002 05:24:17 PM UTCpsmithStatusNone=>(Error - Not Found)
      Assigned toNone=>NA
      Open/ClosedOpen=>(Error - Not Found)
      Operating SystemMS Windows=>(Error - Not Found)
      Fixed ReleaseNone=>(Error - Not Found)
      Closed on-=>-

    Back to the top


    Powered by Savane 3.1-cleanup1