Learn Enough Command Line to Be Dangerous (Draft)(learnenough.com)
learnenough.com
Learn Enough Command Line to Be Dangerous (Draft)
http://www.learnenough.com/command-line
62 comments
When introducing kill, don't use -9. Not a good way for a beginner to learn kill. Guess you weren't kidding with "Learn Enough Command Line to Be Dangerous". Understood that it's a draft. Coming together nicely.
kill -15 $pid ||
kill -2 $pid ||
kill -1 $pid ||
kill -9 $pid
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.
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.
Could you expand on this? In my experience, kill frequently fails without -9, so I basically always include it (and it's never bitten me). I'm open to suggestions, though, so if you have a recommendation for a better way I'd appreciate the feedback. (Feel free to shoot me an email at the address in my profile.)
As already stated, a process cannot respond to KILL signal, not allowing it to cleanup after itself. In many cases this may be OK or irrelevant, but you should never use -9 as a first resort. -9 is a last resort.
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 ;).
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 ;).
So would it be reasonable to recommend kill $pid as a first step and kill -9 $pid if that doesn't work? Bear in mind that this is a tutorial for beginners, so things like kill -15 $pid || kill -2 $pid || kill -1 $pid || kill -9 $pid (as another commenter suggested) aren't appropriate, but I feel like kill is too important a command to leave out completely.
On the other hand, it seems almost all the times when I've had to use kill it's because the process has already refused to die by more normal means and I doubt it'd respond to a non-9 kill.
kill -9 is like rm -rf. Sometimes you need it, but it's the path of maximum destruction. In the case of kill, signal 9 (SIGKILL) is a signal that processes cannot trap, so they immediately end without any chance of cleanup or saving state. Unless you really don't care about data the process may have been working with, it's usually best to try a plain kill (sending SIGTERM) first.
Fails? Frequently? In whet contexts? Was the process already suspended?
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.
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.
An example where kill -9 can screw things up is killing a database process (e.g. MySQL, mongo, etc). Killing it with -9 will most likely lead to data corruption/loss, as the process might be in the middle of flushing to disk for example.
Any database that can't recover from kill -9 is not worth trusting your data with.
Nicely done! Feedback, since it's a draft: There's a lot of introductory verbiage at the beginning. I wonder if this could be condensed or put off in a sidebar.
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.
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.
Thanks for the feedback. The reason for the verbiage is that this is the first of eight planned prerequisite tutorials [1], so Learn Enough™ Command Line to Be Dangerous is setting the stage for all the others as well. The introduction to each future tutorial will be focused exclusively on the content of that one document. I'll definitely look at putting some of the intro into a sidebar, though; that might work well.
Regarding Command-space, I've added a clarification regarding ways to start Spotlight. Thanks again for the helpful suggestions.
[1]: http://learnenough.com/
Regarding Command-space, I've added a clarification regarding ways to start Spotlight. Thanks again for the helpful suggestions.
[1]: http://learnenough.com/
My cmd + space is actually somehow bound to both, so to search I do:
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.
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.
This is (or at least used to be) the default. I find it completely insane that Apple would ship with this. I know japan has special keyboards with buttons for changing language, but China and Hong Kong uses American layout and need to be able to switch.
What a great tutorial. This was definitely an underserved portion of the learning process. Also, learned `cd -` and I think my days will be ever so slightly but definitely better for it. Thanks for sharing!
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.
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.
There are times i wish rm had a dry run kind of switch, where it would list out all the files that would be affected before asking for approval.
The point in the introduction about people who work with developers needing to be familiar with the console is hugely important, in my opinion. It's the one bridge, short of someone having actual previous coding experience, that really makes my life easier at work. It also makes people feel, or so I observe, more confident and in control of their workstation.
Indeed, I hope that the three-tutorial sequence covering the command line, text editors, and Git will be a useful package for the works-with-developers crowd.
This is great! I work on a team of "intended audience members" for this and have already shared it with some people. Is this the first of the 3 tutorials or do Git/Editors ones exist as well? (I know there are plenty of other git resources out there) Cheers!
Glad to hear it! Learn Enough™ Command Line to Be Dangerous is the first of eight planned prerequisites to the Rails Tutorial, the first three of which cover the command line, text editors, and Git. The text editor tutorial is currently in preparation, to be followed by Git, et al. See http://learnenough.com/ for more information.
I really like the format and styling! It's broken up nicely with the images you added and the commands are kept to the really important ones. The summaries at the end of each chapter is great as takeaway. Maybe you could create a cheat sheet of the combination of summaries?
I'm looking forward to the Git edition of this series.
I'm looking forward to the Git edition of this series.
Maybe you could create a cheat sheet of the combination of summaries?
Cool, that's a great idea. It should be easy to extract all the relevant tables and put them into a single document. Thanks!
Cool, that's a great idea. It should be easy to extract all the relevant tables and put them into a single document. Thanks!
For people who would like to go further, and explore writing command line tools (instead of only using them), in C [1], for Linux [2], this post and the linked article in it, by me, may be of help:
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.
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.
I really wish developers today (in the 2000s, for Christ's sake) didn't have to deal with such a horrible UI.
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.
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.
Feel free to abstract away the entire shell. The shell is merely a command-driven REPL that interacts with the kernel API, rewrite the shell however you want with an embedded interpreter like how Emacs eshell works (learn one shell, works across every OS Emacs is ported to).
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.
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.
[deleted]
I enjoy Unix and the Unix philosophy, but I'm legitimately interested: what would a better system look like to you?
There's the rather entertaining talk "A Whole New World" by Gary Bernhardt1[1]. The first time I saw it I was quite disappointed such a system didn't exist.
[1]: https://www.destroyallsoftware.com/talks/a-whole-new-world
[1]: https://www.destroyallsoftware.com/talks/a-whole-new-world
I'll take this one:) http://housejeffries.com/articles/unix-delenda-est
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/
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/
I'm just riffing here but maybe the reason we're stuck on *nix is because it came from a time before The Cloud, subscription software, sharecropper software, etc. It was made to make you more productive; Not to make you #<whatever> of #<whatever> user of Super.os.
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.
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.
demonstrate your improvement
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
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.
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.
Plan 9 started as an off-shoot of Research Unix and in some ways it is the raw, unfiltered Unix ideal, along the way influenced from work done at PARC and ETH Zurich. By and large the GNU/Linux community seems to be drifting away from Unix as far as possible.
Genera certainly sets a bar for a single-user workstation.
Genera certainly sets a bar for a single-user workstation.
Why is 1,060 KB of JavaScript required to display this wonderful text page? Is there a way to read just the text without any interactive elements?
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. The flexibility and convenience of Softcover come at the price of a little extra JavaScript—a price that, from my perspective, is well worth paying.
What has the world come to where the command line is something foreign to a software developer? Throw me on an island with a few unprovisioned *inux boxes and I'm all set.
What has the world come to where the command line is something foreign to a software developer?
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.
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.
A different type of world?
I agree. We're entering a world of Microsoft Bob for software engineers, architects, developers. I suppose there's more opportunity to invent and discover because of this. Some people eat McDonalds, I prefer my own garden from the ground up. I can actually invent new things that way.
I prefer my own garden from the ground up, but I still eat McDonalds!
I understand this thing is aimed to create super power perception within tech novice ppl when some command line is learned, but, seriously, this new fashion of claiming that if you wrote couple lines of code means you are software guru now, is absurd.
Who claimed this? You totally missed the point of these tutorials. It's "Learn Enough Command Line to Be Dangerous" NOT "Learn Everything About the Command Line to Be a Guru".
What do you have to do to get at the content?
You should just be able to scroll down. If that doesn't work, send an email to the address in my profile with details on exactly what's confusing you. For future iterations of the UI, I'm looking at adding access to the table of contents as well.
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.
[1]: http://conqueringthecommandline.com/book
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.
[1]: http://conqueringthecommandline.com/book
Maybe whip up some curl commands in a command line, post-processed with sed and awk.
I enabled JS from a couple of domains, then gave up and backbuttoned out.
I enabled JS from a couple of domains, then gave up and backbuttoned out.
Here is the table of contents to make things a bit easier so you won't have to go through all the URLs: https://softcover.s3-us-west-2.amazonaws.com/8/unix_commands...
This is the ToC for a different book.
Use the command line to get the URLs for each chapter?
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
You appear to be confusing two different documents. The OP refers to http://learnenough.com/command-line, not http://conqueringthecommandline.com/book.
[deleted]
Indeed. My apologies. Instructions to get the URL to the Hartl draft are the same, except:
Substitute "learnenough.com/command-line" for "conqueringthecommandline.com/book"
Commandline.fu is a good source too
[deleted](2)