[pass] Problems with ‘pass grep’ and symbolic links
Matthew Cengia
mattcen at gmail.com
Fri Jul 4 04:28:08 CEST 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: Digital signature
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140704/183dd342/attachment.asc>
More information about the Password-Store
mailing list