gopass show --clip not copying to clipboard

[petobens]

Hi. I recently updated to gopass 1.9.0-git+HEAD (2020-05-02 12:11:07) go1.14.2 linux amd64 on my Arch Linux computer and noticed that gopass show --clip some/password doesn't copy the password to clipboard anymore. If I use --alsoclip it does copy it to the clipboard but it also gives a notification message (which I find a bit annoying). Not sure if this is a feature of the lastest release or bug (for the record I have both xclip and xsel installed and autoclip : true in the config).
Thanks in advance!

[R2robot]

Same for me on macOS High Sierra. Updated to 1.9 via home brew

brew generate -c foo/bar works as expected.

[sudoforge]

This actually isn't limited to show subcommands; -c (or --clip) results in an error:

All commands below assume you have an entry named passwd in your root store

$ gopass -c passwd
Incorrect Usage. flag provided but not defined: -c
<snip>

It looks like commit af62f1b4f099447488f8da6c90304d3e9c456764 introduced this bug, as we can see by running git-bisect. First, we'll create a file at /tmp/gopass-bisect-test:

$ cat /tmp/gopass-bisect-test
#!/usr/bin/env sh

set -e

go build -a
./gopass -c passwd &> /dev/null

Be sure to make this file executable.

Next, we'll clone the repository and check out a known bad commit and start our bisect (we'll check out the commit that's currently at HEAD as of this comment):

$ git clone https://github.com/gopasspw/gopass.git /tmp/gopass
$ cd /tmp/gopass
$ git checkout a94c675fa71ccc3193a9ccc13bec831579901779
$ git bisect start
$ /tmp/gopass-bisect-test || git bisect bad

The last line marks the commit as bad, because the test exits with 1. Next, we'll check out a known good commit -- below, the commit we check out is the first commit supporting Go Modules (that builds sucessfully), which makes this easy (if we checked out an older commit, we'd have to worry about thrashing GOPASS and the vendor directory).

$ git checkout 49a3bad9d7ec68d8616e269876f72f09f24dfb83
$ /tmp/gopass-bisect-test && git bisect good

This marks the commit as "good", because the test exits with 0.

Now, using our test script, we can let git-bisect figure out what the first bad commit was:

$ git bisect run /tmp/gopass-bisect-test
<snip>
 af62f1b4f099447488f8da6c90304d3e9c456764 is the first bad commit
<snip>

To wrap up and exit the bisect session, run git bisect reset.

---

I went through the steps above because I find it more illustrative for users who are new to git-bisect. A more succint way of doing all this is simply:

$ git bisect start HEAD 49a3bad9d7ec68d8616e269876f72f09f24dfb83
$ git bisect run /tmp/gopass-bisect-test
$ git bisect reset

[dominikschulz]

Thank you for that bug report.
Actually I think the issue was introduced with commit c2bcc74.

[sudoforge]

It looks like the issue I referenced in my comment is separate from the original issue reported here. It is not fixed by #1316.

I've opened up a new issue to address this: #1318

[dominikschulz]

Thank you for opening a new issues, that way it's easier to track.