[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Spaces in path names
Re: Spaces in path names
Sat, 14 Jan 2006 14:06:46 +0100
[ Cc:ing Derek, maybe he's still interested; this is
* Roger While wrote on Fri, Jan 13, 2006 at 11:27:23AM CET:
> Hmm. Derek's patch is interesting.
> As an addendum to your mail commenting
> on Derek's mail (July 8 2005), note :
> (One of a few places)
> + _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='\"-L$libdir\"'
> That, I think, is wrong. Should be
> or ?
No, that difference does not matter. You may want to get more familiar
with how Bourne shells do word splitting. For example,
test $foo = "no"
(a common idiom seen in user's scripts) is wrong: the right hand side
contains nothing (parameter expansions like $foo, or command
substitutions like `ls`) that will introduce white space that will be
word-split, unlike the left-hand side. Thus, the right way (with
minimal quoting) would be
test "$foo" = no
If it's unclear whether $foo may start with a hyphen, the common idiom
test "X$foo" = Xno
or, with minimal quoting,
test X"$foo" = Xno
Because the shell does not word-split on the right hand side of
can always safely be written as
It's just that the former versions are often easier to read and help
> Is/has anything going/gone on regarding this issue in CVS/2.x ?
No, not yet. I do have a couple of suggestions though for someone
ambitious to work on this: I would be much more easy with integrating
this if it were more backwards-compatible. One possibility could be
to quote path names in .la files *only* if the have to be quoted.
IOW, one common idiom in ltmain could be
case $dir in
*[$IFS]*) foo_dir="$foo_dir \"$dir\"" ;;
*) foo_dir="$foo_dir $dir" ;;
and it would be useful to factor this out in a small shell function;
it would also be necessary to check whether above works with all kinds
of shells. That way at least all other users would not see dramatical
changes, libltdl would continue to work for them, and all in all we
could incrementally(!) fix each occurrence of missing quotes, while as
long as unfinished, only users of paths with spaces would be impacted.
Pleas note also that my followup comment contained a glitch itself,
>> @@ -1043,7 +1043,7 @@ EOF
>> - lib_search_path=`pwd`
>> + lib_search_path=\"`pwd`\"
>This change is not necessary. The general rule is, that command
>substitutions and variable expansions do not get word-split in
>assignments and in the word after `case'.
This comment is wrong, the code was ok. I misread
Re: Spaces in path names, Kurt Roeckx, 2006/01/12