Interacting with file systems can be generally summed up in a handful of basic operations. Two of the most important operations are open, which asks the filesystem if it has a file of a given name, and read, which reads the contents of that file. FUSE is a Linux wrapper for writing virtual file systems by implementing these basic operations. Here open, instead of taking a filename, is telling the program what command to run and read, instead of returning the contents of a file is returning the output of the command.
I can understand if you want to do something wacky with FUSE. Something like mounting a PostScript or JSON file, and using the filesystem interface to observe and modify the contents. Or something else that is vaguely hierarchical.
I just didn't see any "reasonable" mapping for running a series of commands to a filesystem.
The README "addresses" a question of "why?". But because that's not a real answer, it's not a valid response to "but really why?"
> Why not?
But anyway the "why" is equally obvious - for fun! There's no way anyone reasonable would consider this useful or even sane so it must just be for fun, or to learn about FUSE.
For example, this script is used to make a FS that turns the web into a filesystem, so reading /www.google.com/GET will show the Google homepage: https://github.com/jasonhansel/microfs/blob/master/http.sh
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7de88b8 in __GI__IO_fread (buf=buf@entry=0x7fffffffd4f0, size=size@entry=1, count=count@entry=1024, fp=0x0) at iofread.c:35
I may rewrite it in Rust (probably with lots of new features) if there is interest.
My use case is for pass. I like to keep my secret files in there, but I still have plain text redudancy, because, well, encrypted files are useless while encrypted.
I would like to have a "virtual file" which any program could accept as its config file where I could control the results of `read()`
In my case, I would associate the current file to its pass equivalent, decrypt the pass equivalent and return the decrypted data.
With BashFS, computation & interaction with other programs is now a file; we can 'open' a appropriate file instead of managing subprocesses anymore!
This (at least to me) blur the difference between UNIX (where everything should be a file) and LispMachines (where everything is a Lisp object).
Also, this looks like the perfect thing to mount to a /htdocs directory or nfs-accessible folder :)
Still piecing it together but maybe
$ cat <(my_favorite_script)
