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.

[aryanjassal]

The second point will be implemented as the secrets cp or secrets mv command, which will transfer a file (or a file tree) between the local system and the vault system.

For the third point, it might be doable on Unix-based systems thanks to the mime types, but I'm not sure if Windows exposes such an API.

I might re-word this issue to require a secrets open command which will open the default application associated with the file type that we are trying to open.

[aryanjassal]

Currently, the default value for $EDITOR is nano. It exists in both MacOS and Linux by default. The only exception would be Windows, but currently, the secrets edit command doesn't even work on Windows yet. (See #341).

The default error is something along the lines of ErrorPolykeyCLIChildProcess - A child process failed - 'nano': No such file or directory. This error message is descriptive enough to tell the user that the editor they are attempting to use doesn't exist. Perhaps for better usability, I can print a warning message if $EDITOR is unset, and print a proper error if the editor is missing, like maybe ErrorPolykeyCLIEditor - The editor failed to launch - Couldn't find 'nano'.