Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get current working directory via global.__dirname #264

Closed
rogerwang opened this issue Dec 17, 2012 · 27 comments
Closed

get current working directory via global.__dirname #264

rogerwang opened this issue Dec 17, 2012 · 27 comments

Comments

@rogerwang
Copy link
Member


Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

@rogerwang
Copy link
Member Author

@Mithgol
Copy link
Contributor

Mithgol commented Dec 17, 2012

What's wrong with a good old process.cwd()?

@rogerwang
Copy link
Member Author

@Mithgol thanks for the hint :) We'd like to also support global.__dirname

@Mithgol
Copy link
Contributor

Mithgol commented Dec 17, 2012

I hope you are planning a getter that would call process.cwd().

Some other solution (like actually updating global.__dirname _each time_ the cwd changes) could slow down the application unnecessarily.

@rogerwang
Copy link
Member Author

I see. Could you please reply in the mailing list as well? So the OP would know about this tip.

@Mithgol
Copy link
Contributor

Mithgol commented Dec 17, 2012

I do not have an active Google Groups account, sorry.

You could give the original poster a hyperlink to this issue on GitHub.

Alternatively, you may point him to http://nodejs.org/docs/latest/api/process.html#process_process_cwd because he may find process.cwd() suitable enough for his needs.

@schmod
Copy link

schmod commented May 13, 2013

__dirname should not update whenever process.cwd() changes. The working directory and location of the script are two very different things.

At the very least, this should be documented, as it's a departure from Node's API.

For now, I suppose you could do

global.__dirname = process.execPath.substr(0,process.execPath.lastIndexOf('/'));

@Mithgol
Copy link
Contributor

Mithgol commented May 14, 2013

Thank you for explaining where I was mistaken.

@Lcfvs
Copy link

Lcfvs commented Mar 1, 2014

According with the Node.js behaviour, __dirname & __filename doesn't have to be global, they are proper to the current script/module.

Furthermore, parse process.execPath seems to be a bad idea, because your app is targeted by the package.json but may be everywhere.

I think, it's an implementation bug, like if the module loader doesn't share these vars.

My solution, waiting an upgrade, #1643. ;)

@bpasero
Copy link

bpasero commented Apr 4, 2014

Not supporting __dirname is pretty bad for node.js applications. Any update on this? Is there an overview about what node-webkit supports in terms of node.js features? __dirname seems pretty basic. Most applications use it to specify e.g. view-folders (express).

@Mithgol
Copy link
Contributor

Mithgol commented Apr 4, 2014

__dirname works in Node.js modules, i.e. in JavaScript code that was called with require().

__dirname doesn't work only in WebKit scripts, i.e. in JavaScript code that was called with HTML <script src="...">, or jQuery's $.getScript(), or any other similar method.

@bpasero
Copy link

bpasero commented Apr 4, 2014

I see, thanks for the clarification. As a related note, when I do a "console.log(__dirname)" from within my nodejs script, is there any way to see it somewhere in nodejs-webkit console?

@Mithgol
Copy link
Contributor

Mithgol commented Apr 4, 2014

It should just work.

It works for me:

module.exports = __dirname;
console.log('Hello ' + __dirname);

(__dirname test)

@chaseWillden
Copy link
Contributor

Can this be closed? @bpasero @Mithgol

@RIAEvangelist
Copy link

I agree should be closed.

@Mithgol
Copy link
Contributor

Mithgol commented Feb 17, 2015

I agree as well.

@erezcohen
Copy link

@Lcfvs , what did you mean in "process.execPath seems to be a bad idea, because your app is targeted by the package.json but may be everywhere".
(It works fine for me locally, what am I missing here? I'm trying to avoid an error on a user's machine...)

@erezcohen
Copy link

Per my last comment, I realized what you meant. When you run node (while supplying it some js for example), process.execPath returns the location of the node.exe, regardless of the location of the app. However in my case, when distributing my nwjs app, the app is bundled together with the nw.exe, and so process.execPath returns the desired result.

@mattvot
Copy link

mattvot commented Sep 21, 2015

For those looking for the directory of the index file name and not the nw executable, use:

global.require.main.filename

@polpo
Copy link

polpo commented Nov 5, 2015

Note that if your app is organized into subdirectories, changes the cwd, or uses a different location for the nw executable, the directory of the currently running WebKit script may not correspond with the above suggestions (your app's main entry point .html file, process.execPath, or process.cwd())! The trick of using var __dirname = require('./dirname.js') in the same directory as the WebKit context's .js file is nice, but may result having to litter dirname.js files around.

I suggest using:

var __dirname = path.dirname(document.currentScript.src.slice(7));

or if you don't feel like doing a var path = require('path');:

var __dirname = document.currentScript.src.slice(7, document.currentScript.src.lastIndexOf('/'));

The content of document.currentScript.src is a nice absolute file:// url. The slice(7) strips the file:// scheme off.

@drom
Copy link

drom commented Dec 25, 2015

Sorry, I missed the solution for this issue. How could I get current working directory?
process.cwd() --> gives some temp folder: /tmp/.org.chromium.Chromium.sXz93T

@polpo
Copy link

polpo commented Jan 4, 2016

@drom to get the current working directory when the app was started before NW.js changes to the directory containing the app, on Linux & OS X process.env.PWD and on Windows use process.env.CD.

@drom
Copy link

drom commented Jan 9, 2016

@polpo I can't find any sign of process.env.CD under Windows.

@polpo
Copy link

polpo commented Jun 23, 2016

Note that starting with nw13, global.__dirname now contains the proper dirname of the current .js file, and my comment above from Nov 4, 2015 no longer applies.

@matthew-dean
Copy link

matthew-dean commented Nov 25, 2016

@polpo That's incorrect. __dirname still does not work properly, at least in the browser context. From the Node.js documentation:

__dirname isn't actually a global but rather local to each module.

For instance, given two modules: a and b, where b is a dependency of a and there is a directory structure of:

/Users/mjr/app/a.js
/Users/mjr/app/node_modules/b/b.js
References to __dirname within b.js will return /Users/mjr/app/node_modules/b while references to __dirname within a.js will return /Users/mjr/app.

In Node.js, __dirname is local. In NW.js, __dirname is global, which makes no sense. So if I start root/index.html which references root/scripts/app.js, and then call global.__dirname, it should return root/scripts. Instead, it returns root/.

NW.js should bind the variable dynamically in the context of a script when it's evaluated.

@brettz9
Copy link

brettz9 commented Dec 18, 2017

FWIW (and I'm not using nw.js at the moment), here's my own polyfill to get the script's directory:

Assumes document.currentScript support (for which there is an IE6-10 polyfill but IE11 won't work as per the polyfill site):

const baseURL = typeof __dirname !== 'undefined'
    ? __dirname
    : (() => {
        const src = (document.currentScript && // May not be present if running from say console
            document.currentScript.src
        ) || location.href;
        return src.replace(/\/[^/]+\/?$/, '');
    })();

Also, FWIW, there is a JavaScript proposal (currently at stage 3) to get this from within ES6 modules; see http://2ality.com/2017/11/import-meta.html .

@Mark086
Copy link

Mark086 commented Jan 20, 2018

Happening problems with __dirname here: nodejs/node#18267

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests