I could be wrong but I think beginners learn about -9 because beginners are more likely to start processes that they change their mind about and then cannot stop. Nothing wrong with this in the spirit of experimentation.
For more advanced users more familiar with the processes they start, I would guess -15 should be sufficient most of the time.
Ever kill -9 an unresponsive rails server process only to find that you have to manually rm the tmp server.pid file? That's because you used -9 ;).
The process might have been processing the SIGTERM and shutting down cleanly, but we are impatient so we -9, SIGKILL it, knowing that it can't process that signal and will be terminated (as long as its parent is alive). Or you are correct and there are many scenarios where it will be ignored.
Oh, the developer is walking by and I mention the "hang" to him. He replies, "did you kill -3, SIGQUIT, to generate a core? No? Bye."
Need the process to re-initialize, does the program have a SIGHUP handler?
kill is more geneneral than the name implies, though I agree signaling is an intermediate topic.
On OS X, for some languages at least, if the user has installed additional keyboard input languages, then Command-space may be taken over for switching input language, and thus the instructions for opening a terminal with Spotlight would not work.
Looked through some of the explanations and things such as the walkthrough of Ctrl-C are very well done for true beginner level readers.
Regarding Command-space, I've added a clarification regarding ways to start Spotlight. Thanks again for the helpful suggestions.
cmd + space ; esc ; cmd + space
Every once in a while I debate uncolliding them, but for some reason I get a mild kick out of occasionally unexpectedly seeing cyrillic dump out on the command line.
Also definitely go into why `rm -rf` is such a dangerous command, by that stage in the tutorial the reader has likely begun feeling confident experimenting but has yet to encounter anything really dangerous.
I'm looking forward to the Git edition of this series.
Cool, that's a great idea. It should be easy to extract all the relevant tables and put them into a single document. Thanks!
Developing a Linux command-line utility:
http://jugad2.blogspot.in/2014/09/my-ibm-developerworks-arti...
[1] In C, but the utility development guidelines described in the article mostly apply to other languages like Python and Ruby too, since the main principles are the same.
[2] It may compile and run on Mac OS X too, since it is a Unix, but I haven't tested it on that platform.
The Unix Hater's Hanbook says it well: "The original Unix solved a problem and solved it well, as did the Roman numeral system, the mercury treatment for syphilis, and carbon paper. And like those technologies, Unix, too, rightfully belongs to history. It was developed for a machine with little memory, tiny disks, no graphics, no networking, and no power."
Bu since wee seem to be stuck with Unix, I guess we need any guidance we can get.
Can also just script shell commands and create levels of abstraction to suit whatever simple layer of abstraction suits you. This is what things like Nautilus File Manager do to manipulate files with a mouse.
[1]: https://www.destroyallsoftware.com/talks/a-whole-new-world
I criticize Unix because I think it's getting in the way of the adoption of what I really love: the CLI.
Really a much better article is this one, but I didn't write it: https://mkremins.github.io/blog/unix-not-acceptable-unix/
OSes weren't worth a whole lot; Money was made on the hardware and the applications. How do you make people productive? Give them an OS that enables productivity.
Unix succeeded because AT&T didn't recognize the value of what they had.
https://en.wikipedia.org/wiki/Genera_%28operating_system%29
Personally, I think that if 1% of the resources that have gone into various Unixes had gone into either of these systems, the outcome would have been far superior.
What in the world are you talking about? The whole point of this tutorial is to teach command-line basics as a first step toward becoming a software developer. From the tutorial:
Many programming tutorials either gloss over the command line or assume you already know it. But understanding the basics of the command line is absolutely essential to becoming a skilled developer. Indeed, if you look at the desktop of an experienced computer programmer, even on a system with a polished graphical user interface like Macintosh OS X, you are likely to find a large number of “terminal windows”, each containing a series of commands at a command line (Figure 1). Proficiency at the command line is also useful for anyone who needs to work with developers, such as product managers, project managers, and designers. Making this valuable skill accessible to as broad an audience as possible is the goal of Learn Enough™ Command Line to Be Dangerous.
Update: You probably just need to enable JavaScript, as the Learn Enough tutorials use the Softcover system (http://softcover.io/), which stores the HTML on S3 and uses JavaScript to pull it in dynamically.
By the way, the other replies to this comment refer to Mark Bates's Conquering the Command Line [1], which is a completely different product.
I enabled JS from a couple of domains, then gave up and backbuttoned out.
Go to conqueringthecommandline.com/book
Save the page source
Insert the filename into the script below
Alternatively, omit filename and pipe the source of the page to the script
Works with BSD sed as well as GNU sed; first lesson: portability
a=$(printf '\004')
sed 's/s3_url/'"$a"'&/' \
|tr '\004' '\012' \
|exec sed '
s/\\u0026/\&/g;
s/.*s3_url.:.//g;
s/\".*//g;
/https:.*Amz/!d;
' filename