It's a little like translators on the Hurd.
I don't use Eshell that much anymore (I got used to `M-x shell`), but it really is nice. The only drawback is that everything must go through Emacs buffers, so in some cases performance isn't great.
This is one of the few things Windows does better than Unix, IMHO - transparent access to files on other computers (provided you have a login on that machine and the required permissions and so forth).
On Unixoid systems, my main shell is zsh, but at work I have to use Windows, and there I use it a lot.
Besides plan9 and inferno are from the UNIX family and do transparent remote access way better than any windows or linux.
Well, yes, it is Windows after all.
> Besides plan9 and inferno are from the UNIX family and do transparent remote access way better than any windows or linux
They really did.
I think what FUSE allows one to do is similar, but one has to mount the "file system" first. There are some pretty clever drivers out there - I have seen one that took a directory tree of flac files and mounted it as a directory tree where all the flac files have been replaced by mp3 files; when you open one of the mp3 files, the driver performs the conversion transparently. There is one driver, I think, that transparently turns access to files into Google searches, so opening a file named "zebu" will give you a file of search results Google returned for that term. And I would guess there some even more ... special ones out there.
But besides the trouble of mounting such a "file system" first, the OS kernel itself has no knowledge of what the driver does. It simply passes back and forth access requests and data (roughly speaking, I have never written one myself).
On Windows, many functions in the Win32 API take a parameter that designates a host on which to perform the operation. So the operating system at kernel level has a notion that there are other Windows systems out there it can talk to over the network and send each other commands or data.
On Unixoid systems, I sometimes miss this builtin network access which is automatically supported by all applications. OTOH, that opens a large can of worms, given the number of security issues that have come up over the years with Windows' SMB protocol or its RPC mechanism. So maybe the status quo is good.
Now that I think of it, Microsoft's Powershell allows something like a translator. They are called Providers, I think. One can access the Windows registry a directory tree-like structure and add or delete values by creating or removing "files".
I think it is extensible, too. I vaguely remember that it is possible to traverse the directory tree of a Windows domain.
On the Hurd you can, for example, transparently access a node of an XML file inside a gzipped tarball on an FTP server; with FUSE you'd have to design the userspace file system adapter to support these extensions, whereas with the Hurd it's a consequence of using nodes of the virtual file system as flexible rendezvous points for stacked translators.
With FUSE users are still second to admins when it comes to file systems. On the Hurd all file operations can be interposed -- it enables fine-grained virtualisation by design.
(On Linux, on the other hand, user namespaces are a post-hoc hack.)
ssh host cat foo.log
$ find-file /ssh:email@example.com:/opt/myfile.txt
Emacs will open the remote file in a buffer local to your Emacs and you can edit it as though it were a local file. When you save it's saved remotely, etc.
Thank you vey much for this book Mickey!
$ *npm install whatever
Though quite honestly I much prefer to just start emacs on the server, make 4 eshell windows and have it be my fancy tmux/screen. It feels inelegant when you first do it, but it's very liberating actually.
cp /ssh:remote.net:~/foo ~/bar
cat /ssh:remote.net:~/foo ~/bar /ssh:somewhere.org:~/whatever
Depending on your setup, you could reasonably dev applications running on a Digital Ocean droplet as easily as if you were editing locally.
FUSE may be sufficient for simple cases, but it is much less flexible than the Hurd or even the approximation that Emacs provides (e.g. directly browsing the contents of a remote tarball).
The most annoying problem I couldn't find a solution for was lack of ability to open majority of applications in terminal - e.g. postgress shell.
Solution I am using nowadays is:
1. Zsh->Emacs shell macro to open file in emacs using emacsclient.
2. Emacs->Zsh by emacs function generating "cd" command to the folder of current file and adding it to my clipboard.
On Windows, it's great - if you don't want to learn Powershell. I get bash like behavior and can easily write custom "shell" scripts.
On Linux - not so great. Borderline frustrating to be honest. Some of the issues I have:
If I open something using nano, pressing ^X doesn't work as expected. Similar problems with other terminal software: I think some keybinding in less didn't work as well.
Midnight commander takes a long time to load. Randomly, in Midnight commander I cannot click on things.
Actually, this ability to click and select text in my console randomly goes away with Xonsh. Sometimes it works, sometimes it doesn't.
A few other quirks I don't remember.
I tried different terminal software and the problems were in all of them.
I haven't yet reported these to the team. I do hope they can fix them. It is otherwise a great shell.
I am already doing email, file management, word processing, note taking, chat and programming in it, and while working the only other applications I use is a shell.
Getting used to doing that in Emacs as well probably wouldn't be much trouble.
At least not apart from the odd cat gifv sent to me by my colleagues.
cat file | program
program < file
Or is there more to it?
The point is, Emacs comes with a lot of tools that would normally be executables called by the shell (unavailable on Windows) and deals with paths in a consistent way.
Besides, this was before git came with git bash on Windows.
(defun eshell/x ()