better behaviour of interactive commands like mkfs and terminal in non tty mode

[Ognian]

Hello,
when using interactive commands like 'mkfs' or 'terminal' in non tty mode (i.e. web storm run mode, which is very convenient since you have only to double click on the defined scripts in package.json)
I noticed some issues:

• although the command finishes the nodejs scripts doesn't end
• the terminal command should issue additional new line chars
  Looks like this is actually a commander issue, maybe this one: Support piping tj/commander.js#137

Thanks
Ognian

[AndiDittrich]

Dear Ognian,

did you tried the --noninteractive option of the mkfs command ? this executes the command without any user input (no prompt).

the terminal mode is interactive by design...to execute a remote lua file and view the output there is the run command available

[Ognian]

Hi Andi
as you may already noticed I'm trying to "automate" my "IDE" workflow, so I have the following npm scripts (nodemcu-tool is a local dependency):

"scripts": {
        "ls":"node_modules/.bin/nodemcu-tool fsinfo",
        "upload-app":"node_modules/.bin/nodemcu-tool upload app/*",
        "devices":"node_modules/.bin/node_modules/.bin/nodemcu-tool devices",
        "format":"node_modules/.bin/nodemcu-tool mkfs --noninteractive",
        "flash-fw":"esptool.py --port /dev/tty.SLAB_USBtoUART write_flash -fm qio 0x00000 firmware/nodemcu-master-10-modules-2017-04-12-15-24-09-float.bin",
        "flash-fw-dev":"esptool.py --port /dev/tty.SLAB_USBtoUART write_flash -fm qio 0x00000 firmware/nodemcu-dev-10-modules-2017-04-14-15-13-54-float.bin",
        "erease-flash-fw":"esptool.py --port /dev/tty.SLAB_USBtoUART erase_flash",
        "pwd": "pwd",

        "terminal":"node_modules/.bin/nodemcu-tool terminal",
        "terminal-py":"nodemcu-uploader --port /dev/tty.SLAB_USBtoUART terminal"
    },

First I would suggest to add this as an usage example to the readme, maybe this helps others to start quicker using this wonderful tool.

Second my workflow actually is:

1. ensure no (nodemcu) terminal is running; start upload-app via double click in npm window; look for errors
2. in (webstorm) terminal window enter npm run terminal-py
3. enter there node.restart()
4. ctrl+ü ends (nodemcu) terminal; repeat from 1

So I see here room for improvement:

• I use the python terminal since with your terminal I noticed the following problem: When the board is reset it starts an "auto baud" detection producing random characters. Some of these characters make the (webstorm) terminal window to somehow switch characters, from there on all output is unreadable garbage, and I have to quit the webstorm terminal and reopen it and change to the correct path...
  A solution to this is maybe to filter output for only printable characters somehow (maybe even as an option).

• It is very annoying that I have to first close the terminal before I'm able to upload my program and then reopen the terminal again. Sometimes I forget to do this and even don't notice that the upload fails....
  So maybe there is an easy way how to start the terminal and leave it open and be able to start commands who get executed....

What do you think?

Ognian

[AndiDittrich]

Dear Ognian,

thanks for your feedback!

if you like you can create a pull request with a new doc file like docs/WebstormIntegration.md with some setup instructions for the users ?

your questions

1. theses "characters" are messages from the bootloader sent with 57k6 baudrate. the most easy solution would be a filter which drops such chars as suggested

2. A persistent terminal is a real problem...the tool is designed for "one shot operations". i know that this is not the best solution...

To change this i have to refactor the whole codebase... this take some time and i'm not sure if NodeMCU LUA is so popular anymore that it pays of...most of the users i know switched to the ardu*no IDE integration..

best regards, Andi

[Ognian]

Hello again,

• PR Create WebstormIntegration.md #33 created.
• in my opinion your tool is very valuable since it requires only nodejs; I would even vote for a firmware flashing option, but this would require even more time maybe :-)
  Ognian