Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Last command
To execute last command over again you can of course press ↑ (arrow up) key. But you can also type !!. So executing last command as a root is very easy
While !! is great, the overall ! method becomes really powerful if you understand that you're neither limited to re-executing just the last command or re-executing the command relatively unmodified.
Previously executed ssh host1.my.domain and now need to connect to host2.my.domain? Execute either of ^host1^host2^ or !!:s/host1/host2
Related to the latter, if you execute history and see that you previously connected to host1 with the 23rd command in your history-buffer, you could do !23:s/host1/host2
Have a command in your history that had a repeating string that you'd like to substitute all values for? !43:gs/orig_string/new_string
Agree for everything
I would be suuuuuuuper leery about developing habits around the yes command. Great sadness can ensue from habituating to its use ...especially if you have privileged access to a system. For commands that implement a built-in auto-yes feature (e.g. your yum does via the -y flag). Even there, I'd tend to avoid auto-yes except in the very specific context of scripted routines where you've validated the the auto-acknowleged behavior always acts the way you expect and need it to.
It's also worth noting that not every command you use will understand accepting a yes from piped <STDIN>
Run a long-lasting process in the background and close the terminal
There are a non-trivial number of commands that don't react well to being backgrounded. You might think, "lemme background this thing and let it go about its business" only to come back minutes/hours/days later to find that it's done nothing. Basically, whenever you background a command, it's always a good idea to run the jobs command immediately afterwards to verify that it's in a running state. You may, instead, find that your backgrounded command is in a stopped state.
Even better than using shells' built-in job-control for long-running tasks may be to use a terminal-multiplexer like screen or tmux. They're also great if you're connecting to a system over crappy links (remote in, fire up screen, kick off your tasks ...even if your connection dies, stuff keeps running and you can re-connect and re-attach to your session to finish things up).
While
!!is great, the overall!method becomes really powerful if you understand that you're neither limited to re-executing just the last command or re-executing the command relatively unmodified.ssh host1.my.domainand now need to connect tohost2.my.domain? Execute either of^host1^host2^or!!:s/host1/host2historyand see that you previously connected tohost1with the 23rd command in your history-buffer, you could do!23:s/host1/host2!43:gs/orig_string/new_stringI would be suuuuuuuper leery about developing habits around the
yescommand. Great sadness can ensue from habituating to its use ...especially if you have privileged access to a system. For commands that implement a built-in auto-yes feature (e.g. youryumdoes via the-yflag). Even there, I'd tend to avoid auto-yes except in the very specific context of scripted routines where you've validated the the auto-acknowleged behavior always acts the way you expect and need it to.It's also worth noting that not every command you use will understand accepting a yes from piped <STDIN>
There are a non-trivial number of commands that don't react well to being backgrounded. You might think, "lemme background this thing and let it go about its business" only to come back minutes/hours/days later to find that it's done nothing. Basically, whenever you background a command, it's always a good idea to run the
jobscommand immediately afterwards to verify that it's in a running state. You may, instead, find that your backgrounded command is in a stopped state.Even better than using shells' built-in job-control for long-running tasks may be to use a terminal-multiplexer like
screenortmux. They're also great if you're connecting to a system over crappy links (remote in, fire up screen, kick off your tasks ...even if your connection dies, stuff keeps running and you can re-connect and re-attach to your session to finish things up).Yeah! I was also going to suggest
tmuxinstead ofnohup.