i needed something like this last week so thanks for creating it :) instead of throwing when used on windows couldn't this just return %PATH%?

running inside an electron app (0.34.1) packaged with electron-packager, running on Yosemite

note the last two commands didn't seem to inherit my $PATH. I'll try and figure out why it isn't working...

EDIT also tried setting gid, uid, and cwd to my user, group and home folder but that didn't change the output

2nd EDIT exec whoami returns max, which is my user. exec sudo -Hiu max env returns the correct env variables, including my correct PATH. so I can access it that way. just not through echo $PATH

pretty sure this used to work in older electrons. maybe something changed

This is an upstream (Electron) issue but I'm logging it here for reference since it effects shell-path and fix-path.

See here for more info: electron/electron#3482

Got this stack trace from a report filed by @rickgregory over on linter-php:

TypeError: Cannot read property 'length' of null
    at SyncWriteStream.write (fs.js:1981:38)
    at Object.execFileSync (child_process.js:471:20)
    at pathFromShellSync (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/node_modules/consistent-path/node_modules/shell-path/index.js:52:28)
    at Function.module.exports.sync (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/node_modules/consistent-path/node_modules/shell-path/index.js:34:11)
    at findOutPath (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/node_modules/consistent-path/lib/index.js:27:62)
    at getPath (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/node_modules/consistent-path/lib/index.js:17:16)
    at _exec (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/lib/helpers.js:61:59)
    at Object.exec (/Users/rickg/.atom/packages/linter-php/node_modules/atom-linter/lib/helpers.js:152:10)

Please find attached image for information.

Hi,
I've been working with @steelbrain to resolve an issue with an invalid path being returned in OSX in atom (specifically the linter-puppet-lint package, by way of atom-linter, consistent-path, and ultimately shell-path).
Whilst it picks up the path including entries from .bashrc (in my case nvm), the result of .sync doesn't seem to be including /usr/local/bin.
Actual path: /Users/user.name/.nvm/versions/node/v5.3.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
shell-path: /Users/user.name/.nvm/versions/node/v5.3.0/bin:/usr/bin:/bin:/usr/sbin:/sbin

The inside of shell-path, it seems like using shell-env.
It seems like shell-env causes the blow problem. please take a look the below. Thanks.

On Terminal with executing "yarn electron:serve" ::

require() of ES modules is not supported.
require() of .../path-to/node_modules/shell-path/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from ../path-to/node_modules/shell-path/package.json.
x

On Browser Developer Console ::
Uncaught ../path-to/node_modules/shell-path/index.js:1
(function (exports, require, module, __filename, __dirname, process, global, Buffer) { return function (exports, require, module, __filename, __dirname) { import {shellEnv, shellEnvSync} from 'shell-env';
^^^^^^

SyntaxError: Cannot use import statement outside a module
at new Script (vm.js:84:7)
at createScript (vm.js:258:10)
at Object.runInThisContext (vm.js:306:10)
at Module._compile (internal/modules/cjs/loader.js:883:26)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1004:10)
at Module.load (internal/modules/cjs/loader.js:815:32)
at Module._load (internal/modules/cjs/loader.js:727:14)
at Function.Module._load (electron/js2c/asar.js:769:28)
at Module.require (internal/modules/cjs/loader.js:852:19)
at require (internal/modules/cjs/helpers.js:74:18)

When a shell dotfile (eg. .bash_profile, .zshrc) prints directly to the terminal, the $PATH variable is incorrectly read as the string printed by the dotfile.

Repro steps from command line:

1. echo "yo!" >> .zshrc
2. zsh -i -c 'echo "$PATH"'

The shell type (bash, etc) doesn't matter. The bug only surfaces when this technique results in the "longest" version of $PATH

in an electron 0.36.4 app console (sp is require('shell-path')):

whereas sudo -Hiu max "echo $PATH" returns the wrong thing, sudo -Hiu max env has my correct PATH in it

Spawned by sindresorhus/fix-path#3

To handle cases like where zsh users wrongly put PATH modifications into .zshrc instead of zshenv, we should consider using the -i flag to force an interactive shell to obtain the full PATH.

What needs to be done is to investigate which shells have an -i flag or similar.

This simply isn't working for me when trying to run the application as a packaged app. I have tried putting the following code in both my main.js "electron" file (e.g. the one with Electron's createWindow() function), as well as the "client side" javascript that runs once the app launches:

const shellPath = require('shell-path');
process.env.PATH = shellPath.sync();

I still don't end up with the right $PATH variable when executing future shell scripts.

In 8522076, I replaced the normal check with shell-env, which now instead of $ echo $PATH, parses out the PATH from $ env, same as the sudo check does. I'm doubtful how useful the sudo check is now. It actually misses some things, like .zshrc, since it doesn't run the shell interactively.

Need to ensure it still works fine in a packaged app without sudo.

@silverwind What do you think?

Use some kind of execSync polyfill. No native dependencies though.