Termux hangs when in directory with Node.js project

[12ohit]

Current Behavior

when I cd into a folder where let's say package.json file is present, I have configured starship to show Node.js version in prompt, but because of that it hangs and I can't do anything until I do ctrl + c few times, then I can type my next command or anything but then it again hangs and I have to do ctrl + c again.

Expected Behavior

The terminal should not hang and work as usual

Additional context/Screenshots

I am using Termux with Android 11. Check the screenshot.

I am guessing what I provided should be enough, if not I will be happy to provide additional info.

Environment

• Starship version: 1.20.1
• fish version: fish, version 3.7.1
• Operating system: Android Unknown
• Terminal emulator:
• Git Commit Hash:
• Branch/Tag:
• Rust Version: rustc 1.79.0 (129f3b996 2024-06-10)
• Rust channel: 1.79.0-x86_64-unknown-linux-gnu release
• Build Time: 2024-07-28 16:16:36 +00:00

Relevant Shell Configuration

source ~/.config/fish/alias.fish

if status is-interactive
    # Commands to run in interactive sessions can go here
end

# Install Starship
starship init fish | source

# Remove welcome message
set -g -x fish_greeting ''

# Fish syntax highlighting
set -g fish_color_autosuggestion 'aaa'

Starship Configuration

"$schema" = 'https://starship.rs/config-schema.json'

format = """
[](color_orange)\
[](bg:color_orange fg:color_fg0)\
[ Rohit ](bg:color_orange fg:color_fg0)\
[](bg:color_yellow fg:color_orange)\
$directory\
[](fg:color_yellow bg:color_aqua)\
$git_branch\
$git_status\
[](fg:color_aqua bg:color_blue)\
$nodejs\
[](fg:color_blue bg:color_bg3)\
$docker_context\
$conda\
[](fg:color_bg3 bg:color_bg1)\
$time\
[ ](fg:color_bg1)\
$line_break$character"""

palette = 'gruvbox_dark'

[palettes.gruvbox_dark]
color_fg0 = '#fbf1c7'
color_bg1 = '#3c3836'
color_bg3 = '#665c54'
color_blue = '#458588'
color_aqua = '#689d6a'
color_green = '#98971a'
color_orange = '#d65d0e'
color_purple = '#b16286'
color_red = '#cc241d'
color_yellow = '#d79921'

[directory]
style = "fg:color_fg0 bg:color_yellow"
format = "[ $path ]($style)"
truncation_length = 3
truncation_symbol = "…/"
home_symbol = "󰋜 "

[directory.substitutions]
"documents" = "󰈙 "
"downloads" = " "
"music" = "󰝚 "
"pictures" = " "
"workspace" = "󰲋 "

[git_branch]
symbol = ""
style = "bg:color_aqua"
format = '[[ $symbol $branch ](fg:color_fg0 bg:color_aqua)]($style)'

[git_status]
style = "bg:color_aqua"
format = '[[($all_status$ahead_behind )](fg:color_fg0 bg:color_aqua)]($style)'

[nodejs]
symbol = ""
style = "bg:color_blue"
format = '[[ $symbol( $version) ](fg:color_fg0 bg:color_blue)]($style)'

[time]
disabled = false
time_format = "%R"
style = "bg:color_bg1"
format = '[[  $time ](fg:color_fg0 bg:color_bg1)]($style)'

[line_break]
disabled = false

[character]
disabled = false
success_symbol = '[](bold fg:color_green)'
error_symbol = '[](bold fg:color_red)'
vimcmd_symbol = '[](bold fg:color_green)'
vimcmd_replace_one_symbol = '[](bold fg:color_purple)'
vimcmd_replace_symbol = '[](bold fg:color_purple)'
vimcmd_visual_symbol = '[](bold fg:color_yellow)'

[Runner-coder]

Has anyone looked into this yet cause I'm facing the same issue. I first encountered this while using pastel-powerline preset which uses node module to display NodeJs version.I'm using it on default bash shell.In my case it happens when I repeatedly press enter several times spawning the prompt.It hangs after like 10 tries and then I have to press ctrl+c and enter although it doesn't work all the time. Sometimes it just happens randomly too. If I leave it in hang state for some time eventually get this error

[WARN] - (starship::utils): Executing command "/data/data/com.termux/files/usr/bin/node" timed out.
[WARN] - (starship::utils): You can set command_timeout in your config to a higher value to allow longer-running commands to keep executing.

I haven't tested this with other fiIe extensions like ".jar" so I'm not sure if this is related to just the node module.

If I disable the node module it works fine but that's a workaround not a solution.
But if I run this

export STARSHIP_NUM_THREADS=1

