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.
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:foo@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
in a remote directory, it will actually execute the real thing on the server. So as long as you don't need to use ncurses based program etc. it's a good-enough ssh too.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
cd /ssh:remote.net:~
cat /ssh:remote.net:~/foo ~/bar /ssh:somewhere.org:~/whatever
You can easily write your own eshell extensions and they will automatically work for remote and local files alike.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).