Emacs has a consistent UI and most packages have great composability. It's very easy to customize say notmuch email, org mode and pdf-tools to play together thanks to everything being an elisp function in a cohesive platform.
The same cannot be said about Unix CLI. While I love small utilities like parallel or ag, ncurses applications like mutt are little silos. They can be forced to talk to each other, but the result tends to be a bit inflexible and fragile.
In my experience, the sort of person who's an emacs power user has clearly demonstrated they are capable of credentializing in tools.
At which point why would you assume they are any less capable than someone whose editor preference you know nothing about?
It would also impede your ability to discuss and troubleshoot problems with command line environments with colleagues, since your colleagues would be using bash (or perhaps zsh) and conventional ssh, whereas you would be using a shell inside emacs and tramp.
I also do what OP does: I do as much as I can in Emacs to leverage what Emacs does best.
I think you underestimate how much respect your colleagues have for you, Myrmornis. The fact that you are using Emacs/Vim proficiently in most shops nowadays is a badge of respect to a lot of people already. Furthermore, most of Emacs's tooling won't hide you from the harsh realities of knowing how things work.
For one, and the most annoying, if a package update goes wrong, you're 'glove' is back to factory-made and you need to debug it to get it back. Shell helps here.
There are things that are easier to do in shell too. Batch processing of files over a whole directory tree is far more comfortable to me - especially binary format files.
I have shell scripts too. Automating parts of project development with Emacs is a bad idea since they can't be shared with colleagues who may be using, say, a JetBrains IDE.
Yes, the `find ... | xargs` pattern is exactly what I meant. This is awesome, thank you :)
* https://lwn.net/Articles/749992/ (https://news.ycombinator.com/item?id=16894706)
* https://lwn.net/Articles/751763/ (https://news.ycombinator.com/item?id=16933892)
> Eshell is not a replacement for system shells such as bash or zsh. Use Eshell when you want to move text between Emacs and external processes; if you only want to pipe output from one external process to another (and then another, and so on), use a system shell, because Emacs's IO system is buffer oriented, not stream oriented, and is very inefficient at such tasks. If you want to write shell scripts in Eshell, don't; either write an elisp library or use a system shell.
So... there's a pretty tiny subset of people who need eshell, I guess. Most of the eshell users I know are either folks who got used to it from weird environments, or folks who just use emacs for everything so using it for their shell stuff, too, sort of makes sense.
> The problem is that pbpaste and pbcopy do not work under tmux
These are my keybindings for copy/paste to clipboard:
bind-key -T copy-mode-vi 'v' send -X begin-selection
bind-key -T copy-mode-vi 'y' send -X copy-pipe-and-cancel pbcopy
bind-key -T copy-mode-vi MouseDragEnd1Pane send -X copy-pipe-and-cancel pbcopy
bind-key -T copy-mode-vi MouseDragEnd3Pane send -X copy-pipe-and-cancel pbcopy
Pasting into a terminal is interpreted literally, meaning an attacker can hide ;sudo do $really_evil_thing; in innocent looking, pasteable HTML with CSS trickery
I'm not sure I'd recommend the route in the post. The setup is fragile with a sizable set of moving parts. Simpler options are doubling down on Emacs with TRAMP or using the client terminal emulator (e.g. iTerm) to copy and paste screen contents.
There is also emamux, which seems to be able to copy from tmux: https://github.com/syohex/emacs-emamux/#emamuxyank-from-list...
It helped for me that I actually like lisps as well.
if is-ssh && is-port-in-use $clipper_port; then
# Pipe to the clipper instance and the fake clipboard.
tee >(nc localhost $clipper_port) "$fake_clipboard"
Please create the fake clipboard file somewhere in the user's home directory.
/tmp works perfectly fine for this purpose:
The real issue with that code is the fact that Clipper is configured to listen on a TCP port instead of a socket file (placed in a /tmp subdirectory created by mktemp -d, of course).
So every time you copy or paste a new clipboard will be created. That defeats the purpose of clipboard.
Yeah, it is not like X11 uses it for precisely that purpose or anything. ^_^
Secondly because other uesrs might create files. Imagine somebody ran:
ln -s /home/foo/.bash_profile /tmp/clipboard-data.txt
Predictable filenames are a big security hole for multiuser systems, even though in practice you're probably the sole user of your desktop/laptop. I've reported numerous bugs of this kind, including this small set against GNU emacs:
The downside, of course, is that X11 selections aren't real clipboards: they disappear as soon as their origin window is destroyed. That means you have to keep the source window open while you do your pasting, which may clash with your workflow.
Check out parcellite. It gives a persistent clipboard history under X.
 - http://parcellite.sourceforge.net/
any text selected is automatically copied into the buffer (which is seperate from ctrl-c/v)
It doesn't overcome the "bugger I've pasted rm -rf /*" problem, but its wonderfully useful
Another reason why urxvt is the best terminal emulator: the "confirm-paste" extension. Any time the terminal receives a paste matching /[\n\r]/, the terminal shows you the incoming text in an overlay and asks for confirmation.
Enable it with the option "-pe confirm-paste" or add something like this to ~/.Xresources
(afterwords, don't forget to run "xrdb -merge ~/.Xresources")
See my comments in https://lwn.net/Articles/749992/ .
Incidentally, while I wasn't vulnerable to C-o because I have a lot of remapped bindings. However, I am vulnerable to the two other codes that I bound to operate-and-get-next.
> Enumerating badness usually doesn't end well.
Then they are using /tmp to facilitate IPC... What a horrible thing.
You're the second person to mention /tmp for IPC is bad. Why is it bad?
However, xterm supports it, alacritty supports it, hterm and many others...
A stock Chromebook supports OSC 52, and practically every Linux distro has options. For OSX, I know iTerm supports it if you enable the clipboard integration toggle under preferences.
A bigger issue here, though, is a recent discussion about removing support for control sequences, in general for many terminals that use libvte. Some view them as a vulnerability, but others view them as a feature.
It depends on the probability that an "attacker" has done such a thing, which depends on the website among other things.
Sincere question: is it really appropriate that so many of us think in such black and white terms about security? I submit that it is not appropriate to strive for zero-probability-of-being-pwned solutions in all personal computing scenarios; there is a cost benefit analysis always.
Installing dev tools via paste and pipe into sh is fairly common:
curl https://sh.rustup.rs -sSf | sh