[pass] Problems with ‘pass grep’ and symbolic links

[Allan Odgaard]

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