exec does not working in mingw bash in windows about shelljs

[arturadib]

does that happen regardless of setting the flag {async:true} ?

[shivapoudel]

@arturadib any progress regarding this ;)

[shivapoudel]

Cause stall for this snippet in Windows PowerShell xD
https://github.com/axisthemes/grunt-potomo/blob/master/tasks/potomo.js#L53-L60

Ref: WP-Translations/grunt-transifex-wordpress#9 (comment)

[arturadib]

we recently changed the exec command to use Node's latest execSync.. can you please try the latest version from npm? (0.4.0) thanks

[shazahm1]

@arturadib

The latest update may fix this issue, don't know yet because now there is a new error. I'm guessing it has to due with space characters in the path name. Please see the attached screenshot. Notice the very first error, the path name is truncated at the first space in the path name.
I think there might be an issue with spaces in the path name in po

Ref: WP-Translations/grunt-transifex-wordpress#9 (comment)

[shazahm1]

Oh, it works fine when run from cmd.exe.

[arturadib]

@devtristan I know you've been looking for Windows bugs to solve, this may be a good one! :)

[shazahm1]

Ok, I did two tests...

1. I move my project to a path which did not contain spaces in the path name. I got the exact same error message when using powershell; cmd worked fine.
2. I created a new admin user on my Win8.1 machine and logged into it. This new user did not have a space in its name. I opened powershell and navigated to the project that i created for 1. and it worked.

So the issue definitely has to do with the space in the file path but not the path in relation to the actual project. I suspect it has something to do with the file that shelljs writes to the users temp folder.

[shazahm1]

Ok, I tracked it down to the _tempDir() function.

I changed this:

  state.tempDir = writeableDir(os.tempDir && os.tempDir()) || // node 0.8+
                  writeableDir(process.env['TMPDIR']) ||
                  writeableDir(process.env['TEMP']) ||
                  writeableDir(process.env['TMP']) ||
                  writeableDir(process.env['Wimp$ScrapDir']) || // RiscOS
                  writeableDir('C:\\TEMP') || // Windows
                  writeableDir('C:\\TMP') || // Windows
                  writeableDir('\\TEMP') || // Windows
                  writeableDir('\\TMP') || // Windows
                  writeableDir('/tmp') ||
                  writeableDir('/var/tmp') ||
                  writeableDir('/usr/tmp') ||
                  writeableDir('.'); // last resort

To this:

    state.tempDir = writeableDir('C:\\TEMP') || // Windows
    writeableDir('C:\\TMP') || // Windows
    writeableDir('\\TEMP') || // Windows
    writeableDir('\\TMP') || // Windows
    writeableDir('.'); // last resort

And it worked from powershell. The temp file ended up being written to the project folder instead of the temp folder in c:\TEMP.

What the solution is from here, I do not know... but hopefully this helps!

[arve0]

Any news on this? Experiencing the same (see below) with shelljs 0.5.3.

Error: Command failed: "c:\Program Files\nodejs\node.exe" c:\Users\Arve Seljebu\AppData\Local\Temp\shelljs_5f1db58f6af48df8b8a5
    at checkExecSyncError (child_process.js:464:13)
    at Object.execSync (child_process.js:504:13)
    at execSync (c:\Users\Arve Seljebu\Documents\GitHub\lesson_editor\node_modules\shelljs\src\exec.js:81:11)
    at _exec (c:\Users\Arve Seljebu\Documents\GitHub\lesson_editor\node_modules\shelljs\src\exec.js:214:12)
    at c:\Users\Arve Seljebu\Documents\GitHub\lesson_editor\node_modules\shelljs\src\common.js:182:23
    at Object.<anonymous> (c:\Users\Arve Seljebu\Documents\GitHub\lesson_editor\ghpages.js:13:1)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)

[arve0]

@ariporad Why remove the bug label? Is breaking on usersnames with spaces intended behavior?

I see you write

1. I'm going to setup some better labels, is that OK?

in #272. What is a better label?

[nfischer]

I think he just removed all the old labels. I think the label we're using for bugs is "fix" (although I personally liked the "bug" label better). I suppose if we think of "fix" as meaning "please fix this" for github issues and "fix" as meaning "this is a fix" for pull requests, then it all makes sense.

[ariporad]

@arve0, @nfischer: Yeah, that's exactly right. I have a script which nukes all the existing labels and creates new ones.

@nfischer: The reason for fix is that at the time we were planning to use the commit message guidelines, so I created a label for each commit message type (chore/fix/test/feat/etc.).

[nfischer]

Yup, I figured that was the other reason.

Back to the issue at hand, I think we agree that this is in fact an issue, and I've applied the label. I'll try testing out #263 and see if this is in fact an issue and if that fixes the concern.