276592 - NS_OS_CURRENT_WORKING_DIR is not implemented

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Benjamin Smedberg]

For the directory service, NS_OS_CURRENT_WORKING_DIR either was never
implemented, or the impl got removed when xpcom-obsolete was split off.

Comment 1

[Benjamin Smedberg]

Attachment: Implement NS_OS_CURRENT_WORKING_DIR

Comment 2

[Darin Fisher]

dougt: was NS_OS_CURRENT_WORKING_DIR perhaps removed for a reason?

Comment 3

[Doug Turner (:dougt)]

NS_OS_CURRENT_WORKING_DIR isn't a very well defined place xp.  

Comment 4

[Benjamin Smedberg]

What's not well-defined about it? The current working dir is pretty standard,
no? We're just reflecting getcwd() into XPCOM.

Comment 5

[Benjamin Smedberg]

Fixed on trunk.

Comment 6

[Doug Turner (:dougt)]

what is the cwd of a application launched from the desktop?

Comment 7

[Darin Fisher]

(In reply to comment #6)
> what is the cwd of a application launched from the desktop?

I'm sure it is not undefined, and if memory serves... I think it should be the
desktop folder.  Certainly, if launched with a shortcut, the user even has the
opportunity to set the working directory for the executable.  (I'm talking about
Windows here; I suspect other desktops would behave similarly.)

Comment 8

[Doug Turner (:dougt)]

darin -- i didn't say it was undefined, but rather ill-defined, hence it was
removed.   

I had no problem with mapping some key to whatever getcwd returns, but the
problem is what do we say this means to someone that doesn't know all of the
issues with cwd?  More to the point -- what do you want to do with this key that
you can't do with the existing keys?

Comment 9

[Benjamin Smedberg]

Map command-line arguments. See bug 276588.

Comment 10

[Peter Weilbacher]

Reopening because this breaks the build on OS/2 with the currently used GCC
3.2.2 (which comes without direct.h while _getcwd is already in stdlib.h). But
thanks for thinking about OS/2, too! :-)

Comment 11

[Peter Weilbacher]

Attachment: remove #include <direct.h> for OS/2

Removal of direct.h fixes the build problem. Asking for approval, too, because
otherwise there won't be a 1.8a6 for OS/2...

Comment 12

[Peter Weilbacher]

Attachment: remove #include <direct.h> for OS/2

Removal of direct.h fixes the build problem. Asking for approval, too, because
otherwise there won't be a 1.8a6 for OS/2...

Comment 13

[Darin Fisher]

doug, how is the current working directory ill-defined?  what are the problems
with getcwd that you are eluding to?

Comment 14

[Peter Weilbacher]

The OS/2 change was already checked in on 2005-01-06 -> FIXED.