A hang occurs when typing source /dev/stdin

[AumyF]

Describe the bug
Nushel hangs when trying to type source /dev/stdin.

To Reproduce

1. Open Nushell
2. Try to type source /dev/stdin
3. It hangs when pressing the last N key and the letter n is not displayed

Expected behavior
It should not hang.

Screenshots

Configuration (please complete the following information):

Run version | pivot and paste the output to show OS, features, etc.

> version | pivot
  #        Column0                                               Column1
────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  0   version              0.33.0
  1   build_os             linux-x86_64
  2   rust_version         rustc 1.53.0
  3   cargo_version        cargo 1.53.0
  4   pkg_version          0.33.0
  5   build_time           2021-07-20 18:48:12
  6   build_rust_channel   release
  7   features             clipboard-cli, ctrlc, default, ptree, rustyline, term, trash, uuid, which, zip
  8   installed_plugins    binaryview, chart bar, chart line, fetch, from bson, from sqlite, inc, match, post,
                           ps, query json, s3, selector, start, sys, textview, to bson, to sqlite, tree, xpath

Add any other context about the problem here.

[fdncred]

Yup, this is a bug that we've seen before. The last time it in Windows. source con any word starting with con will hang nushell. Thanks!

[AumyF]

Thank you for replying! I read #3785 and reproduced the bug on Windows. I thought that these are essentially same bugs because both CON in Windows and /dev/stdin in Linux are special files used to receive console input.

In addition to this, I found:

• nushell hangs on typing source foo if foo is a file which contains source /dev/stdin in Linux or source CON in Windows
• cp, mv, open, rm, save and touch do not hang

[fdncred]

On Windows we need to add all these, not just CON.

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9

I'm not sure all the items on Linux/Mac we need to ignore.

I'm hoping that @jntrnr will be able to make these changes in the code that he's experimenting in.

[github-actions]

This issue is being marked stale because it has been open for 90 days without activity. If you feel that this is in error, please comment below and we will keep it marked as active. Otherwise, it will be closed in 10 days.

[rgwood]

Confirmed that this is still an issue with source /dev/stdin in v0.72.

[zoechi]

I just run into an issue that looks similar but unrelated to dev/stdin.

For me it happens when I target the file ~/.cargo/bin/nu_plugin_net like

register ~/.cargo/bin/nu_plugin_net

It hangs when I type the last character (t) and the character is not shown anymore.
When I start with

~/.cargo/bin/nu_plugin_net

and try to prepend it with register it hangs when I enter the r

It also hangs with

nu -c "register ~/.cargo/bin/nu_plugin_net"

but in this case Ctrl+c ends the command and I get the cursor back.

Most other plugins don't cause this issue (nu_plugin_query, nu_plugin_gstat, nu_plugin_plist, nu_plugin_plot).
register nu_plugin_from_parquet also hangs though.

Same behavior in Kitty and Gnome Terminal

 version              0.74.0                                          
 branch                                                               
 commit_hash                                                          
 build_os             linux-x86_64                                    
 build_target         x86_64-unknown-linux-gnu                        
 rust_version         rustc 1.68.0-nightly (4781233a7 2023-01-16)     
 rust_channel         nightly-x86_64-unknown-linux-gnu                
 cargo_version        cargo 1.68.0-nightly (1cd6d3803 2023-01-12)     
 pkg_version          0.74.0                                          
 build_time           2023-01-17 18:41:35 +01:00                      
 build_rust_channel   release                                         
 features             database, dataframe, default, trash, which, zip 
 installed_plugins    gstat, query, query json, query web, query xml  

[fdncred]

For me it happens when I target the file ~/.cargo/bin/nu_plugin_net like

This is because you're trying to register a plugin that isn't compiled against the latest nushell and/or nushell has had signature changes that requires plugins to be recompiled. The plugin system is pretty brittle and unforgiving atm. If you try to use an old or incompatible plugin, you'll get this behavior.

[zoechi]

But nushell hangs before I can press enter to execute the command.

[fdncred]

But nushell hangs before I can press enter to execute the command.

Yes, I realize this. It's because nushell is doing it's thing without telling you about it as it's parsing your text.

[zoechi]

Ok, I wasn't sure this was clear.
I assumed it might do the same "it's thing" in the original issue and the one I run into.

[fdncred]

I think it's pretty much the same, although source and register do different things.

[zoechi]

But both commands are not yet executed, or are they?
I assumed it's completion or something like that that kicks in at this point.

[fdncred]

I believe it's nushell trying to parse, not only the command line, but the files your typing on the command line, as you're typing. i could be wrong though.

[zoechi]

@fdncred In my case it seems to be related to plugin encoding, but I didn't get to the bottom of it yet. Somehow it gets stuck when it tries to read from the plugin.

[fdncred]

@zoechi You could be right but I tend to think it's more about calling outdated plugins as I've had this problem many times.

[zoechi]

@fdncred
Looks like its stuck in blocking read in both cases.
In the plugin case when it tries to read the decoding

let encoding = get_plugin_encoding(&mut stdout_reader)?;

and in the /dev/stdin case it tries to read from the path and also is stuck, probably because nothing can be received

if let Ok(contents) = std::fs::read(&path) {

It looks like there is no straight forward way to deal with blocking reads in rust.
Are there places in the code base where this situation is covered (where I could steal the approach)?

[fdncred]

I'm not sure. I'm not familiar with these parts of the code base. I don't see anything else that uses ChildStdout, but maybe you could google for it?

[zoechi]

@fdncred it's just about reading from a file handle in a non-blocking way in Rust.
I haven't found much about how to solve this.
Tokio seems to provide something with async and I found 2 crates that address that, but they all don't appear to be a particularly good fit for this project.
Should I initiate a discussion in Discord?

[fdncred]

Should I initiate a discussion in Discord?

Yes, definitely. It's always better to discuss on Discord than here.

[zoechi]

I looked into it (#3822 (comment)) but I won't have time anytime soon to work on a fix. Just in case my comments above led to the assumption, I'm working on it.