Unexpected stdout chars on neovim job api with pty enabled.

[supermomonga]

Describe the bug

When attempting to start the devcontainer using the :RemoteStart command, an error occurs at the point where the provider tries to execute the devpod command using the executor and then decode the resulting stdout as JSON.

I noticed that unexpected characters were mixed into stdout. As an experiment, I modified the implementation of executor.lua and disabled the pty option on Neovim's job API (vim.fn.jobstart()). By doing so, this error with stdout disappeared.

To reproduce

Minimal steps for reproduce:

vim.fn.jobstart without pty option

1. Run neovim without any config using nvim -u NONE.
2. Run :lua vim.fn.jobstart('devpod version', { pty = false, on_stdout = function(_, data, _) vim.api.nvim_echo({data}, true, {}) end })
3. Run :mes to show echo history

vim.fn.jobstart with pty option

1. Run neovim without any config using nvim -u NONE.
2. Run :lua vim.fn.jobstart('devpod version', { pty = true, on_stdout = function(_, data, _) vim.api.nvim_echo({data}, true, {}) end })
3. Run :mes to show echo history

Expected behavior

:RemoteStart will not fail to parse stdout

Screenshot/Screencast(s)

Please see above description and reproduce steps.

System information

• Your local OS: macOS 13.6.9
• CPU model: Apple M2 (Apple Silicon)
• Local Neovim version: v0.10.2
• Remote host OS (if applicable): none
• Remote Neovim version (if applicable): none
• devpod cli version: v0.6.1

Additional context

I'm using macOS's default terminal app and default shell (zsh).

[surgiie]

I believe this is what is causing my issues as i asked about here: https://github.com/amitds1997/remote-nvim.nvim/discussions/184.

[net-caster]

@surgiie I'm experiencing the same issue too. Just left a comment on your thread

[neevparikh]

Also seeing this issue, seems like we want https://neovim.io/doc/user/lua.html#vim.system() instead? see note here: https://neovim.io/doc/user/builtin.html#jobstart().

[neevparikh]

Just a note, swapping all calls to pty=false causes other stuff to break (namely finding free ports on remote), my hack is adding pty to the job opts and passing it in only for the decode call

[oldgalileo]

Ran into the same issue on an MBP M4 trying to start a remote repository for https://github.com/microsoft/vscode-remote-try-rust

Also confirmed that manually setting the pty to false on the devpod list providers worked.

[Alby407]

I can confirm this bug on a Macbook Pro M3, macOS 15.3.2 when using a Docker-based method. Setting pty=false in executor.lua fixes this. Didn't have any problems yet.