Re: pathnames containing spaces

[Robert Collins]

On Thu, 2004-01-29 at 00:08, Earnie Boyd wrote:
> Good luck with fixing the white space problems in every process that 
> reads arguments and uses white space as a delimiter of some sort.

Earnie has a very good point - GNU Arch faces the same problem with a
limited set of tools - patch, diff and tar. (Plus it's own internals of
course). We've come to the conclusion that whilst fixing
spaces-in-filenames, it would be sensible to address unicode glyphs at
the same time - so as to prevent auditing code twice (once to escape
spaces, once to espace unicode).

It's a big project no matter how you look at it... 

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: pathnames containing spaces

[Earnie Boyd]

Scott James Remnant wrote:
It should also be noted that Libtool suffers heavily from this problem
also.  The shell uses spaces as separators, which means Libtool isn't
even able to install to a directory containing a space:
dependency_libs="-L/mnt/Program Files/unix/lib -lfoo"

comes out as three arguments, and quoting the -L argument doesn't
actually solve that.
As well as many other programs, utilities and scripts.  White space has 
always been used as a delimiter for argument grokking purposes.  Quoting 
the space only helps in some instances and to some point.  If the path 
with a space is stored or even passed to another process then you've got 
to store or pass the quoting mechanisms with it as well.

Although file systems support a space in it's filenames it is 
discouraged from use for practical application purposes.  This 
discouragement is what makes the use of space in filenames non-portable, 
not necessarily the file system itself.  It is much easier to apply 
workarounds to this problem than it is to program for the problem.  The 
chance that you will have further problems with the space if you fix it 
in one place is, IMNSHO, about 99.99% certain.

Good luck with fixing the white space problems in every process that 
reads arguments and uses white space as a delimiter of some sort.

Earnie.
--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Re: pathnames containing spaces

[Scott James Remnant]

On Tue, 2004-01-27 at 19:27, Russ Allbery wrote:

> James Amundson <[EMAIL PROTECTED]> writes:
> 
> > As far as I can tell, it is impossible to get automake to work with
> > pathnames containing spaces. The canonical example is
> > ./configure --prefix="/c/Program Files"
> > make install
> > which will cause make to choke because install will be called with
> > unquoted pathnames. I don't know if there are other examples -- I have
> > never made it past this one.
> 
> make uses a space as a separator, and getting it to accept spaces in file
> names is extremely difficult or impossible depending on the version of
> make that you're using.
> 
It should also be noted that Libtool suffers heavily from this problem
also.  The shell uses spaces as separators, which means Libtool isn't
even able to install to a directory containing a space:

dependency_libs="-L/mnt/Program Files/unix/lib -lfoo"

comes out as three arguments, and quoting the -L argument doesn't
actually solve that.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



signature.asc
Description: This is a digitally signed message part

Re: pathnames containing spaces

[James Amundson]

On Tue, 2004-01-27 at 17:07, Alexandre Duret-Lutz wrote:

> In fact there is two different problems.  One is that we cannot
> support spaces in source filenames.  

Right. I wasn't even thinking about that, but I definitely see your
point. I don't suppose colons in source filename would be work very
well, either.
 
> (Incidentally this will also break builds if
> the package has been unpacked in a directory with a space, and
> $(srcdir) is absolute.)

Is there any check for that? It might save someone confusion at some
point.

> Your problem is different.  You want spaces in installation
> paths.  

Yes. That's really what I had in mind.

> Those paths do not appear as target or dependencies in
> Makefiles so there is no insurmountable obstacle.  As you say
> it's a simple matter of quoting.  Well sort of...  The appended
> patch is the start of a fix for this.

Excellent! Thank you very much.

Best,
Jim Amundson

Re: pathnames containing spaces

[Alexandre Duret-Lutz]

