The Linux Command Line [pdf](iweb.dl.sourceforge.net)
iweb.dl.sourceforge.net
The Linux Command Line [pdf]
http://iweb.dl.sourceforge.net/project/linuxcommand/TLCL/09.12/TLCL-09.12.pdf
6 comments
I am using Linux for more than a year now and feel liberated from the Windows trap. Lately, Windows has become too slow in terms of even copy operations.
Looks to be a long reading. I think I can skip a few chapters .
This is one of the best tutorials around. Found it very useful and I can't even think of going to windows after reading this!
File copy operations?
Surely the time required for this is dominated by the disk IO speed?
Surely the time required for this is dominated by the disk IO speed?
The dominant operation is recalling how to copy something and actually going through the steps to copy it, not anything related to disk IO. At least, as people experience it it is.
Depending on what kind of storage devices are being used, I have observed very slow file transfers in Windows Explorer versus the Windows command-line copy command.
Thanks for the great PDF. I'm always fascinated how great pipe works in Linux.
It looks very long. 522 pages. I wish there is a smaller one.Any suggestions?
This book really helped me in my transition from windows to linux
On the one hand, it's important to realize that Linux doesn't have a single command line. It has multiple possible command lines, each implemented by a different command line shell; each shell, in turn, is almost certainly entirely capable of running on a non-Linux Unix-like OS, such as OpenBSD or Mac OS X.
On the other hand, that's precisely the kind of thing you don't mention in a book aimed at absolute beginners. It's more-or-less irrelevant to people coming from a non-command-line background who want to know how they can replicate the magic the more command line conversant can pull off.
Implying that bash is the only shell and that its command line is the only command line is a lie, but it's precisely the kind of lie that needs to be told to keep the early explanations simple and, more importantly, to get the student up and running with simple examples very early. The command line's main advantage is that you can start doing things almost instantly. Bogging down the early part of the text robs it of that immediacy.
TL;DR: Don't knock this book because it doesn't mention zsh or tcsh in the first chapter. I only mention this because I've seen people do essentially similar things.
A lot of education is based around building a lie to use as a scaffold, and then tearing it down once the actual truth you used the scaffold to build no longer requires the lie to stand upright. The trick is knowing when to tear down the lie.
On the other hand, that's precisely the kind of thing you don't mention in a book aimed at absolute beginners. It's more-or-less irrelevant to people coming from a non-command-line background who want to know how they can replicate the magic the more command line conversant can pull off.
Implying that bash is the only shell and that its command line is the only command line is a lie, but it's precisely the kind of lie that needs to be told to keep the early explanations simple and, more importantly, to get the student up and running with simple examples very early. The command line's main advantage is that you can start doing things almost instantly. Bogging down the early part of the text robs it of that immediacy.
TL;DR: Don't knock this book because it doesn't mention zsh or tcsh in the first chapter. I only mention this because I've seen people do essentially similar things.
A lot of education is based around building a lie to use as a scaffold, and then tearing it down once the actual truth you used the scaffold to build no longer requires the lie to stand upright. The trick is knowing when to tear down the lie.
> On the one hand, it's important to realize that Linux doesn't have a single command line.
Well I mean, there is a standardized shell defined (in POSIX 1003.2 or POSIX.2 or whatever the hell they call it, iirc). I don't know of any shells that actually implement exactly that, but my understanding the that the bourne shell more or less fills that role.
It seems fairly reasonable to say therefore that the "bourne again" shell is "the" shell, provided you're not teaching 'again-isms'.
(I say this as a long time zsh user)
Well I mean, there is a standardized shell defined (in POSIX 1003.2 or POSIX.2 or whatever the hell they call it, iirc). I don't know of any shells that actually implement exactly that, but my understanding the that the bourne shell more or less fills that role.
It seems fairly reasonable to say therefore that the "bourne again" shell is "the" shell, provided you're not teaching 'again-isms'.
(I say this as a long time zsh user)
http://pauillac.inria.fr/~weis/info/commandline.html