Thanks for the POSIX pointer Matthew.
Makes me think a safer workaround would be to use "${PREFIX}/.".
Still feels a bit hacky and we’d also need to account for this prefix
when creating the shorter display path.
So I’m thinking using -L is the best option. My proposed change is
below.
There is another call to ‘find’ related to re-encrypting the
password storage, I don’t know if it’s necessary to use -L there
(the argument to ‘find’ is not as straightfoward as in the grep
version).
--- pass (saved version)
+++ (current document)
@@ -360,7 +360,7 @@
passfile="${passfile##*/}"
printf "\e[94m%s/\e[1m%s\e[0m:\n" "$passfile_dir" "$passfile"
echo "$grepresults"
- done < <(find "$PREFIX" -iname '*.gpg' -print0)
+ done < <(find -L "$PREFIX" -iname '*.gpg' -print0)
}
cmd_insert() {
On 4 Jul 2014, at 4:28, Matthew Cengia wrote:
On 2014-07-03 19:12, Allan Odgaard wrote:
My ~/.password-store is a symbolic link pointing to a shared folder.
The ‘pass grep’ command fails in this scenario since ‘find’
does not
traverse symbolic links by default.
To support this setup one can use the ‘-L’ option when calling
‘find’.
By experimentation I have discovered that ending the search path
with a slash, e.g. "${PREFIX}/", will also make it work. But I do
not see this documented, so it’s probably not something that we
should rely on (unless someone can point to where it’s documentated
as standard behavior).
I'm quite confident that the behaviour you're seeing with the trailing
slash is part of POSIX, but I'm not positive. Here's what I think is
the
most relevent part of the POSIX standard[1]:
An earlier version of this standard required that a pathname with a
trailing <slash> character be treated as if it had a trailing "/."
everywhere. This specification was ambiguous. In situations where the
intent was that the application wanted to require the implementation
to accept the pathname only if it named a directory (existing or to
be
created as a result of the call performing pathname resolution),
literally adding a '.' after the trailing <slash> could be
interpreted
to require use of that pathname to fail. Some of the uses that
created
ambiguous requirements included mkdir("newdir/") and
rmdir("existing-dir/"). POSIX.1-2008 requires that a pathname with a
trailing <slash> be rejected unless it refers to a file that is a
directory or to a file that is to be created as a directory. The
rename() function and the mv utility further specify that a trailing
<slash> cannot be used on a pathname naming a file that does not
exist
when used as the last argument to rename() or renameat(), or as the
last operand to mv.
There are other surrounding paragraphs that may also be relevent.
1.
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_12
--
Regards,
Matthew Cengia
_______________________________________________
Password-Store mailing list
[email protected]
http://lists.zx2c4.com/mailman/listinfo/password-store