then all the sudden it works correctly (at least for me) without having to disable node module which is kinda confusing cause it's completely the opposite of the workaround suggested in this issue #4251 where they suggest to set it to 6. Anything above 1 doesn't work for me. Can OP try this and confirm the results please?

I hope this bug get fixed soon since it's been over like 3 months !

[12ohit]

Thanks for your response @Runner-coder , as you suggested I tried for doing export STARSHIP_NUM_THREADS=1 then changing the directory to some that has node project. And yes as long as the STARSHIP_NUM_THREADS=1 variable is set to 1 my terminal doesn't get stuck.

This is not a proper solution though, or I hope to get a better explanation of why setting STARSHIP_NUM_THREADS to 1 helps to solve the problem.

Edit: For now I will add export STARSHIP_NUM_THREADS=1 in my ~/.config/fish/config.fish file as a temporary solution.

[YDX-2147483647]

I've made a experiment, and I think it is https://docs.rs/process_control to be blamed.

Conclusions

1. The issue is not specific to Node.js / Termux / OS.

2. It hangs if node/deno/… --version takes too much time.

3. To be specific, in crate::utils::exec_timeout, process.controlled_with_output().time_limit(time_limit) might keep the process running after the time is out. As a result, the shell starts waiting for it indefinitely.

   starship/src/utils.rs

   Lines 563 to 574 in d510240

   	pub fn exec_timeout(cmd: &mut Command, time_limit: Duration) -> Option<CommandOutput> {
   	let start = Instant::now();
   	let process = match cmd.spawn() {
   	Ok(process) => process,
   	Err(error) => {
   	log::info!("Unable to run {:?}, {:?}", cmd.get_program(), error);
   	return None;
   	}
   	};
   	match process
   	.controlled_with_output()
   	.time_limit(time_limit)

Details of the experiment

Details of the experiment

Environment: d510240, Windows 10, PowerShell 7, deno v2.1.4.

1. Disable/uninstall the system starship, rename/remove ~/.config/starship.toml, and stop all deno processes.

2. Edit src/utils.rs, add let time_limit = Duration::from_millis(100); in fn exec_timeout(…). Then cargo build.
   (If you meet a cmake issue on Windows, please see 1.1.20 failed in cmake stage on windows 10 rust-lang/libz-sys#229.)

3. mkdir test-deno && cd test-deno && touch deno.json.

4. $env:STARSHIP_LOG='trace'.

5. Invoke-Expression (&cargo r -- init powershell), and you will get stuck. (If not, close the shell and restart from step 4.)

   [TRACE] - (starship): Parsed arguments: Cli { … }
   …
   [TRACE] - (starship::utils): Trying to read from "C:\\Users\\…\\.config\\starship.toml"
   …
   [TRACE] - (starship::config): Read predefined color: bright-black
   😢 freeze here
   

   Moreover, Ctrl+C may not work.

6. Now look at the processes, and you will find a deno -V started just now running with 0.00% CPU.

   (Open another shell)
   $ Get-Process -Name deno | Format-Table -Property Name,Id,CPU,StartTime,CommandLine
   
   Name	Id		CPU		StartTime	CommandLine
   ----		--			---		---------		-----------
   deno	XXX		0.00		(just now)	"path/to/deno.exe"  -V

7. Stop-Process -Name deno, and suddenly Invoke-Expression (&cargo r -- init powershell) becomes alive, popping out tons of trace logs.

   …
   [TRACE] - (starship::utils): Using "path/to/deno.exe" as "deno"
   …
   
   [WARN] - (starship::utils): Executing command "path/to/deno.exe" timed out.
   [WARN] - (starship::utils): You can set command_timeout in your config to a higher value to allow longer-running commands to keep executing.
   [TRACE] - (starship::config): No color palette specified, using defaults
   [TRACE] - (starship::config): Parsing color_string: green
   [TRACE] - (starship::config): Read predefined color: green
   [TRACE] - (starship::modules): Took 478.7462ms to compute module "deno"
   

Update

I might be wrong?

• ☹Invoke-Expression (&cargo r -- init powershell) hangs before [TRACE] - (starship::utils): Using "path/to/deno.exe" as "deno".
• ✅cargo r -- prompt is always fine.
• ✅cargo r -- module deno is always fine.
• ☹(cargo r -- module deno) hangs after [TRACE] - (starship::modules): Took 352.1846ms to compute module "deno".
• ✅(cargo r -- module git_status) is fast (<200ms) and always fine.
• ☹(cargo r -- module typst) hangs after [TRACE] - (starship::modules): Took 176.9481ms to compute module "typst".

Weird…