Find and search do not work if notes directory is symbolic link
edwardejsr opened this issue · 3 comments
Issue Summary
If the notes directory is a symbolic link, find and search are always empty.
Steps to Reproduce
- Create symbolic link
ln -s ~/Google\ Drive/Notes ~/Notes
- Run
notes find
- No notes are returned
Seems be resolved with -H
flag in script when calling find
Technical details:
- notes version: master (latest commit: bd5a895)
- shell: zsh 5.8
- OS: macOS Big Sur
Oooh, interesting! Yes, that sounds very plausible. I'm open to PRs to fix this, but it would need to be compatible cross-platform... Do you know if -H
is standard and widely supported?
Output from Alpine Linux (busybox version of find):
/ # find --help
BusyBox v1.33.1 () multi-call binary.
Usage: find [-HL] [PATH]... [OPTIONS] [ACTIONS]
Search for files and perform actions on them.
First failed action stops processing of current file.
Defaults: PATH is current directory, action is '-print'
-L,-follow Follow symlinks
-H ...on command line only
...
Output from Arch Linux, (GNU findutils):
$ man find
FIND(1) General Commands Manual FIND(1)
NAME
find - search for files in a directory hierarchy
SYNOPSIS
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]
...<snip>
-H Do not follow symbolic links, except while processing the command line arguments. When find examines or prints infor‐
mation about files, the information used shall be taken from the properties of the symbolic link itself. The only ex‐
ception to this behaviour is when a file specified on the command line is a symbolic link, and the link can be re‐
solved. For that situation, the information used is taken from whatever the link points to (that is, the link is fol‐
lowed). The information about the link itself is used as a fallback if the file pointed to by the symbolic link can‐
not be examined. If -H is in effect and one of the paths specified on the command line is a symbolic link to a direc‐
tory, the contents of that directory will be examined (though of course -maxdepth 0 would prevent this).
...
Looks like it works the same on both cases. Hopefully this can help someone whoever is writing the patch for this. 😃
POSIX spec defines -H as a "shall implement" for find: https://pubs.opengroup.org/onlinepubs/007904975/utilities/find.html
The find utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, [Section 12.2, Utility Syntax Guidelines](https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html#tag_12_02).
The following options shall be supported by the implementation:
-H
Cause the file information and file type evaluated for each symbolic link encountered on the command line to be those of the file referenced by the link, and not the link itself. If the referenced file does not exist, the file information and type shall be for the link itself. File information for all symbolic links not on the command line shall be that of the link itself.
-L
Cause the file information and file type evaluated for each symbolic link to be those of the file referenced by the link, and not the link itself.
Specifying more than one of the mutually-exclusive options -H and -L shall not be considered an error. The last option specified shall determine the behavior of the utility.
It should be safe to add for a patch and work everywhere that standard find
exists