nushell breaks after exiting elixir's shell iex

[mario-mazo]

Describe the bug

Hi while using the elixir programming language there is the iex (elixir interactive shell)
after you exit the shell the ls command is broken.
This happens and fresh install of nu using brew

I have noticed that nushell breaks only if the ls command returns more than 3 rows.

How to reproduce

1. Open iex
2. exit iex using Ctrl+c Ctrl+c
3. ls

~/bin> ls                                                                                              05/01/2023 04:51:28 PM
╭───┬────────┬──────┬──────┬───────────────╮
│ # │  name  │ type │ size │   modified    │
├───┼────────┼──────┼──────┼───────────────┤
│ 0 │ a-file │ file │  0 B │ 2 minutes ago │
│ 1 │ b-file │ file │  0 B │ now           │
╰───┴────────┴──────┴──────┴───────────────╯
~/bin> iex                                                                                             05/01/2023 04:51:30 PM
Erlang/OTP 25 [erts-13.1.5] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]

Interactive Elixir (1.14.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>
BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
       (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
^C
~/bin> ls                                                                                              05/01/2023 04:51:34 PM
╭───┬────────┬──────┬──────┬───────────────╮
│ # │  name  │ type │ size │   modified    │
├───┼────────┼──────┼──────┼───────────────┤
│ 0 │ a-file │ file │  0 B │ 2 minutes ago │
│ 1 │ b-file │ file │  0 B │ now           │
╰───┴────────┴──────┴──────┴───────────────�Error: nu::shell::io_error

  × I/O error
  help: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }

Expected behavior

ls should not show error and should show all the files

~/bin> ls                                                                                              05/01/2023 04:52:20 PM
╭───┬────────┬──────┬──────┬───────────────╮
│ # │  name  │ type │ size │   modified    │
├───┼────────┼──────┼──────┼───────────────┤
│ 0 │ a-file │ file │  0 B │ 3 minutes ago │
│ 1 │ b-file │ file │  0 B │ a minute ago  │
╰───┴────────┴──────┴──────┴───────────────╯
~/bin>                                                                                                 05/01/2023 04:52:20 PM

Screenshots

No response

Configuration

| key                | value                                                             |
| ------------------ | ----------------------------------------------------------------- |
| version            | 0.79.0                                                            |
| branch             |                                                                   |
| commit_hash        |                                                                   |
| build_os           | macos-aarch64                                                     |
| build_target       | aarch64-apple-darwin                                              |
| rust_version       | rustc 1.68.2 (9eb3afe9e 2023-03-27) (built from a source tarball) |
| cargo_version      | cargo 1.68.1 (6feb7c9cf 2023-03-26)                               |
| build_time         | 2023-04-25 20:06:17 +00:00                                        |
| build_rust_channel | release                                                           |
| features           | default, zip                                                      |
| installed_plugins  |                                                                   |

Additional context

Darwin WGFJWY3Q6R 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020 arm64

[amtoine]

i've seen that Resource temporarily unavailable error pop up randomly on ubuntu 🤔
this looks more reliable though, so may be a bug 😮

[mario-mazo]

Hello
This went a away with the new erlang 26 and elixir 15.
Seem like the shell was rewritten from scratch for this version of erlang
and now nushell works fine. You can close this

[exlee]

Would it be possible to reopen this ticket?

While it might work in OTP26, OTP25 is not yet deprecated and it's almost impossible to use Nushell with it.

Steps to reproduce (using Nix)

1. mkdir -p /tmp/elixir; cd /tmp/elixir
2. touch file - important, doesn't fail on empty directory
3. nix shell nixpkgs#elixir_1_14
4. nu --login
5. iex
6. Ctrl-C Ctrl-C
7. ls -l

Error:

  × I/O error
  help: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }

[cpg314]

This seems like a more general problem. I have noticed the same issue even though I do not use elixir. I have not been able to point the exact cause, possibly it is CLIs asking for user inputs or doing some pretty printing.

More precisely, nushell frequently enters a state where

1. Larger command outputs will get stopped early, e.g.

   $ cat /dev/urandom | base64
   [...]
   Ec+3m5grbgTZ1lqBmj6mLYNBeLLfheKAgeZaMSVK2GEdAMIx8+6sOphPc6ToUuTdehb1gkv0lzY7
   $ echo $env.LAST_EXIT_CODE
   1

2. Commands asking for user input will exit immediately

   $ bash -c "read test"
   /usr/bin/bash: line 1: read: read error: 0: Resource temporarily unavailable

I have seen the resource temporarily unavailable (os error 11) message in case 1 as well, when commands are more verbose than my cat | base64 pipe example above.

Unsuccessful fixes:

• Calling reset or clear
• Starting nu inside nu.

Successful fixes:

• Opening a new terminal solves the issue in that new window
• Opening and closing nano!

[exlee]

I’m not entirely sure how Nushell is handling this, but it seems like something is opened and then not closed for some reason. In Elixir, it’s quite obvious — pressing Ctrl-C kills handlers, which might not be cleaning up because of this.

I can’t assist much more right now, but I did check Erlang’s changelog, and these links might be helpful in figuring out why OTP25 is causing the issue while OTP26 isn’t:

• ERL-282: escript fails when redirecting stdout to less and less terminates erlang/otp#3150
• Implement new Erlang shell erlang/otp#6144

Skimming through these, this comment appears to describe the core issue and could help with debugging it in related scenarios.