eval "man -k ." | fzf | read hangs on mac

[introom]

eval "man -k ." | fzf | read
fish version 3.1.0
macos

Used to work fine before 3.1.0

[krobelus]

I can reproduce when running fish interactively, it seems like first read takes control of the terminal.
If you press Control-C after some time, the fzf UI becomes visible.

Happens since 2fe2169 which made eval a builtin because fish blocks when executing builtins.

This workaround seems to restore the old behavior:

begin; eval "man -k ."; end | fzf | read

(or man -k . | fzf | read)

[zanchey]

@ridiculousfish @mqudsi any thoughts? If the workaround is enough, I don't think this needs to be fixed for 3.1.*, though of course it would be nice.

[ridiculousfish]

I thought this would be the same as #6624 but it doesn't appear to be.

[ridiculousfish]

This ends up being similar to #6624 except we need to thread the pgid into eval as well.

[ridiculousfish]

So the problems here are:

1. Commands spawned by eval would run in a different pgroup. which would fight with fzf for control of the terminal. So we have to tell eval to propagate the pgroup.
2. eval would just propagate the io_chain, but this might contain a pipe that is intended to be used by fzf, which is not yet launched. So we would deadlock. The fix is for eval to direct its output to the provided buffers, like other builtins..

This points the way for a lot of cleanup - output_stream_t is "the thing that builtins write to" and should be unified with io_data_t. Also pgroup management continues to vex but I have a plan for that.

I think this should go into a patch release, I will prepare a commit.

[ridiculousfish]

I merged this into 3.1.1 as 5fccfd8

[novadev94]

I'm having some trouble with the newest change, all "eval" commands here hang up: https://github.com/junegunn/fzf/blob/master/shell/key-bindings.fish

Can reproduce it with a simple command like eval vim foo.txt, it works fine with revision 389c5e7

[krobelus]

Probably the non-buffering behavior can safely be restored for streams that are not redirected:

diff --git a/src/builtin_eval.cpp b/src/builtin_eval.cpp
index c9495a669..52b33d2f4 100644
--- a/src/builtin_eval.cpp
+++ b/src/builtin_eval.cpp
@@ -27,22 +27,34 @@ int builtin_eval(parser_t &parser, io_streams_t &streams, wchar_t **argv) {
         new_cmd += argv[i];
     }
 
+    shared_ptr<io_bufferfill_t> stdout_fill, stderr_fill;
+    io_chain_t io = *streams.io_chain;
     // The output and errput of eval must go to our streams, not to the io_chain in our streams,
-    // because they may contain a pipe which is intended to be consumed by a process which is not
-    // yet launched (#6806). Make bufferfills to capture it.
-    // TODO: we are sloppy and do not honor other redirections; eval'd code won't see for example a
-    // redirection of fd 3.
-    shared_ptr<io_bufferfill_t> stdout_fill =
-        io_bufferfill_t::create(fd_set_t{}, parser.libdata().read_limit, STDOUT_FILENO);
-    shared_ptr<io_bufferfill_t> stderr_fill =
-        io_bufferfill_t::create(fd_set_t{}, parser.libdata().read_limit, STDERR_FILENO);
-    if (!stdout_fill || !stderr_fill) {
-        // This can happen if we are unable to create a pipe.
-        return STATUS_CMD_ERROR;
+    // because they may contain a pipe which is intended to be consumed by a process which is
+    // not yet launched (#6806). Make bufferfills to capture it.
+    // TODO: we are sloppy and do not honor other redirections; eval'd code won't see for
+    // example a redirection of fd 3.
+    if (streams.out_is_redirected) {
+        stdout_fill =
+            io_bufferfill_t::create(fd_set_t{}, parser.libdata().read_limit, STDOUT_FILENO);
+        if (!stdout_fill) {
+            // This can happen if we are unable to create a pipe.
+            return STATUS_CMD_ERROR;
+        }
+        io.push_back(stdout_fill);
+    }
+    if (streams.err_is_redirected) {
+        stderr_fill =
+            io_bufferfill_t::create(fd_set_t{}, parser.libdata().read_limit, STDERR_FILENO);
+        if (!stderr_fill) {
+            // This can happen if we are unable to create a pipe.
+            return STATUS_CMD_ERROR;
+        }
+        io.push_back(stderr_fill);
     }
 
     int status = STATUS_CMD_OK;
-    auto res = parser.eval(new_cmd, io_chain_t{stdout_fill, stderr_fill}, streams.parent_pgid);
+    auto res = parser.eval(new_cmd, io, streams.parent_pgid);
     if (res.was_empty) {
         // Issue #5692, in particular, to catch `eval ""`, `eval "begin; end;"`, etc.
         // where we have an argument but nothing is executed.
@@ -54,12 +66,15 @@ int builtin_eval(parser_t &parser, io_streams_t &streams, wchar_t **argv) {
     // Finish the bufferfills - exhaust and close our pipes.
     // Note it is important that we hold no other references to the bufferfills here - they need to
     // deallocate to close.
-    std::shared_ptr<io_buffer_t> output = io_bufferfill_t::finish(std::move(stdout_fill));
-    std::shared_ptr<io_buffer_t> errput = io_bufferfill_t::finish(std::move(stderr_fill));
+    if (stdout_fill) {
+        std::shared_ptr<io_buffer_t> output = io_bufferfill_t::finish(std::move(stdout_fill));
+        streams.out.append_narrow_buffer(output->buffer());
+    }
 
-    // Copy the output from the bufferfill back to the streams.
-    streams.out.append_narrow_buffer(output->buffer());
-    streams.err.append_narrow_buffer(errput->buffer());
+    if (stderr_fill) {
+        std::shared_ptr<io_buffer_t> errput = io_bufferfill_t::finish(std::move(stderr_fill));
+        streams.err.append_narrow_buffer(errput->buffer());
+    }
 
     return status;
 }

[max-sixty]

FYI having upgraded to 3.1.1, my fzf shortcuts now cause the shell to hang. Is this related? Lmk if I can provide any info to make resolving this easier. Thanks. (and thanks for such an awesome shell!)

[ridiculousfish]

@krobelus you were exactly right, I wish I had spotted your review before the 3.1.1 release! #6955 is tracking the regression I introduced. @max-sixty, that's what you're encountering as well.

[max-sixty]

Thanks @ridiculousfish & @krobelus !

[krobelus]

@ridiculousfish Sadly I didn't see it either until after the release when the reports came in.

[novadev94]

Just tested out the latest commit on master, things now work like a charm! Thanks to all you guys!