spaces in pathnames
jeremyhu at freedesktop.org
Mon Jun 30 08:50:02 PDT 2008
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
> 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.
More information about the xorg