avajs/ava

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 commented

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.
twada commented

@rickmed Thank you for clarifying!

And, hmm... I don't have git bash env so I need some help.

twada commented

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.