bugGNUstep - Bugs: bug #11853, starting gdnc in a directory with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11853: starting gdnc in a directory with spaces causes spawn to fail

Submitted by:  Alex Perez <aperez>
Submitted on:  Sat 05 Feb 2005 10:00:57 AM UTC  
 
Category: Base/FoundationSeverity: 4 - Important
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Richard Frith-Macdonald <CaS>
Open/Closed: Closed

Sun 05 Jun 2005 05:32:07 AM UTC, comment #5:

NO follow up for three months ... so I closed this.

Richard Frith-Macdonald <CaS>
Project MemberIn charge of this item.
Fri 18 Feb 2005 08:22:22 AM UTC, comment #4:

Solved the problem with the unicode filesystem support.
I't a bug in mingw. Recent mingw runtime releases have it fixed, but the main mingw package still comes with the older tuntime.

So ... you need to get a recent mingw runtime, or ... I rewrote NSFileManager so you can turn off unicode filesystem support by commenting out a couple of lines at the top so that UNICODE and _UNICODE are not defined.

Once that was fixed, I found and fixed a couple of windows specific bugs in NSTask.m, so you need to get the latest version of that file too.

Hopefully there are no other issues with this.

Richard Frith-Macdonald <CaS>
Project MemberIn charge of this item.
Thu 17 Feb 2005 03:08:06 PM UTC, comment #3:

Thanks for testing.

I think the leading '~' in the path is correct, as '~C' means the 'C' drive on a windows system, and this path should be expanded to the native windows path at the point where it is used.

Testing the new gdnc worked fine when I got my old windows-xp system running. However ...
I tried updating the rest of gnustep-base to the latest cvs code, and everything stopped working, not just gdnc. Programs simply crash on startup, before doing anything.

Going back a while in cvs seems to indicate that my problem is not recent, but stems from the point where a patch was applied to support windows unicode filesystem operations (late december).

Am I alone in this, or has nobody tried updating their base library on a windows system for a few months?

Anyway, at the moment I'm assuming that the current problem inb CVS stems from that unicode windows patch ... I'm going to look at the code and see if I can figure out what went wrong with it.
Re-opening this bug ... though perhaps I should be opening another one instead.

Richard Frith-Macdonald <CaS>
Project MemberIn charge of this item.
Wed 16 Feb 2005 10:14:39 PM UTC, comment #2:

This still isn't working, unfortunately. Now, when I run GDNC with updated -base CVS from today (Feb 16), I get the following output (same output from within the mingw32 rxvt environment as well as from a windows command prompt):

C:\Documents and Settings\aperez>"c:\program files\common files\gnustep\tools\gd
nc"
2005-02-16 22:08:50.000 gdnc[3400] No path specified for bundle
2005-02-16 14:08:50.000 gdnc[3400] Defaults home '~C/Documents and Settings/aperez/GNUstep' does not exist - failed to create it.
2005-02-16 14:08:50.000 gdnc[3400] Defaults home '~C/Documents and Settings/aperez/GNUstep' does not exist - failed to create it.
2005-02-16 14:08:50.000 gdnc[3400] File NSUserDefaults.m: 821. In [NSUserDefault
s -initWithContentsOfFile:] Path '(nil)' is not writable - making user defaults
for '(nil)' read-only
2005-02-16 14:08:50.000 gdnc[3400] Improper installation: No language locale fou
nd

exiting.

This is a bogus message. The language locale is where it is, and this worked fine before reinstalling base from my most recent CVS checkout today. So, while it looks like you may have partially fixed the problem, it's still not working completely. There's definately a problem with NSUserDefaults; it looks like it blindly prepends a ~ in front of $GNUSTEP_HOME, which okay, I guess, except under win32.

In my environment, GNUSTEP_USER_ROOT=%APPDATA%/GNUstep . %APPDATA% expands out to c:\documents and settings\aperez\application data\

If you need any additional info, let me know.

Thanks, Alex.

Alex Perez <aperez>
Project Member
Mon 14 Feb 2005 09:56:27 AM UTC, comment #1:

A windows specific problem ... this should be fixed in CVS.
Please give it a try.

Richard Frith-Macdonald <CaS>
Project MemberIn charge of this item.
Sat 05 Feb 2005 10:00:57 AM UTC, original submission:

This happens under mingw32, but it probably also happens under *NIX as well (as long as there's a single space in the path, it likely breaks in nasty ways) It says "gdnc - spawn failed - bye."

Alex Perez <aperez>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 6 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 05 Jun 2005 05:32:07 AM UTCCaSOpen/ClosedIn Test=>Closed
Fri 18 Feb 2005 08:22:22 AM UTCCaSStatusNone=>Fixed
  Open/ClosedOpen=>In Test
Thu 17 Feb 2005 03:08:06 PM UTCCaSOpen/ClosedIn Test=>Open
Mon 14 Feb 2005 09:56:27 AM UTCCaSAssigned toNone=>CaS
  Open/ClosedOpen=>In Test

Back to the top


Powered by Savane 3.1-cleanup1