spaces in pathnames

[Jeremy Huddleston]

On Jun 30, 2008, at 07:49, Peter O'Gorman wrote:
> Glynn Clements wrote:
>> I can't say for certain that it's absolutely impossible, but any
>> solution will be both ugly and fragile.
>>
> Indeed, startx does not have to be a sh script on Mac OS X, nor does  
> it
> have to be portable, it can all either be in a #if __APPLE__ or built
> from a different cpp file, etc.
>
> Jeremy, is startx the only place where this matters?

I'm sure it *matters* in other places, but it's only really been  
reported with startx so far, so I think that might be the only place  
it's really an issue (there might be something in xinitrc.cpp that  
needs to be changed... I didn't actually look there yet).

As far as doing different cpp files or adding in extra #ifdef  
__APPLE__ stuff goes... Our goal is to have as little Apple-specific  
cruft as possible.  For a while (and is true with the currently  
shipping "official" OSX version), xinit isn't even included.  Most of  
xinit's functionality was handled by some bits that were in xserver/hw/ 
darwin/bundle.  I've cleaned up the start routine substantially this  
past month, and now we use xinit just like the rest of the world  
without any weird hackery.

There are #ifdef __APPLE__ blocks in startx.cpp right now for things  
like user preferences that don't make sense on other systems.  Spaces  
in pathnames is an issue that could exist on systems other than OSX,  
so I was hoping to find a clean, portable solution that would work for  
everybody, but I'm quickly seeing that any such solution would be a  
bit of a pain for me to wrestle.

I really don't like using eval, but I think that's the only solution  
that I understand at the moment, so I'm probably going to use that  
(inside some #ifdef __APPLE__ blocks so as to not force my kludge on  
the rest of the world).  Hopefully someone who understands this a  
little better than I do (Roland? I'll buy you a beer! =>) can put  
together a patch that is a bit more palatable.

--Jeremy