Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSA: You do NOT need this plugin #64

Closed
marlonrichert opened this issue Apr 6, 2023 · 2 comments
Closed

PSA: You do NOT need this plugin #64

marlonrichert opened this issue Apr 6, 2023 · 2 comments

Comments

@marlonrichert
Copy link

marlonrichert commented Apr 6, 2023

You can create any number of asynchronous processes in Zsh simply by using a file descriptor and process substitution:

typeset -i fd=-1
exec {fd}< <( ... )

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.

@marlonrichert marlonrichert changed the title PSA: You do **not** need this plugin PSA: You do NOT need this plugin Apr 6, 2023
@mafredri
Copy link
Owner

mafredri commented 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.

Closing as a duplicate of #24.

@mafredri mafredri closed this as completed Apr 6, 2023
@marlonrichert
Copy link
Author

You are right, I worded that too aggressively. My apologies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants