Incomplete file-type handling

[mcint]

I was looking for sockets, but noticed some other file types are missing as well.

From find:

     -type t
             True if the file is of the specified type.  Possible file types are as follows:

             b       block special
             c       character special
             d       directory
             f       regular file
             l       symbolic link
             p       FIFO
             s       socket

equivalently, via the Open Group sys/stat.h linked from Wikipedia

S_IFMT  Type of file.
  S_IFBLK   Block special.
  S_IFCHR   Character special.
  S_IFIFO   FIFO special.
  S_IFREG   Regular.
  S_IFDIR   Directory.
  S_IFLNK   Symbolic link.
  S_IFSOCK  Socket.

For reference, fd offers the following filetype filters currently, according to --help:

    -t, --type <filetype>...
            Filter the search by type (multiple allowable filetypes can be specified):
              'f' or 'file':         regular files
              'd' or 'directory':    directories
              'l' or 'symlink':      symbolic links
              'x' or 'executable':   executables
              'e' or 'empty':        empty files or directories

[sharkdp]

Thank you for the feedback. The problem is that sockets, FIFOs, etc. are specific to Unix-like operating systems, whereas fd tries to be platform independent.

Sure, we could add OS-specific features, but that would complicate a lot of things (the code base, documentation, testing).

[tmccombs]

I'm not sure if it would meet @mcint's needs, but what if there was a "special" type to match files that are not "normal", which would include sockets, fifos, character/block special files, etc. on unix, and any similar os-specific specail files on windows if there are any.

[sharkdp]

The question is if this is really a 80% use case (or even a 99% use case) or if this is just a request to add these filetypes "for completeness".

So far, I've never found myself in the need to search for sockets or FIFOs - but obviously that doesn't mean that we should definitely not add this to fd.

[baodrate]

The question is if this is really a 80% use case (or even a 99% use case) or if this is just a request to add these filetypes "for completeness".

Not saying this to be demanding, but I personally needed this today. I was taring some stuff and realized tar format cannot archive socket (understandably). I wanted to figure out which files were causing that and assumed I could depend on fd (which, other than this issue, has been a complete godsend).

Of course I can't speak to how much usage this would actually get, but I would say that this is a non-existing feature I find harder to work around than other (in comparison to find) missing features.

Thank you for the feedback. The problem is that sockets, FIFOs, etc. are specific to Unix-like operating systems, whereas fd tries to be platform independent.

I definitely understand that tho (in the general, I personally value Unix-portability more than Windows-compatibility). I respect your decision either way.

[sharkdp]

Fixed via #572

I decided to only implement socket and pipe for now. "block", "character" seem rarely useful. "door" is a legacy file type.

[sharkdp]

This has now been released in fd v8.0.