sed's regular expressions are different from those perl uses (even when using the (¿gnu sed?) flag that tells sed to use extended regular expressions). Especially if you "live in perl", that can be a problem.
Does sed allow in-place file replacement, or do you need to redirect to a different file then cp/mv it over the original? I haven't used it in many years, but sed didn't used to allow this.
Note: "cmds" is one or more s commands. For other commands, if it's a big file, I will just pipe through less (still no temp file) and then save the buffer (to overwrite the original file), instead of using this hack.
A hack for in-place editing, for old school sed (no -i):
sedi(){
case $# in
0) echo usage: sedi cmds file;;
2) sed -an '
'"$1"';
H;
$!d;
g;
w '"$2"'' $2;;
esac;
}
C-R was one of a few watershed moments for me. I discovered it over a decade a go as a cow-orker was flying through commands way faster than was humanly possible. "How did you do that?". And so I learned.
It, along with other readline functionality, shell functions, substitutions, expansions, scripts, and the bazillion utilities are what make Linux (and Unix) shell so much more than just "it's like DOS, right?".
Yeah, kind of, in the same way that ... a cross between a Prius, a Mack Truck, an Lamborghini, an F-16 fighter, a helicopter, and a freight train are like a pushcart. It's an interface that helps you manage your computers, the things on them, and the things they're connected to. It's also a hugely efficient and effective way to process information and issue commands and controls in a useful way.
I've switched from screen to tmux about a year or two ago, after decades of using screen.. and I'm perfectly happy with tmux, as it fits my needs.
However, it's not true that screen has no advantages over tmux. Each program has its own strengths and weaknesses. For instance, screen is scriptable via its Lua bindings, tmux is not. Screen has zmodem support built in, tmux does not. There are probably many other examples, since screen has a bazillion features which have been developed over decades, while tmux is relatively new (and its developers don't seem to care to duplicate every one of screen's features).
tmux is scriptable from the shell via its command-line arguments, so any language can script it.
It's certainly true that screen does have tons of small old features... but I sort of swept that in with "unless you're using HP-UX or something." zmodem support isn't exactly relevant to the overwhelming majority of programmers, but yes, I admit these things are still relevant to a few niches.
"tmux is scriptable from the shell via its command-line arguments, so any language can script it."
I'm not sure if tmux is scriptable to the same extent that screen is via screen's Lua bindings, as the latter probably exposes many of screen's internals, while scriptability of tmux is limited to what you could do with its command line arguments. I haven't researched the matter, though, so I may well be wrong.
Perhaps not, but tmux's bindings are nearly all backwards-compatible with screen's. Well, the default escape char is ctrl-B but I (and I think most folks) just remap it to ctrl-A immediately.
I always rebind it to ^z. Since I never need to put a process in the background (I just open a new screen instead) when running screen, it never bothers me that that combo is a bit harder to type.
i use the ratpoison window manager (it works a lot like tmux/screen, but for x11) and have control+a set as its prefix key. i use tmux for some long-lasting remote sessions, so to send a control+a to the shell running under tmux, under ratpoison, i type control+a, a, control+a, a. yes, i do it a lot. no, i'm not going to change it.
I actually only learned that ctrl-A works in bash 3-4 months ago, and haven't yet picked a new screen/tmux escape and retrained to it. Mainly because these days, I only use screen when I WFH or am traveling, when I ssh into my workstation. Almost nobody has ssh rights to a production machine, so I'm actually struggling to think when I would use it from my workstation.
screen, pdsh,
perl -pi -e 's/find/replace/g' *.txt
redis-cli's new ability to have piped in data be the last argument of a command.
vim -o file1.txt file2.txt file3.txt (opening multiple files with vim)
Using vim instead of less as a pager: cat file.txt | vim -