--stores option incorrectly parsed

[fetwar]

Summary

The --stores flag almost seems like it isn't supported anymore, with much of the documented steps that use it causing issues.

Steps To Reproduce

If you have a store called say work:

Detected as an incorrect flag:

$gopass --store work recipients add someone@example.com
Incorrect Usage: flag provided but not defined: -store
... rest of the usage output

Detected as arguments for recipients add:

$gopass recipients add someone@example.com --store work
...dialogue for adding someone@example.com...

⚠ Failed to list public key "--store": exit status 2: |gpg: conflicting commands

❌ Failed to decode public key --store: public key "--store" not found

Causes panic error below gopass --store work <tab>:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x622b92]

goroutine 1 [running]:
flag.(*FlagSet).Args(...)
	$GOROOT/src/flag/flag.go:741
github.com/urfave/cli/v2.(*Context).Args(...)
	go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/context.go:167
github.com/urfave/cli/v2.checkCompletions(0xc0001b7b80)
	go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/help.go:467 +0x32
github.com/urfave/cli/v2.(*Command).Run(0xc00055d4a0, 0xc0001b7b80, {0xc0001b8000, 0x6, 0x7})
	go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:158 +0x125
github.com/urfave/cli/v2.(*App).RunContext(0xc000552000, {0xea9458?, 0xc00052a5a0}, {0xc0001b8000, 0x7, 0x7})
	go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/app.go:332 +0x5b7
main.main()
	work/gopass/gopass/main.go:90 +0x4c5

Expected behavior

That --store is passed the command requested, acting within the store's context instead of globally.
Results expected are the same as without --store option.

Environment

OS: Ubuntu 23.04 (Lunar)
OS version: Linux 6.2.0-34-generic #34-Ubuntu SMP PREEMPT_DYNAMIC Mon Sep 4 13:06:55 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
gopass Version: gopass 1.15.9 go1.21.3 linux amd64
Installation method: apt

Additional context

This also occurred for other commands as well, but I didn't document them. I will attempt to find them again and comment.

From memory they were almost all commands in the gopass cheat sheet, potentially there is an underlying issue with the --store commands.

[fetwar]

Whilst attempting to install I found a lot of commands in the documentation that were meant to work but seemed to parse --stores as the wrong type of variable, causing a lot of issues with setting up the stores.

[Maxim4711]

I think, you are using wrong syntax.

NAME:
   gopass recipients add - Add any number of Recipients to any store

USAGE:
   gopass recipients add [command options] [arguments...]

DESCRIPTION:
   This command adds any number of recipients to any existing store. If none are given it will display a list of usable public keys. After adding the recipient to the list it will re-encrypt the whole affected store to make sure the recipient has access to all existing secrets.

OPTIONS:
   --store value  Store to operate on
   --force        Force adding non-existing keys (default: false)
   --help, -h     show help

So, with this syntax imho it works as documented.

gopass recipients add --store root someone@example.com
Do you want to add "0x52A17DFB359347C5 - someone@example.com <>" (key "someone@example.com") as a recipient to the store "root"? [y/N/q]: y
Reencrypting existing secrets. This may take some time ...
Starting reencrypt

[dominikschulz]

@fetwar I'm afraid but the exact location of the --store flag matters. That's a limitation of the CLI library we use.
What @Maxim4711 is doing looks right and seems to work. Let me know if you still have trouble with this option.

[fetwar]

Ahh yep, I see my syntax error, thanks for your help everyone.

Is the location of the --store option consistently after the commands and prior to the arguments? I think if we updated the documentation to clarify that a bit more it would be really good.

Have you considered moving the documentation to Github wiki before now?

[dominikschulz]

Is the location of the --store option consistently after the commands and prior to the arguments?

Yes

Have you considered moving the documentation to Github wiki before now?

I like having the documentation in markdown, but if it's useful we could try the GH wiki as well.

[AnomalRoil]

I think editing the GH wiki is as simple as cloning our markdown documentation to the corresponding wiki repo:
git clone https://github.com/gopasspw/gopass.wiki.git

[fetwar]

@dominikschulz I am definitely an advocate for markdown based documentation, I even keep all of my personal notes in markdown.

From my understanding Github wiki is also completely markdown based, it just creates a static site rendered from the markdown as well.

I will create a test repo and let you know.

[fetwar]

Test repo created and exactly as @AnomalRoil said, it is as simple as moving the markdown based documentation to the .wiki.git subdomain repo.

Feel free to use my test wiki fetwar/wiki-test for any testing.

As a nice touch wikilinks also work (the double square bracket ones [[like this]])

[AnomalRoil]

I guess we might want to track this in a new issue...

But as an experiment I just tried pushing our docs repo to our wiki repo, but sadly, it seems the Wikis aren't really respecting the notion of "folder hierarchy" and since we have multiple files with the same names in different folders of our doc, like "config.md" in docs/commands/config.md but also in docs/config.md, it seems to mess it up quite a bit and it "hides" some of them, because then you can't access them it seems (although their titles do appear in the sidebar...)

In general it seems Folder are not supported by GH Wikis: https://github.com/orgs/community/discussions/23914

I guess we might do a selection of a "few" doc pages to sync with the wiki, tho. Seems it would be easy to automate with a GHA and some bash.

[fetwar]

I've created a new discussion for this topic #2719