You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can then later read the output from the file descriptor (FD) this creates. For example, you can redirect your FD's output straight to your terminal:
<&$fd
or use read to capture the output in a variable for further processing:
local REPLY=''read -ru $fd
Both of these will wait for input to be available and finish when the process behind the file descriptor is done.
Alternatively, if you want to process the output immediately as it becomes available, use the Zsh Line Editor (ZLE) to connect a handler widget to the FD and process the output there:
zle -Fw "$fd" widget
zle -N widget handler-function
handler-function() {
local -i fd=$1
zle -F $fd# Unhook immediately, to avoid getting called more than once.
...
}
In any case, wrap your processing code in an always block to make sure you close the FD when you're done:
{
...
} always {
exec {fd}<&-
}
This all is much more efficient than using this plugin, which uses a pseudoterminal to asynchronously run your code in an interactive shell.
The text was updated successfully, but these errors were encountered:
marlonrichert
changed the title
PSA: You do **not** need this plugin
PSA: You do NOT need this plugin
Apr 6, 2023
While I appreciate you sharing knowledge, I would've appreciated a slightly less aggressive take. This style of writing is suitable elsewhere, but on the projects own issue tracker? It does feel like you have a personal vendetta with this project.
Anyway, this issue does ignore a bunch of features that are part of this library, like timing commands, separating stdout/stderr, canceling in-progress work and ability to know when commands complete (even without zle watcher), etc. Obviously most of that can be implemented with this method, yet at some point you may have zsh-async2.
I have considered creating backends for this project, e.g. zpty and subshell, where the latter would use the method you wrote about. Haven't gotten around to it though.
You can create any number of asynchronous processes in Zsh simply by using a file descriptor and process substitution:
You can then later read the output from the file descriptor (FD) this creates. For example, you can redirect your FD's output straight to your terminal:
or use
read
to capture the output in a variable for further processing:Both of these will wait for input to be available and finish when the process behind the file descriptor is done.
Alternatively, if you want to process the output immediately as it becomes available, use the Zsh Line Editor (ZLE) to connect a handler widget to the FD and process the output there:
In any case, wrap your processing code in an
always
block to make sure you close the FD when you're done:This all is much more efficient than using this plugin, which uses a pseudoterminal to asynchronously run your code in an interactive shell.
The text was updated successfully, but these errors were encountered: