Ticket #131 (closed crash: fixed)
Having a space in the volume name containing your user directory causes xinit to fail
| Reported by: | ubermale@… | Owned by: | jeremyhu@… |
|---|---|---|---|
| Priority: | Important | Milestone: | 2.3.0 |
| Component: | xserver | Version: | 2.2.1 (xserver-1.3.0-apple20) |
| Keywords: | volume name xinit | Cc: |
Description
Jun 25 09:58:38 octo org.x.startx[22495]: xinit: Detected Xquartz startup, setting CFProcessPath=/Applications/Utilities/X11.app/Contents/MacOS/X11 Jun 25 09:58:38 octo org.x.startx[22495]: Unrecognized option: Data/dogen/.serverauth.22495 Jun 25 09:58:38 octo org.x.startx[22495]: Fatal server error: Jun 25 09:58:38 octo org.x.startx[22495]: Unrecognized option: Data/dogen/.serverauth.22495 Jun 25 09:58:38 octo org.x.startx[22495]: AbortDDX Jun 25 09:58:38 octo org.x.startx[22495]: Quitting Xquartz…
After changing “User Data” to “User_Data”, it was fixed.
Attachments
Change History
comment:2 Changed 5 years ago by jeremyhu@…
- Status changed from new to assigned
- Version set to 2.2.1 (xserver-1.3)
- Milestone set to 2.3.0
Please try the attached replacement for /usr/X11/bin/startx and let me know if it works for you
comment:3 Changed 5 years ago by ubermale@…
Hello,
That one didn't work either but I just noticed it does give line numbers with errors:
old===== Jun 25 09:43:17 octo org.x.startx[18390]: /usr/X11/bin/startx: line 119: [: /Volumes/User: binary operator expected Jun 25 09:43:17 octo org.x.startx[18390]: /usr/X11/bin/startx: line 132: [: /Volumes/User: binary operator expected
new===== Jun 25 19:09:39 octo org.x.startx[1557]: /usr/X11/bin/startx: line 167: [: /Volumes/User: binary operator expected Jun 25 19:09:39 octo org.x.startx[1557]: /usr/X11/bin/startx: line 190: [: /Volumes/User: binary operator expected
comment:4 Changed 5 years ago by jeremyhu@…
Ok, I updated it to fix that additional problem. Can you give this update a go and let me know how it works for you?
Thanks.
comment:5 Changed 5 years ago by jeremyhu@…
Actually... that's not going to work either... I don't think there's going to be a way to really fix this given the limitations of bash... hmm...
comment:6 Changed 5 years ago by ubermale@…
Hehe, ok just let me know when you're ready for me to try it out. Thanks.
comment:7 Changed 5 years ago by jeremyhu@…
Ok. try this... but I don't know if this is compatible with other shells, but it should work ok with bash on OSX.
comment:8 Changed 5 years ago by jeremyhu@…
And this one should work with all shells... can you give it a try?
comment:9 Changed 5 years ago by jeremyhu@…
ok... i take it back... still not working... sigh... stupid corner cases...
comment:10 Changed 5 years ago by jeremyhu@…
ok... try this please...
really, this time.
comment:11 Changed 5 years ago by ubermale@…
Success! You da man..what else can I say? Looking forward to OpenGL support next :D
comment:12 Changed 5 years ago by jeremyhu@…
- Status changed from assigned to closed
- Resolution set to fixed
eh, thanks.... but you may be waiting a while =(
This was working with the default X11 install of Mac OS 10.5.3; the problem arise with updating to XQuartz 2.2.3.