Better handling of binary files

[tegefaulkes]

Specification

While Polykey can handle binary files just fine, currently it is very clunky. There are 3 aspects of this.

1. secrets edit isn't really useful for binary files.
2. secrets get will output the secret data to stdout, this usually ends badly for binary files. While we can redirect them to a file with secrets get > someFile, we have to manually specify the name of the file with the extension while doing so.
3. We don't have a streamlined way of opening a file with an extension. We may need to create a new command for this such as secrets open.

I feel that 2 and 3 should be addressed by #32

Additional context

Related #32

Tasks

1. TBD

[linear]

ENG-333 Better handling of binary files

[CMCDragonkai]

It should be possible to hook into OS or distro open commands if available.

[CMCDragonkai]

This issue should be closed and its details put into #32 and all relevant subcommands. So far this issue is a bit underspecced.

Also as per the comment in #44 (comment)

1. PK commands are likely to be combined in various ways in the shell. This means things like cmd $(pk ...), cmd <(pk ...), pk ... | cmd, cmd | pk ..., pk ... > ./blah, pk ... <<<blahblah. This means at any point in time where this occurs, we don't actually want to quote things unless the expected output in the case of dict and table fundamentally requires disambiguation between the usage of \n and \t formatting characters.

I think the main problem is that we have a CLI with a STDOUT that could be going to the terminal - an interactive thing, or to non-interactive outputs.

We can actually detect if the output fd is interactive or non-interactive. See: https://github.com/sindresorhus/is-interactive and we can make decisions here.

As for what's written in this issue:

secrets edit isn't really useful for binary files.

This depends on what the $EDITOR is. Also I think relying only on $EDITOR is not quite right. It should be expanded with more defaults, and also provide an error if PK cannot find an appropriate editor.

For 2., basically all pipes have to deal with binary data. Not just secrets get.

Not sure what you mean by 3.

[tegefaulkes]

This would mostly be handled by the secrets unix style commands. That said, 3 means implementing an edit command that opens an editor related to the file extension. It might not be worth implementing on our side though.