Aurelia-cli beta.15 - option selection not working

So I just updated to the new beta.15
Now I cannot select anything but the first option displayed, for instance Default ESNext App is selected and I want to move to Custom App. I tried up/down pgup/pgdn but nothing moves the selection.

Windows 10
Normally use Bash (4.4.19(2)), but also tried CMD and both just ignore me when I try to move the selected option.

What am I doing wrong?


1 Like

So I have installed the npm enquirer project separately and after figuring out npm link to get require to work with the examples have tested that it works fine there for moving the selection.

Anyone else seen this issue?

1 Like

Sounds strange. What’s your nodejs version?

1 Like

just updated it as well, so 10.15.3 (was 8.x.x)

1 Like

So just tried clearing the npm cache, uninstalling/reinstalling aurelia-cli and enquirer select still not working in the cli. Fortunately build and run work okay, so I am only stymied in creating a new cli project it appears.

1 Like

I went back to this to try and figure out what was going on. I had tried in Windows 10 CMD shell, but I think it was before updating node.

It works in CMD now, I can navigate the options fine, but not when using:
GNU bash, version 4.4.19(2)-release (x86_64-pc-msys)

I’ll try updating git.

Apparently that didn’t do anything to correct the problem with using the git installed bash shell.

Here is what I see, notice the project name is overwriting the prompt on entry, and arrow keys do nothing. Wonder if the issue is with Inquirer base or Enquirer itself.

Actually, since I can run the Enquirer project examples fine in bash, is it something being filtered in the CLI?


1 Like

So I was finally able to figure out how to clone the cli and get the debugger running in vscode along with using bash for the (internal) terminal.
Umm, yeah, select using arrows works fine there…go figure.

1 Like

Trying to run debug using external terminal, but it just pops open and then closes even though it should be waiting for input.

If anyone knows how to get that to hang around that would help.

Update: Was able to open a bash terminal, and then using attach instead of launch.
Guess what works when I use :
node --inspect bin/aurelia.js new
node bin/aurelia.js new

but fails using the symlink:
au new

So it appears to be related to the symlink maybe?

1 Like

I can reproduce the issue with git bash on windows, but I have no idea why. We previously also had issue for au new to exit from git bash.

1 Like

lol, and I thought that having to ctl-c to get au new to end was a feature :smiley:

I had better understanding now. It’s related to how git bash run sub process.

When you do au new, git bash runs the file /c/Users/you/AppData/Roaming/npm/au which starts with a shebang #!/bin/sh. git bash creates another sub process of /bin/sh to run the au command.

When you do node examples/select/prompt.js, git bash didn’t create another sh in sub process, but using current shell to run it. There is no issue here.

You can reproduce the same issue with enquirer example with a file try-it

node examples/select/prompt.js

Then you run ./try-it, you get the same problem!

I tried few things, but I could not bypass this issue :frowning:

Update: it’s more complicated than that. My guess on sub-process is not correct. Because the issue can be reproduced with source ./try-it too.

Some related issue around bash on windows, it’s very common.

From inquirer comment: The issue isn’t that I don’t want to support it. The issue is that git bash is not an interactive/TTY terminal. So it just cannot work :frowning:


Thanks for the additional work. I did open a question over on the enquirer github to see if they might have any thoughts, but sounds like you have already nailed it down to bash weirdness.

1 Like

There was native bash on windows through Linux sub system, you may get better result.


FYI the reason behind the tty issue.


As dirty as it can be, this bypassed the issue.

winpty bash $(which au) new

Checked and it does work.

I started to write must be something with the character set, and then read your noted reason on github, and turns out that was it.

I am assuming when ran directly in VS Code its doing something similar to your fix since that works as well.

1 Like