power-assert output not showing on git bash on Windows
Closed this issue · 15 comments
I'm getting (unxpected?) output fail messages...
EDIT: the problem is on git bash. Using cmd (I'm on windows), the output is different.
Actual (cmd):
× [anonymous]
t.true(a.test(b) || b === c)
| | | |
| "bar" "bar" "baz"
false
1 test failed [10:23:10]
1. [anonymous]
AssertionError: false === true
Test.t [as fn] (avaTests.js:12:3)
_combinedTickCallback (internal/process/next_tick.js:67:7)
process._tickCallback (internal/process/next_tick.js:98:9)
npm ERR! Test failed. See above for more details.
not sure if the whole combinedTickcallback etc should appear though....
Actual (git bash):
1 failed
1. [anonymous]
false === true
Test.fn (C:/Users/rickm/Documents/Google Drive/Side-projects/Programming/NodeJS/js-playground/tdd/avaTests.js:12:9)
_combinedTickCallback (internal/process/next_tick.js:67:7)
process._tickCallback (internal/process/next_tick.js:98:9)
npm ERR! Test failed. See above for more details.
Test Source
const test = require('ava')
test(t => {
const a = /foo/;
const b = 'bar';
const c = 'baz';
t.true(a.test(b) || b === c);
})
Config
no config
Command-Line Arguments
no config args
Environment
node 6.3.0
npm 3.10.6
ava 0.15.2
win10 x64
not sure if the whole combinedTickcallback etc should appear though....
It should not, but that's an unrelated issue. I've reported it here: tapjs/stack-utils#14
// @twada
power-assert is just an assertion message string creator. It does not print messages by itself.
Therefore, to determine the problem,
@rickmed would you add failing assertion with simple assertion message that does not trigger power-assert
t.true(false, 'THIS IS AN ASSERTION MESSAGE')
;
and see what happens both on cmd and git bash?
@twada Both print the same thing:
> ava --verbose
× My Test description THIS IS AN ASSERTION MESSAGE
1 test failed [08:59:39]
1. My Test description
AssertionError: THIS IS AN ASSERTION MESSAGE
Test.t [as fn] (avaTests.js:48:3)
_combinedTickCallback (internal/process/next_tick.js:67:7)
process._tickCallback (internal/process/next_tick.js:98:9)
npm ERR! Test failed. See above for more details.
@rickmed Thank you for clarifying!
And, hmm... I don't have git bash env so I need some help.
Labeled as help wanted
since I don't have environment to reproduce this issue.
Hmm, I can't reproduce this:
- git bash 2.9.3.windows.1
- ava 0.16.0 and 0.15.2
- node 6.3.1
- Windows 10 insider build 14905
I've definitely hit power-assert failing in some cases (for me, when used from a _helper.test.js
), but never a difference between cmd, git bash or even new ubuntu on windows.
I would suspect different paths for node
or global node_modules
are causing different versions to run?
@rickmed could you clarify what git bash
is? Going by https://git-for-windows.github.io/ it's a bash emulator thing, though with https://msdn.microsoft.com/en-us/commandline/wsl/about being available that may not be as necessary to use at it once was.
@novemberborn - wsl is still kind of a train wreck (for example, editing things in the wsl area from outside on disk can corrupt the entire image.)
most windows node developers use git bash
@StoneCypher There is a reason %LOCALAPPDATA%\lxss
is super-hidden (not visible even with show hidden files), it's not for you. Use /mnt/c
like you're meant to. You may as well complain about how editing config files in C:\Windows with Word breaks your OS means that Windows or Word are "kind of a train wreck" (maybe they are, but that sure isn't why)
So this isn't a useless reply, Git Bash is the bash that is shipped with the windows version of git (eg git-scm.com
), it is a cut-down repackaging of MSYS2 with what is required to run git (which is partially implemented as shell scripts). As it is MSYS2, it is based on cygwin, and requires some nasty hacks internally to get things like fork()
to work in user-space, and requires re-compilation. That said, it mostly works fine, but since WSL came out I've completely switched to it and been much happier.
That said, I think this issue can be closed as unreproducable?
@simonbuchan - as a word of advice, pretty much everyone who knows that limitation exists also knows why it exists.
given that we can't use windows software with the stuff running on our windows machine, because of a technical limitation not shared by any of the existing solutions, such as cygwin or virtual machines or so on, because just opening the file potentially corrupts an entire drive?
i'm standing by my evaluation that wsl
is currently a technical train wreck
🙄
Just in case you are actually interested in doing real work, rather than trying to win points on the internet on a pointless issue on a pointless github issue, put your code in /mnt/c/...
, like I said.
WSL can run windows apps, and windows tools can see your files. Where's the issue? (That's a rhetorical question, I won't actually reply further to this)
It turns out that I do real work every day.
If you choose to ask politely, I'll explain why that won't actually work. Or you could ask google.
Failing that, please have a nice day.
Lots of stuff has changed since this issue was opened. I'm closing due to inactivity, but please leave a comment if this is still a problem.