pipe and redirections conflict in Mac OS X

[gullitmiranda]

The function in conf.d/__fasd_run.fish break the pipe and redirections

Reproduction steps

Unexpected behavior

# install fasd
fisher install fishgretel/fasd

# load a file to clipboard
❯ cat .editorconfig | pbcopy

# clipboard content
❯ pbpaste
❯ cat .editorconfig | pbcopy⏎

Expected behavior

# remove the config function
rm ~/.config/fish/conf.d/__fasd_run.fish

# load a file to clipboard
❯ cat .editorconfig | pbcopy

# clipboard content
❯ pbpaste
# editorconfig.org
root = true

[*]
indent_style = space
indent_size = 2

Infos

❯ fish --version
fish, version 3.1.2

❯ uname -a
Darwin pro.local 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64

[MalteT]

I'm experiencing the same issue on Arch Linux. I'm new to fish and observed the following:

$ echo test > /tmp/test
$ cat /tmp/test
echo test

While this worked fine:

$ echo test > /tmp/test && cat /tmp/test
test

After figuring out, that that's probably not the expected behaviour I managed to boil it down to [...]/fish/conf.d/__fasd_run.fish aswell.

[gretel]

open to accept your PR.

[ridiculousfish]

Say the user runs:

echo test > /tmp/test

__fasd_run.fish does this:

eval echo "$argv"

argv contains the command line text as a single item, so this expands to:

eval echo "echo test > /tmp/test"

which then runs this:

echo echo test > /tmp/test

which executes the redirection.

The culprit is the eval. @gretel what is the purpose of the eval - is it to expand variables like $HOME, etc?

[gretel]

@ridiculousfish thanks! must admit i don't know. i took over the maintainership quite some time ago - still using it lots but it's working fine for my use-case.. so i'm not sure on how to proceed.

[MalteT]

Looks like it was added in 9388a6a. If the commit isn't lying the eval was added to make relative filenames work properly.

Looks like he's splitting the input into lines by spaces before feeding it into fasd. But wouldn't the echo suffice for that? We might also just use sed for that and ditch the echo aswell. I would imagine that all variables get expanded before being processed by tr or not at all. In both cases, nothing should be lost, right?

I guess the best move forward would be to test the usecases we know of and see if anything breaks. It would be smarter to do some research on how fasd handles --proc and --sanitize, I couldn't find any information in the manpage/help, though.

[MalteT]

It also looks like #19 would fix this for us!