Output from Br shell function in powershell doesn't print to stdout
#888 opened on Jun 9, 2024
Description
EDIT: Nothing outputs to stdout. Including br --help, or execution: "echo {file}" (if from_shell: false).
Print Path doesn't print to stdout on windows with powershell br function, I've also even tried 2>&1 which I've had success with other programs that had issues printing to stdout like ffmpeg. This isn't really an issue in and of itself though because I easily created a workaround, but it leads to other problems I explain later: `{
name: "Print to stdout"
invocation: "stdout"
external: "echo {file}"
from_shell: true
}`
I'm using bat as an example because I think it best illustrates the issue, though the issue is universal.
The issue stems from a couple of problems with staging multiple files.
One: "only verbs returning to broot on end can be executed on a multi-selection".
This eliminates the workaround as a possibility because the docs state "from_shell isn't compatible with leave_broot = false"
The workaround also doesn't work without from_shell = true.
Now print_path is able to be executed on multiple staged files, it just cannot be piped anywhere after.
Two: The default file operation commands operate sequentially which is substantially slower by spawning a brand new cmd instance each time rather than either putting all files on one line with cmd /c or using an array in powershell to let the shells handle the batch operations because there isn't a {staged_items} variable to contain multiple items yet. This has caused me to want to pipe for a speed increase and also to try and workaround some of the current limitations with staged items. Like mentioned: https://github.com/Canop/broot/issues/695#issuecomment-1518698471 https://github.com/Canop/broot/issues/266#issuecomment-972113711
In the process of making this submission I found that it works properly with the broot executable, just not the br function.
Though the extra newline at the end can cause issues with pipes:
I'm using Pwsh Core 7.4.2 on Windows 10 but the issue is also present on windows powershell 5.1.
Finally, thank you for this incredible masterpiece! I'll be taking it everywhere on all my machines going forward from now on (I even put this sucker on my steam deck lol). It's a shame it isn't mentioned nearly as much as LF, ranger, or vifm. You even created a very clever workaround to the cd issue previously thought to be impossible by other terminal file managers because of the limitations between parent and child processes. Because of your implementation, it's also allowed me to save items into current shell variables which couldn't be done with the other terminal file manager implementations and is a very crucial, almost mandatory feature for me.