I'm going to talk about two simple kinds of commands, which I shall call "Type 1 Commands" and "Type 2 Commands". These terms are coined by me. They're pretty arbitrary, and are for educational purposes only. The characteristics they describe are (I believe) helpful in teaching these concepts to beginning users, because they will be easily recognized by humans. However, they are meaningless to computers, This is a user-oriented tutorial, and I'm trying to describe things from a human's point of view. A programmer-oriented tutorial will have to teach you the computer's point of view, which is probably more accurate and "real".
People are always repeating the myths about how hard it is to use shell commands, and back before there was a GUI, it must have been really hard, because you had to know how to do everything at the command line, in order to use the computer at all. There was no such thing as using the command line a little bit here, a little bit there, picking it up slowly at your convenience. There was no GUI to support you through the learning process, it was all or nothing, but the fact that THE COMMAND LINE (say it with me) PART OF THE DESKTOP means that I can show you an easy trick for using really easy shell commands to program your GUI, and you can learn it, and benefit from it, without having to learn another thing. So here's something easy and powerful that I call Type 1 Commands and Type 2 Commands
Type 1 Commands
Tp put it simply, Type 1 commands are one word commands. I use the designation Type 1 Command to refer to the practice of opening or using an application or program by simply naming the application or program without any option or arguement, just the one word. Usually, this applies to GUI based applications.
Yes, that's right. There are shell commands for opening GUI desktop applications. That's because the command line is part of the Desktop.
For example, the command for opening the web browser Firefox is:
>firefox
The command for opening Dolphin, KDE4's new, advanced file manager goes like this:
>dolphin
The command for opening k3b, my favorite CD burning application, goes like this:
>k3b
Is a pattern starting to emerge? You name the application, and it opens. You may be asking yourself what's the point of using the command line to open applications when you've got a menu for that, but I promise you, there is an answer to that question... and it's a good one! Stay a while.
Type 2 Commands
I'm going to use the term "Type 2 Commands" to refer to two-word commands, a command followed by an arguement.
A sense of syntax is really the key to using the command line, or any language. You didn't need to memorize every sentence that you ever spoke or write, and once you understand the syntax, you're not going to have to memorize every command you use. And in this very important case, the syntax is very easy to understand.
Basically the syntax works like this
X (application) opens Y (file, web address, etc)
As in:
>firefox www.google.com
which means Firefox opens www.google.com
>mplayer ~/Music/"The Beatles, She Loves You.mp3"
Which means mplayer opens the file named "The Beatles, She Loves You.mp3"
A little sidebar: Now, there are a couple things about this command that I ought to explain for now, though I will cover these topics later, so you can skip this part if you like. They have to do with the url, or path, for the file mentioned above:
~/Music/"The Beatles, She Loves You.mp3"
The squiggly line:
~
At the beginning of the path is called a TILDE, and it represents my home directory. It's a kind of a shortcut. The path to the file actually looks like this:
/home/bbjones/Music/"The Beatles, She Loves You.mp3"
In the path above,
/home/bbjones
is my home directory. (bbjones is the normal account user name, by which I login) It's where all of my personal files are located, and so, naturally, it comes up a lot. And so, naturally, a short cut is useful
~
represents
/home/bbjones
i.e., the home directory of the logged in user.
The quotes around the name of the file
/home/bbjones/Music/"The Beatles, She Loves You.mp3"
are there because the file name has spaces in it, and the quotes tell the computer that the all of the words refer to one file name, not several files named "The" "Beatles," "She"... and so on. If there were no spaces in the file name, the quotes would not be necessary, as in the command:
>mplayer ~/Music/The.Beatles.-.She.Loves.You.mp3
Okay, so we're back. Here are a couple more examples of Type 2 Commands.
>k3b ~/Desktop/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso
K3b (the CD burning application) opens the iso image KNOPPIX_V5.1.1CD-2007-01-04-EN.iso, which is located in my Desktop folder
>opera http://www.twitter.com/blackbelt_jones
translation: Opera (a web browser) opens to the web address http://www.twitter.com/blackbelt_jones, which is my twitter blog.
If this isn't incredibly easy so far, I'm explaining it wrong. Type 1 commands are one word commands like this
>xchat
Type two commands are two word commands like this:
>firefox http://www.thecommandlineispartofthedesktop.blogspot.com
Sunday, January 18, 2009
Saturday, January 17, 2009
1. I can prove it.
Have I mentioned that the Command Line is part of the Desktop?
The myth that the command line and the Desktop GUI are separate, competing entities persists from the 1980's, when the GUI took over from the big bad black console as the favored user interface, and thank heaven! Practically everyone agrees that this was a good thing, a very good thing, a super-duper good thing. But it's 2009, and the GUI and the CLI are now friends, not rivals. After a quarter century, the big black console still exists, but the command line that most command line users use most of the time has evolved and been integrated into the GUI. It's part of the desktop! I can't stress that enough, because, it seems no matter how much I stress that, some people just don't get that. Most people still think that using the command line means somehow not using the GUI, but what you get when you learn how to a use few shell commands is a stronger, faster, better GUI.
Almost a decade into the 21st century, some people are still debating whether the Command Line is better than the GUI. Well, I have chosen to dedicate a certain portion of my life to the proposition that this is a really stupid thing to debate.
Which is better, the screwdriver or the the hammer? Depends on whether you've got to drive a nail or a screw, right?
Which is better, a fork or a spoon? Well, am I eating soup, or a salad? And what if I'm at the Old Country Buffet, and I want to have soup and a salad? Do I use a fork or a spoon?
Obviously, I want both a fork and a spoon. Folks, it's not about one tool being better than another tool. It's about two tools being better than one tool. There are lots of reasons for migrating from a Brand W operating system to GNU/Linux, and one of the best is that GNU/Linux has developed as a two tool operating system, wheras brand W has developed almost entirely as a one tool operating system. A powerful command line is one of Linux's primary advantages, but the command line still has a 1980s image problem. Whenever Linux users mention the command line, Windows users seem to take it as an admission that Linux doesn't have a decent GUI, but we've got several elegant GUIs that are lovingly designed by the people who use them. Some seem strange to the uninitiated, others are more familiar, but there are plenty of excellent choices. If you migrate to GNU/Linux, I would suggest that you're never going to get the full benefit if you're not willing to use both tools, the GUI and the CLI within the GUI. Frankly, switching to Linux can be too much of a pain not to claim the full benefit.
User friendliness, the ability for an unschooled user to just sit down and get to work is a good thing, a great thing, a super-duper great thing. It has been a touchstone of GNU/Linux development for as long as I've been involved with Linux, and probably longer... but if you're going to be using your computer for twenty, thirty, or forty years, wouldn't you like to learn a few tricks along the way for saving you a lot of time, for automating repetitive drudge work, for teaching your GUI to do exactly what you want it to do? What if it wasn't nearly as hard to learn as you think?
I can prove it. But first, a little disclaimer.
A big part of the method of this book is to attempt to teach you commands by classifying shell commands according to syntax. Understanding syntax is key to human language, and I think it's an important key to the simple, imperative language of Unix Shell Commands. These classifications are arbitrary, artificial, and entirely my own creation. They are for educational purposes only.
This is a user-oriented tutorial, and I'm trying to describe things from a human's point of view. This method of classification will be (I believe) helpful in teaching these concepts to beginning users, because they will be easily recognized by humans. However, they are meaningless to computers. A programmer-oriented tutorial will have to teach you the computer's point of view, which is probably more accurate and "real".
The myth that the command line and the Desktop GUI are separate, competing entities persists from the 1980's, when the GUI took over from the big bad black console as the favored user interface, and thank heaven! Practically everyone agrees that this was a good thing, a very good thing, a super-duper good thing. But it's 2009, and the GUI and the CLI are now friends, not rivals. After a quarter century, the big black console still exists, but the command line that most command line users use most of the time has evolved and been integrated into the GUI. It's part of the desktop! I can't stress that enough, because, it seems no matter how much I stress that, some people just don't get that. Most people still think that using the command line means somehow not using the GUI, but what you get when you learn how to a use few shell commands is a stronger, faster, better GUI.
Almost a decade into the 21st century, some people are still debating whether the Command Line is better than the GUI. Well, I have chosen to dedicate a certain portion of my life to the proposition that this is a really stupid thing to debate.
Which is better, the screwdriver or the the hammer? Depends on whether you've got to drive a nail or a screw, right?
Which is better, a fork or a spoon? Well, am I eating soup, or a salad? And what if I'm at the Old Country Buffet, and I want to have soup and a salad? Do I use a fork or a spoon?
Obviously, I want both a fork and a spoon. Folks, it's not about one tool being better than another tool. It's about two tools being better than one tool. There are lots of reasons for migrating from a Brand W operating system to GNU/Linux, and one of the best is that GNU/Linux has developed as a two tool operating system, wheras brand W has developed almost entirely as a one tool operating system. A powerful command line is one of Linux's primary advantages, but the command line still has a 1980s image problem. Whenever Linux users mention the command line, Windows users seem to take it as an admission that Linux doesn't have a decent GUI, but we've got several elegant GUIs that are lovingly designed by the people who use them. Some seem strange to the uninitiated, others are more familiar, but there are plenty of excellent choices. If you migrate to GNU/Linux, I would suggest that you're never going to get the full benefit if you're not willing to use both tools, the GUI and the CLI within the GUI. Frankly, switching to Linux can be too much of a pain not to claim the full benefit.
User friendliness, the ability for an unschooled user to just sit down and get to work is a good thing, a great thing, a super-duper great thing. It has been a touchstone of GNU/Linux development for as long as I've been involved with Linux, and probably longer... but if you're going to be using your computer for twenty, thirty, or forty years, wouldn't you like to learn a few tricks along the way for saving you a lot of time, for automating repetitive drudge work, for teaching your GUI to do exactly what you want it to do? What if it wasn't nearly as hard to learn as you think?
I can prove it. But first, a little disclaimer.
A big part of the method of this book is to attempt to teach you commands by classifying shell commands according to syntax. Understanding syntax is key to human language, and I think it's an important key to the simple, imperative language of Unix Shell Commands. These classifications are arbitrary, artificial, and entirely my own creation. They are for educational purposes only.
This is a user-oriented tutorial, and I'm trying to describe things from a human's point of view. This method of classification will be (I believe) helpful in teaching these concepts to beginning users, because they will be easily recognized by humans. However, they are meaningless to computers. A programmer-oriented tutorial will have to teach you the computer's point of view, which is probably more accurate and "real".
Subscribe to:
Posts (Atom)