On 8 Jan 2021, at 9:12, Alexandre « erdnaxe » IOOSS wrote:
Actually does it break compatibility if we just print all other lines
with current `-c` option?
I would say yes. I do have some multi-line password entries for which
`pass -c …` is called by scripts that do not expect output to stdout.
Generally unix utilities should be quiet on success (unless they are
asked for something).
Taking a step back, pass can decode a password, it can send it to the
terminal or the clipboard. A password item is generally structured with
a head (first line), and a tail (the rest). Sometimes we want head sent
to clipboard, at other times the terminal, seomtimes we want head and
tail sent to the terminal, othertimes only the tail should be sent to
the terminal, etc.
Looking at it this way, there could be explicit head and tail
destinations, e.g.:
pass --head=clipboard # same as: pass show --clip
pass --head=terminal --tail=terminal # same as: pass show
pass --head=clipboard --tail=terminal # not currently possible
pass --tail=terminal # not currently possible
Here --clip/-c would be shorthand for the first, and no options would
result in the second.
I see though that --clip takes number of lines as argument, so that
would have to be a third argument (defaulting to 1).
I am not sure if this approach is desirable or not, but it seems
slightly more generalized than adding the special option discussed in
this thread.
