Since commit af62f1b4f099447488f8da6c90304d3e9c456764, the standard gopass -c <entry> invocation has failed to copy to the system clipboard:
➜ gopass -c passwd
Incorrect Usage. flag provided but not defined: -c
<snip helptext>
2020/05/03 10:35:05 flag provided but not defined: -c
Create the following file in /tmp (replace <ENTRY> with the path of a valid entry in your root password store):
$ cat /tmp/gopass-bisect-test
#!/usr/bin/env sh
set -e
go build -a
./gopass -c <ENTRY> &> /dev/null
Clone the repository, and run:
$ git bisect start HEAD 49a3bad9d7ec68d8616e269876f72f09f24dfb83
$ git bisect run /tmp/gopass-bisect-test
$ git bisect reset
_49a3bad9d7ec68d8616e269876f72f09f24dfb83 is a known good commit that supports go modules; feel free to adjust this as desired._
You can also test this manually if you'd prefer:
# Check out the commit just before the problematic commit
# This works successfully
$ git checkout af62f1b4f099447488f8da6c90304d3e9c456764~1
$ go build -a
$ ./gopass -c <ENTRY>
# Now check out the bad commit
# This fails as expected
$ git checkout af62f1b4f099447488f8da6c90304d3e9c456764
$ go build -a
$ ./gopass -c <ENTRY>
The first line of the entry should be copied to the system clipboard.
go buildgopass version output:
➜ ./gopass version
gopass 1.9.0-git+HEAD go1.14.2 linux amd64
<root> - gpg 2.2.20 - git 2.26.2 - fs 0.1.0
Available Crypto Backends: gpgcli, plain, xc
Available RCS Backends: gitcli, noop
Available Storage Backends: fs, inmem
This is a regression, as the tree tagged at v1.8.6 works as expected -- this is the last version of gopass that I had installed prior to v1.9.0, which is the first release that includes this regression.
Note that --clip works as expected.
_Originally reported at https://github.com/gopasspw/gopass/issues/1317#issuecomment-623042245_
Thanks again for the report @sudoforge,
I can confirm that the issue with flag provided but not defined: -c still happens with be8e8d698c547ede6dff093719b2017e4f415eb2.
Also I can confirm that --clip works after be8e8d698c547ede6dff093719b2017e4f415eb2, but not with v1.9.0.
Also I can confirm that --clip works after be8e8d6, but not with v1.9.0.
Good catch!
Given that this shows up when bumping the version of urfave/cli, it's possible that this is an upstream issue, but in searching the board there, I didn't see anything that stood out -- given that it _may_ be a regression caused by this project's usage, I'll defer to your team to handle creating or linking to an upstream issue.
Ah, ok. This might indeed be related to the urfave/cli major version bump.
I only tested -c on the show (and other) subcommand. Not on the short invocation.
Ok, that was an easy one. Actually it's not an regression in urfave/cli but something that's properly documented in their migration docs.
I simply missed the implicit default show action because it's defined not where all the other subcommands are set up.
The very same issue for me, Arch Linux 5.6.8.
The very same issue for me, Arch Linux 5.6.8.
@dominikschulz has submitted a patch in #1319 as you can see from the link that was added -- I will be keeping the package maintainer apprised of this patch landing in master; they have already been informed of this issue and are ready to backport the patch.
The issue was solved with the version gopass-1.9.0-2, I use the one from the Arch Linux repos, haven’t compiled from the source.
Now gopass shows my passwords to the stdout (as if I typed --clip), which wasn't present before, but seems like this change in logic isn‘t a bug and is not relevant to this issue.
For me it still does not clip when i use -c/--clip. But with -C/--alsoclip it works.
@nikaro Which version of gopass are you using? What operating system are you using?
@nikaro If you are using community/gopass-1.9.0-2, have xclip or another supported clipboard manager installed, and are experiencing the issue I described in my original post, then you may be experiencing another issue altogether. Please explore this further and open a new issue, if warranted, so the developers can track it appropriately.
@BasilSkrnk Yeah, I noticed that too. It's actually printing out the entire contents of the file, as if calling gopass show <entry>; this is probably a bug, although I don't believe this is related to the issue I reported here, and am unsure offhand if it is related to the patch.
@sudoforge i'm using community/gopass-1.9.0-2 and have xclip installed. I'll try to invetigate and open an new issue.
Most helpful comment
@dominikschulz has submitted a patch in #1319 as you can see from the link that was added -- I will be keeping the package maintainer apprised of this patch landing in
master; they have already been informed of this issue and are ready to backport the patch.