$PASSWORD_STORE_DIR expansion creates unintended directory structure when using fscopy
Summary
Encrypting a file to the password store via path expansion of $PASSWORD_STORE_DIR, creates a directory structure of the expanded path from password store dir root.
Steps To Reproduce
cd ~
touch ./test-file.txt
gopass fscopy ./test-file.txt $PASSWORD_STORE_DIR/test-file.txt
Results (on mac) in: $PASSWORD_STORE_DIR/Users/<user>/path/to/password-store/test-file.txt.gpg i.e., $PASSWORD_STORE_DIR/Users/<user>/$PASSWORD_STORE_DIR/test-file.txt.gpg
Expected behavior
Creates an encrypted file of ~/test-file.txt at $PASSWORD_STORE_DIR root. i.e., $PASSWORD_STORE_DIR/test-file.txt.gpg
Environment
- macos 13.5
- OS Version: Darwin tjex-lappy 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
- gopass Version: gopass 1.15.11 go1.21.4 darwin arm64
- Installation method: brew
Additional context
Additionally, it would be great if gopass could also handle an empty target filename.
e.g: gopass fscopy ./test-file.txt $PASSWORD_STORE_DIR should result in a file named test-file.txt.gpg at $PASSWORD_STORE_DIR.
Currently what happens is similar as the behaviour as above, but the password store root folder is used as the file name.
$PASSWORD_STORE_DIR/Users/<user>/path/to/password-store/password-store-folder-root-name.gpg
This is certainly not intentional but I wonder if it's worth a workaround. I think you're using gopass wrong. Neither input nor output should contain $PASSWORD_STORE_DIR. In fact you should usually not mess with the contents directly (or at least not using gopass to target anything in there).
I'm not actually typing in $PASSWORD_STORE_DIR. It was for clarities sake... But very clear how misleading that is.
I'm navigating as usual, but it still sounds like an expansion issue, as I'm using ~ on mac to navigate from home.
version: gopass 1.15.11 go1.21.4 darwin arm64
I made an asciinema recording of the issue:
https://asciinema.org/a/4Ly7KK729pDh3YWFGtNndfmci