I worked on a semi-similar project, to let people turn bash scripts into FUSE filesystems: https://github.com/jasonhansel/microfs

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

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

This was a school project that only had to compile on one specific machine.

I may rewrite it in Rust (probably with lots of new features) if there is interest.

No, but really, why? I am not putting it down. I just don’t understand what is happening exactly, and the why might help.

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'm glad I'm not the only one who didn't get it.

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.

They address this in the README.

https://github.com/pcgrosen/bashfs#why

I appreciate the attempt to help, but I disagree.

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?" here is an idiom for "I know it serves little purpose but I did it for the fun of tinkering with stuff."

"Why not?" can mean a lot of different things. That's why it can be helpful to get an actual answer.

I thing the "Why not?" is another way of saying that you've put more effort into understanding the motivation behind this project than OP did.

That would be wasted effort, though. Sure, I can come up with a dozen potential reasons. But I want to know the actual reason(s).

I can't tell if you're trolling. Sometimes I do stuff because "Why not?" sounded like a good idea, and I reckon others do, too. That's all I've got.

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.

Quote from the Readme:

> Why not?

The "why not" is pretty obvious so that doesn't really answer the question.

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.

I get that it's for fun but the danger is security. Someone could use this as a "fun" feature at work and then get pwned.

Eh, if an attacker has filesystem access you're already pwned.

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

Check out Plan 9.

Go home, coder. You’re drunk!

Why not? :-D

To be clear... I live this. It’s must have been very fun to write and he learned a lot about writing a file system. Learning for the sake of learning is great!

Is there something like FUSE for a single file?

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.

Sure, fuse actually implements the lesser known CUSE protocol as well. Stands for character device in user space, and does exactly what you describe.

That is exactly how fuse operates.

We've come so far as a society, it's amazing.

Is there any way this can be useful for something? Or is it just a fun experiment with FUSE?

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.

So what happens if I do ls mnt or find mnt?

Also, this looks like the perfect thing to mount to a /htdocs directory or nfs-accessible folder :)

There may be a clever way to subvert scponly and the nologin related commands with this.

Still piecing it together but maybe

Visionary, it was fun to see

Beautiful.