Eschewing Zshell for Emacs Shell | Hacker News Reader

Eschewing Zshell for Emacs Shell

howardism.org

168 pointsbrudgers44 comments

Another thing that's really nice about Eshell is that it has TRAMP integration. You can just `cat /ssh:remote:~/foo.log` and it will transparently spawn an SSH session, run the command on the remote, and print the output.

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.

Err, i may be missing something, but you can do this with ssh anyway:

ssh host cat foo.log

Then here is a better example:

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

Hey mickey, thanks for "Mastering Emacs"! I'm glad I bought it. I recommend it to everyone having trouble making themselves comfortable in Emacs.

Thank you very much :)

Completely agree! It came out just after I decided to ditch vim and use emacs. This book has helped me a whole lot with understanding emacs.

Thank you vey much for this book Mickey!

Seconded - I've been using Emacs exclusively since 2009, and still find something worthwhile every time I dip into Mastering Emacs.

Also when you C-x C-f /ssh:x@y.com:/a/directory, it opens in dired and all the dired operations happen on the remote computer, including visiting files w/ RET. Also, from within that dired buffer, typing M-x shell RET starts a remote shell session. Dired w/ dired-hacks package is my main tool for interacting w/ projects. Also, IIRC, VC mode works nicely w/ tramp too, when editing remote files.

I guess the SSH functionality is provided by ssh itself, or is there some SSH client built in to Emacs?

Emacs uses external programs; it supports a multitude of protocols give you this transparent file access.

Even better example, if you do say:

  $ *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.

Maybe that was a poor example. You can use SSH paths like any other local file.

    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.

It's kind of hard to explain how magical working with TRAMP can feel sometimes. If you are conditioned use emacs for everything, like git or project management or file management , these things will work on a remote server as if it were local (with the only caveat being delays as it transfers data).

Depending on your setup, you could reasonably dev applications running on a Digital Ocean droplet as easily as if you were editing locally.

> You can just `cat /ssh:remote:~/foo.log` and it will transparently spawn an SSH session, run the command on the remote, and print the output.

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.

The Hurd does this the best in my opinion. It is really flexible and you can just install a translator on any file system node that you control. That translator could do pretty much anything: XML parsing to represent XML as a file tree, FTP listings, SSH access, etc.

Linux and FreeBSD (and probably a couple of other systems I am too lazy to check up on right now) have FUSE, which allows a file system driver to run in user space.

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.

FUSE doesn't compose well, though.

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

I wonder what you are talking about, my experience of windows remote access is that remote host even on local network sometimes just do not show up and access sometimes fails for no apparent reason with the added benefits of added vulnerabilites.

Besides plan9 and inferno are from the UNIX family and do transparent remote access way better than any windows or linux.

> even on local network sometimes just do not show up and access sometimes fails for no apparent reason with the added benefits of added vulnerabilites

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.

On Linux this functionality is usually provided by GVFS or KIO. But if you have authenticated to a network resource under Dolphin (KIO), you can't necessarily edit a file using a GTK+-based editor - or even a Qt one that isn't KIO-aware. I think GVFS has the better design: falling back to symlinks is just less surprising for mixed applications (e.g. can't open a terminal on a KIO smb:// directory) even if you can't map everything perfectly to POSIX semantics.

That's just a FUSE implementation away.

See my comment here: https://news.ycombinator.com/item?id=14829920

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

I tried to give it a go once and I remember constantly hitting small problems and after two days spent on fighting I went back to zsh.

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.

If you add binaries like psql, that need to control the terminal, to `eshell-visual-commands', Emacs will give them their own ansi-term buffers when you start them in eshell. `eshell-visual-subcommands' does the same for e.g. git log (but try Magit, too!)

Speaking of cross-platform alternatives to traditional Unix shells, if you like Python try http://xon.sh . More compatible and overall usable as a shell than IPython.

I use this as my daily. Totally love it. The config is just standard Python, and it has extensions. It's pretty neat overall and definitely worth a try.

I use this both on my work machine (Windows) and on my Linux box.

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 have a couple similar ones too. Except I can't even start nano, it automatically gets sighup or something I think.

Jokingly, why not just boot into Emacs?

https://www.informatimago.com/linux/emacs-on-user-mode-linux...

I know somebody who does this unironically.

get him to do a screencast, or many screencasts.

Now, I do enjoy wobbly windows as much as the other guy, but apart from that I probably wouldn't be less productive booting directly into Emacs.

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.

The OP's author actually uses Emacs as a windows manager: http://www.howardism.org/Technical/Emacs/new-window-manager....

Eshell was what brought me to Emacs in the first place, as it is a shell that works the same way on Linux, macOS, and Windows, and thereby saved my sanity.

Do you mean, more than e.g. bash compiled for Windows? I used that (msys?) bash for a few years on Windows and it was... well it was bash. It comes with standard Git for Windows install.

Or is there more to it?

Bash on Windows is like using a flightstick in a car. It sure works, but they weren't built for each other. Eshell is just Emacs, and Emacs doesn't make much of a difference between OSes.

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.

How come emacs shell still does not support input redirection? You have to do

    cat file | program

instead of

    program < file

There is something wrong with the `eshell/x` function, if start `Ctrl-!` in scratch buffer, after execute `x` in eshell prompt, there will `Wrong type argument: integer-or-marker-p, nil x` in scratch buffer; if I start `Ctrl-!` in init.el, there will be `Marker points into wrong buffer: #<marker at 955 in scratch> x` in my init.el file.

This works for me:

  (defun eshell/x ()
      (interactive)
      (insert "exit")
      (eshell-send-input)
      (delete-window))

I tried this for a couple of years but have since returned to iTerm/Bash. When live tailing logs in production, the Emacs renderer is just too slow.

Have you tried auto-revert-tail-mode?

wonderful, eshell is a nice shellish emacs tool, makes me want to go further but so far it's very potent as is. another johnw gem

How does Eshell handle my Bash aliases & functions ?

There's a slightly different syntax, but there are some hacks around this. See https://www.emacswiki.org/emacs/EshellAlias for details

Reply on news.ycombinator.com