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.
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.
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).
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.
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)