>>> "James" == James Amundson <[EMAIL PROTECTED]> writes:

 James> Wait a minute... You were joking, right? An important
 James> piece of infrastructure like automake shouldn't have
 James> amateurish mistakes like forgetting to properly quote
 James> pathnames in scripts and makefiles.

 James> Surely the automake maintainers realize that this is a
 James> bug, don't they?

I do.

In fact there is two different problems.  One is that we cannot
support spaces in source filenames.  As Russ Allbery pointed out
in another thread (he didn't Cc you) make uses space as a
separator and we cannot work around this.  It is not possible to
write a portable makefile with a dependency or target that
contains a space.  (Incidentally this will also break builds if
the package has been unpacked in a directory with a space, and
$(srcdir) is absolute.)

Your problem is different.  You want spaces in installation
paths.  Those paths do not appear as target or dependencies in
Makefiles so there is no insurmountable obstacle.  As you say
it's a simple matter of quoting.  Well sort of...  The appended
patch is the start of a fix for this.  Unfortunately it is not
yet complete: it breaks `make installdirs' on conditional
directories (this is because installdirs now tries to run
$(mkdir_p) "$(DESTDIR)$(bardir)" "$(DESTDIR)$(include_foodir)"
and this fails if $(DESTDIR)$(bardir) or
$(DESTDIR)$(include_foodir) is empty -- mkdir won't create "".) 

It shouldn't be too hard to fix, but unfortunately it's bedtime :)

2004-01-27  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* Makefile.am (maintainer-check): Check for unquoted $(DESTDIR) uses.
* lib/am/data.am, lib/am/distdir.am, lib/am/java.am, lib/am/libs.am,
lib/am/lisp.am, lib/am/ltlib.am, lib/am/mans.am, lib/am/progs.am,
lib/am/python.am, lib/am/scripts.am, lib/am/texinfos.am: Quote
installation paths in install, uninstall, and installcheck rules,
as well as in am__installdirs variables.  This is for the sake
of paths containing spaces.
* test/instspc.test: New file.
* test/Makefile.am (TESTS): Add instspc.test.
Report from James Amundson.

Index: Makefile.am
===
RCS file: /cvs/automake/automake/Makefile.am,v
retrieving revision 1.226.2.1
diff -u -r1.226.2.1 Makefile.am
--- Makefile.am 5 Jan 2004 22:21:48 -   1.226.2.1
+++ Makefile.am 27 Jan 2004 23:02:09 -
@@ -252,6 +252,10 @@
@if test `grep -E '[EMAIL PROTECTED]@' automake | wc -l` -ne 0; then \
  echo "Unresolved @...@ substitution in automake" 1>&2; \
  exit 1; \
+   fi; \
+   if grep -E "[^\'\"]\\\$$\(DESTDIR" $(srcdir)/lib/am/*.am; then \
+ echo 'Suspicious unquoted DESTDIR uses.' 1>&2 ; \
+ exit 1; \
fi
 
 
Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.230.2.7
diff -u -r1.230.2.7 THANKS
--- THANKS  12 Jan 2004 21:58:55 -  1.230.2.7
+++ THANKS  27 Jan 2004 23:02:10 -
@@ -88,6 +88,7 @@
 Ian Lance Taylor   [EMAIL PROTECTED]
 Imacat [EMAIL PROTECTED]
 Inoue  [EMAIL PROTECTED]
+James Amundson [EMAIL PROTECTED]
 James Henstridge   [EMAIL PROTECTED]
 James R. Van Zandt [EMAIL PROTECTED]
 James Youngman [EMAIL PROTECTED]
Index: lib/am/data.am
===
RCS file: /cvs/automake/automake/lib/am/data.am,v
retrieving revision 1.41.2.2
diff -u -r1.41.2.2 data.am
--- lib/am/data.am  10 Jan 2004 13:41:53 -  1.41.2.2
+++ lib/am/data.am  27 Jan 2004 23:02:10 -
@@ -22,14 +22,14 @@
 ##  ##
 
 if %?INSTALL%
-am__installdirs += $(DESTDIR)$(%NDIR%dir)
+am__installdirs += "$(DESTDIR)$(%NDIR%dir)"
 ?BASE?%DIR%%PRIMARY%_INSTALL = $(INSTALL_%ONE_PRIMARY%)
 ?!BASE?%DIR%%PRIMARY%_INSTALL = $(install_sh_DATA)
 ?EXEC?.PHONY install-exec-am: install-%DIR%%PRIMARY%
 ?!EXEC?.PHONY install-data-am: install-%DIR%%PRIMARY%
 install-%DIR%%PRIMARY%: $(%DIR%_%PRIMARY%)
@$(NORMAL_INSTALL)
-   $(mkdir_p) $(DESTDIR)$(%NDIR%dir)
+   test -z "$(%NDIR%dir)" || $(mkdir_p) "$(DESTDIR)$(%NDIR%dir)"
 ?!BASE?@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
 ## Funny invocation because Makefile variable can be empty, leading to
 ## a syntax error in sh.
@@ -45,8 +45,8 @@
 ?!BASE?$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
 ?!BASE?*) f=$$p;; \
 ?!BASE?  esac; \
- echo " $(%DIR%%PRIMARY%_INSTALL) $$d$$p $(DESTDIR)$(%NDIR%dir)/$$f"; \
- $(%DIR%%PRIMARY%_INSTALL) $$d$$p $(DESTDIR)$(%NDIR%dir)/$$f; \
+ echo " $(%DIR%%PRIMARY%_INSTALL) '$$d$$p' '$(DESTDIR)$(%NDIR%dir)/$$f'"; \
+ $(%DIR%%PRIMARY%_INSTALL) "$$d$$p" "$(DESTDIR)$(%NDIR%dir)/$$f"; \
done
 endif %?INSTALL%
 
@@ -67,8 +67,8 @@
 ?!BASE?

Re: pathnames containing spaces

[Tom Tromey]

> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

Russ> make uses a space as a separator, and getting it to accept spaces in file
Russ> names is extremely difficult or impossible depending on the version of
Russ> make that you're using.

Yeah, and the problem is made worse because quoting for make isn't the
same as quoting for the shell.  You have to double quote things,
sometimes in creative ways -- and automake likes to re-use user input,
so in some situations doing this is probably just impossible.

The problems aren't just with spaces, dollar signs and colons also
cause fits.

Tom

Re: pathnames containing spaces

[Thomas Dickey]

On Tue, 27 Jan 2004, Earnie Boyd wrote:

> > Surely the automake maintainers realize that this is a bug, don't they?
> >
>
> No, it is not an automake or autoconf bug.  Autoconf and Automake are
> about portability and spaces in path names are not portable.

Which platforms does automake run on where spaces in pathnames are
illegal?

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Re: pathnames containing spaces

[Bruce Korb]

Earnie Boyd wrote:

> No, it is not an automake or autoconf bug.  Autoconf and Automake are
> about portability and spaces in path names are not portable.

Explain that to some ported-to-unix programs that create
files with spaces in them.  It is a matter of custom.  On Unix,
the custom is to not do this.  On windows (and with GUI programs),
the custom is to do so.  This is a bug.  The refusal to fix it
is snobbery.  The fact that the solution is difficult gives a
legitimate reason for not putting it high on the priority list.

Re: pathnames containing spaces

[Earnie Boyd]

James Amundson wrote:
On Tue, 2004-01-27 at 06:21, Earnie Boyd wrote:

The usual response to this problem is 
_don't_use_path_names_with_spaces_. 


Heh heh.


There are different ways to modify 
what you are doing that it is not worth modifying the autotools to 
handle the space in path name problem.


Wait a minute... You were joking, right? An important piece of
infrastructure like automake shouldn't have amateurish mistakes like
forgetting to properly quote pathnames in scripts and makefiles.
Surely the automake maintainers realize that this is a bug, don't they?

No, it is not an automake or autoconf bug.  Autoconf and Automake are 
about portability and spaces in path names are not portable.



 For instance you could use the 
DOS 8.3 modified name which for ``Program Files'' is usually 
``Progra~1''.  Or you with Cygwin and MSYS you create a mount point and 
map ``C:\Program Files'' to it, e.g. ``echo "c:/progra~1 /opt" >> 
/etc/fstab''; then ``./configure --prefix=/opt''.


Thanks for the workarounds. Obviously, the mount point business won't
work for programs running outside of MSYS (or Cygwin). None of them will
work on non-windows platforms.
You are complaining about automake which itself will not execute outside 
of Cygwin or MSYS or someother posix compatiblity layer.

Earnie.

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Re: pathnames containing spaces

[Russ Allbery]

James Amundson <[EMAIL PROTECTED]> writes:

> As far as I can tell, it is impossible to get automake to work with
> pathnames containing spaces. The canonical example is
>   ./configure --prefix="/c/Program Files"
>   make install
> which will cause make to choke because install will be called with
> unquoted pathnames. I don't know if there are other examples -- I have
> never made it past this one.

make uses a space as a separator, and getting it to accept spaces in file
names is extremely difficult or impossible depending on the version of
make that you're using.

Automake is, for good or ill, built on top of make, and therefore suffers
from its shortcomings.

-- 
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>

Re: pathnames containing spaces

[James Amundson]

On Tue, 2004-01-27 at 06:21, Earnie Boyd wrote:
> The usual response to this problem is 
> _don't_use_path_names_with_spaces_. 

Heh heh.

>  There are different ways to modify 
> what you are doing that it is not worth modifying the autotools to 
> handle the space in path name problem.

Wait a minute... You were joking, right? An important piece of
infrastructure like automake shouldn't have amateurish mistakes like
forgetting to properly quote pathnames in scripts and makefiles.

Surely the automake maintainers realize that this is a bug, don't they?

>   For instance you could use the 
> DOS 8.3 modified name which for ``Program Files'' is usually 
> ``Progra~1''.  Or you with Cygwin and MSYS you create a mount point and 
> map ``C:\Program Files'' to it, e.g. ``echo "c:/progra~1 /opt" >> 
> /etc/fstab''; then ``./configure --prefix=/opt''.

Thanks for the workarounds. Obviously, the mount point business won't
work for programs running outside of MSYS (or Cygwin). None of them will
work on non-windows platforms.

--Jim Amundson

Re: pathnames containing spaces

[Earnie Boyd]

The usual response to this problem is 
_don't_use_path_names_with_spaces_.  There are different ways to modify 
what you are doing that it is not worth modifying the autotools to 
handle the space in path name problem.  For instance you could use the 
DOS 8.3 modified name which for ``Program Files'' is usually 
``Progra~1''.  Or you with Cygwin and MSYS you create a mount point and 
map ``C:\Program Files'' to it, e.g. ``echo "c:/progra~1 /opt" >> 
/etc/fstab''; then ``./configure --prefix=/opt''.

Earnie

James Amundson wrote:
As far as I can tell, it is impossible to get automake to work with
pathnames containing spaces. The canonical example is
./configure --prefix="/c/Program Files"
make install
which will cause make to choke because install will be called with
unquoted pathnames. I don't know if there are other examples -- I have
never made it past this one.
Have I missed something, or is this a bug? It is a serious problem when
using MSYS or Cygwin.
--Jim Amundson




--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

pathnames containing spaces

[James Amundson]

As far as I can tell, it is impossible to get automake to work with
pathnames containing spaces. The canonical example is
./configure --prefix="/c/Program Files"
make install
which will cause make to choke because install will be called with
unquoted pathnames. I don't know if there are other examples -- I have
never made it past this one.

Have I missed something, or is this a bug? It is a serious problem when
using MSYS or Cygwin.

--Jim Amundson