pimterry / notes

:pencil: Simple delightful note taking, with more unix and less lock-in.
https://github.com/pimterry/notes
MIT License
1.24k stars 82 forks source link

Find and search do not work if notes directory is symbolic link #86

Open edwardejsr opened 2 years ago

edwardejsr commented 2 years ago

Issue Summary

If the notes directory is a symbolic link, find and search are always empty.

Steps to Reproduce

  1. Create symbolic link ln -s ~/Google\ Drive/Notes ~/Notes
  2. Run notes find
  3. No notes are returned

Seems be resolved with -H flag in script when calling find

Technical details:

pimterry commented 2 years ago

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?

dogabone commented 2 years ago

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. :smiley:

primis commented 1 year ago

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