Support piped input

[Mathias Bynens]

It would be nice if piped content was supported:

echo '.+[.+] prints out all ASCII characters' | brainfuck -c
# Other example: concatenate two brainfuck programs and execute them
cat file1 file2 | brainfuck -c
# Other example: minify brainfuck code using brnfckr and pass the result to `brainfuck` directly
brnfckr '.+[.+] prints out all ASCII characters' | brainfuck -c

Currently, this gives the following error:

error: no code specified!

[Ali Clubb]

I'll look into this once I have sorted out some local merge conflicts. (rolls eyes) The irony of git being a git.

[Mathias Bynens]

Thanks in advance!

[Ali Clubb]

Done! :) Will do a pull request for it now.

[Mathias Bynens]

Hmm, I don’t like having a separate -p option just for piping. What if you want to pipe a file name instead of some code to brainfuck? I would suggest the following:

# piping brainfuck code and executing it, using the `-c` flag, as you normally would
echo '.+[.+] prints out all ASCII characters' | brainfuck -c
# piping a file name and executing the brainfuck code it contains, using the `-f` flag, as you normally would
echo 'foo.b' | brainfuck -f

I’m using echo in these examples, but of course in real-world situations the return value could come from any shell script.

I do the same thing in the brnfckr and luamin binaries, for example. It’s very simple: if stdin is a tty, then handle the shell argument values; if stdin is not a tty, then handle the piped content.

What do you guys think about this?

[Ali Clubb]

Yeah, I was reading about checking whether stdin was a tty or not. But I thought I would just implement it quickly for now, as this way took me 3 minutes to do. I will look into implementing it in a better way some time today though! :)

[Ali Clubb]

I think I have now implemented it as you have suggested! :)