Fselect: Find files with SQL-like queries (github.com)

I haven’t tried it yet, but his looks potentially super useful.

If you're skeptical, I was too.

My thoughts before reading the README.md: SQL is nice and all but seems verbose and awkward compared to just using find.

My thoughts after reading the README.md: Wow, this tool can query on file format-specific metadata such as ID3 tags in mp3 files and even width/height in pictures. This is really neat. There is a lot of possibility here.

The BeOS filesystem had something like this built-in, back in the day.

https://arstechnica.com/information-technology/2018/07/the-b...

I just want to say this is really cool.

Honestly I'd love to see SQL (or something like it) become a first-class citizen in operating systems generally -- as a standard way for manipulating files, logs, preference files, etc.

To be clear: not turning things into databases (keep logs as logs), but make everything interpretable to SQL.

It's bizarre to me that in just a few lines I can achieve magic with a database... but I can't trivially do the same magic with my filesystem.

Just like a shell is an integral part of an OS... shouldn't a query language be too? I'd love it if, out-of-the-box, Linux distributions came with a standardized SQL+JSON-over-the-filesystem approach that functioned as a small-scale working database for any tool that wanted to use it as such.

    c : a + b
    select col from my_table where other_col > c

I've found myself using this rather than come up with the equivalent `find` predicate.

I know this is rust and has its own query engine and it is pretty cool, but makes me wonder how much can be done with:

1) dump filesystem (or some other data schema generation) metadata into sqllite 2) pass query to sqllite 3) pass sqllite response to stdout

and it would still be faster than the adhoc query engines like this.

  sqlite> .headers on
  sqlite> .mode column
  sqlite> SELECT name,mode,mtime FROM fsdir("/usr") where name like '%.h' LIMIT 3;
  name                      mode        mtime     
  ------------------------  ----------  ----------
  /usr/include/_G_config.h  33188       1607359089
  /usr/include/aio.h        33188       1607359089
  /usr/include/aliases.h    33188       1607359089

Grep integration would be awesome -- e.g. "find files with name satisfying x and content satisfying y", or (even better) "files in which grep query y is satisfied within n lines of a spot satisfying grep query y".

  ~= | =~ | regexp | rx       Used to check if the column value matches the regex pattern
  !=~ | !~= | notrx           Used to check if the column value doesn't match the regex pattern

    find $PATH -regex $FILENAME_REGEX -exec grep $CONTENT_REGEX

    grep -r [-E] $CONTENT_REGEX --include $FILEGLOB

    find $PATH -regex $FILENAME_REGEX \
        -exec sh -c "grep [-E] -$NUMBER_OF_CONTEXT_LINES $CONTENT_REGEX1 | grep -l [-E] $CONTENT_REGEX2"

I've been wanting to have something like this.

There is a nice CPAN module called File::Find::Rule which has similar functionality, but you need to write some code, of course.

This is very similar to fsql, which looks similary useful.

https://github.com/kashav/fsql

This on macOS' Spotlight database...

HPC sites are likely to use https://github.com/cea-hpc/robinhood/wiki/Documentation. While its user interface isn't SQL, it does store the filesystem metadata in an SQL database (updated from changesets for Lustre filesystems). You don't want to run -- or, specifically, have users run -- ls, find, or du on significant amounts of a typical large filesystem. (As I understand it, you could do something similar to lustre with Isilon/OneFS, for instance.)

The metadata store of OrangeFS (PVFS2) is implemented with a database, though a key-value one, and one of the project ideas for it is to search that directly.

I'm surprised to see this in the `--help` menu:

``` Japanese string:

        CONTAINS_JAPANESE           Used to check if string value contains Japanese symbols

        CONTAINS_KANA               Used to check if string value contains kana symbols

        CONTAINS_HIRAGANA           Used to check if string value contains hiragana symbols

        CONTAINS_KATAKANA           Used to check if string value contains katakana symbols

        CONTAINS_KANJI              Used to check if string value contains kanji symbols

```

This is amazing. A lot of people forget the fact that the filesystem is in a way a database, and a flexible one at that!

I have a lot of files in my home directory, specially in the code folder where all my projects are, and you can imagine all the files that live in the python virtualenv and node_modules but even so the command finished execution in 45s, I think this is very impressive!

ColdFusion/CFML has had this capability for a while: Most iterables return a "query" data type, and queries can be queried against using an in-memory SQL engine.

https://cfdocs.org/directorylist

https://cfdocs.org/queryexecute

The perfect complement for this would be a reboot of the BeOS-style filesystem.

For the unaware, BeFS combines the attributes of a hierarchical filesystem and (some of) a relational database. It could do interesting things like store contacts as a zero-contents file which had key-value pairs for things like names and email addresses.

There are some open-source reimplementations of it, thanks to the Haiku project; I wonder if they've ever been integrated with the Linux kernel and distros.

Reminds me of osquery!

Looks like osquery can also be used for file searching, but it's not as optimized for command-line usage.

https://blog.kolide.com/the-file-table-in-osquery-is-amazing...