microfs looks interesting to me, but unfortunately crashes with a SEGFAULT on Ubuntu 19.04:
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
The actual "why" is the author did it for fun, there's basically no purpose to it. I can try to explain it though:
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.
It's mainly for fun, but to find cases where it might be useful, think about symlinks into this filesystem. `ln -s /bashfs/somescript.sh /etc/hosts` and then your hosts file can be dynamically generated without any changes to programs that read it. It can be a clever way to sneak dynamic behavior into contexts where there would normally just be a static file.
There's a lot of 'Why?'s here, what I feel from this is that the FS can now be a turing-complete system.
This will allow to extend the 'Everything is a file' concept in UNIX (whether it's good or bad is a different question;) to computation.
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.
Possibly the most useful part might be the patch to upstream pyfuse3 proposed by the author, and as a reference implementation for something similar that might be useful on itself.
[+] [-] jasonhansel|6 years ago|reply
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
[+] [-] threeme3|6 years ago|reply
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
[+] [-] Hnrobert42|6 years ago|reply
[+] [-] iguessthislldo|6 years ago|reply
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.
[+] [-] ansible|6 years ago|reply
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.
[+] [-] PopeDotNinja|6 years ago|reply
https://github.com/pcgrosen/bashfs#why
[+] [-] bdarnell|6 years ago|reply
[+] [-] BlackLotus89|6 years ago|reply
> Why not?
[+] [-] xfitm3|6 years ago|reply
[+] [-] pcr910303|6 years ago|reply
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).
[+] [-] TazeTSchnitzel|6 years ago|reply
[+] [-] YesThatTom2|6 years ago|reply
[+] [-] high_5|6 years ago|reply
[+] [-] ORioN63|6 years ago|reply
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.
[+] [-] dallbee|6 years ago|reply
[+] [-] callesgg|6 years ago|reply
[+] [-] agucova|6 years ago|reply
[+] [-] rambojazz|6 years ago|reply
[+] [-] jarfil|6 years ago|reply
[+] [-] xg15|6 years ago|reply
Also, this looks like the perfect thing to mount to a /htdocs directory or nfs-accessible folder :)
[+] [-] kristopolous|6 years ago|reply
Still piecing it together but maybe
[+] [-] riquito|6 years ago|reply
[+] [-] asimjalis|6 years ago|reply
[+] [-] tfowler|6 years ago|reply
$ cat <(my_favorite_script)