stdout is not a terminal in fish_command_not_found?

[emilazy]

This came up while porting a command-not-found script to fish and I'm genuinely not sure what's going on here. 0 and 2 (stdin and stderr) behave normally. Can anyone explain this behaviour to me or is it a strange bug? Something to do with the way the output of fish_command_not_found is handled?

emily@yuyuko ~> sh -c 'env HOME=$(mktemp -d) fish'
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
emily@yuyuko /U/emily> fish --version
fish, version 3.6.1
emily@yuyuko /U/emily> echo $version
3.6.1
emily@yuyuko /U/emily> function emily_test; if ! test -t 1; echo oops; end; end
emily@yuyuko /U/emily> emily_test
emily@yuyuko /U/emily> function fish_command_not_found; if ! test -t 1; echo oops; end; end
emily@yuyuko /U/emily> this-command-does-not-exist
oops
emily@yuyuko /U/emily [127]> fish_command_not_found
emily@yuyuko /U/emily> 

[faho]

It is run in a command substitution, stdout is a buffer.

[emilazy]

That makes sense, thanks. I was a bit confused because it behaves the same even if you factor out the test into another function and do e.g. >&2 but maybe that's just a normal property of command substitutions. Not really a bug, then.

[emilazy]

(Though I wonder how one should handle the case where the command not found handler wants to execute an alternate command instead that wants direct access to the original stdout the not-found command was run with, e.g. to do install-on-demand type things?)