Learning Linux command line

Personally I use vi but that's mainly due to the vast majority of systems I've used not having emacs installed. I wouldn't say I'm an expert in it by any means but I can do everything I usually need to without thinking about it.

Can't say I've ever had any interview questions about it though ... It's always been assumed that you can use a standard editor and questions have been on more complex things ...

Back on topic though the thing about learning the Linux command line is that once you have learnt the "glue" methods of sticking commands together to do what you want then really what you are doing is learning lots of little command line applications and interfaces rather than a command line as such. Hence as you come across various new tools you learn to manipulate them to do what you want and learn new switches on tools you already know (like my colleague who has been a Unix admin for the best part of 20 years but was coming to terms with the -Z switch on ls yesterday).

After a while you do tend to spend a lot of time thinking I know there is a command that I can use to do this and get the info out so I can manipulate it in this way but the last time I needed to do it was 3 years ago and I can't remember it now ...
 
Vi has a steep learning curve, but it's worth learning as it will always be available. You don't need to learn too much to be able to do most stuff you need to with it, and that stuf gets into your muscle memory fairly quickly. Just pick a point on the near vertical learning curve where you know enough and rely on a cheat sheet for the rest.

They key thing about the command line is that it's a bunch of small specialist utilities that you can chain together to do almost anything with. Learn permissions, navigation and layout. Then learn pipes and input/output redirection.

Everything after that is golden.
 
Once you've become more competent at the things above then learning regular expressions, sed and awk might be useful for you.
 
Another thing - if you also really want to understand Linux/Unix as well as learning a heck of a lot of good practices for software development and design in general then I highly recommend "The Art of Unix Programming" by Eric S. Raymond (it's free and available online - link below)...

Note: It's not going to teach you the command line and I'm not saying it will... But it goes over a lot of interesting history - how and why Unix developed, what exactly makes it different, what it does right, what it does wrong... Moving on to things like the rule of least surprise, how to design good interfaces, discussions about modularity and complexity etc. And he uses some of the oldest and longest surviving Unix utilities as examples - explaining what about their design made them last so long and remain so useful...

Anyway, here it is... I can definitely say I thought I knew what I was doing before but reading this book has really helped me think about things in a new way, so I hope some of you posting here might find it useful too:

http://www.faqs.org/docs/artu/index.html
 
I'm a vi man myself. I put off learning it for years and stuck with nano in the shell or kate or gedit in a DE, but when I finally really tried vi it was a breeze :) Now i often find myself trying to use commands like cw or . in Openoffice!

Oh, and to get to grips with the shell, just dive in and try some file manipulation to start with. (I know someone's already said that but I needed an on-topic reason to post abot vi ;) )
 
dodgem said:
I'm a vi man myself. I put off learning it for years and stuck with nano in the shell or kate or gedit in a DE, but when I finally really tried vi it was a breeze :)
Click to expand...

This is what happened to me many years ago I switched when I found out the following.....

uvarvu said:
Once you've become more competent at the things above then learning regular expressions, sed and awk might be useful for you.
Click to expand...

A bit more than that.... once you've become competent at reg expressions everything becomes crystal clear. You navigate vi,emacs and even the shell by using regular expressions.
 
A lot of it is just familiarity with when and how to use certain techniques, and invariably you end up coming across similar situations time and time again and become faster at quickly knowing what to do...

For example the other day I was updating and tidying up some webpages written by someone else, which consisted of several nested pages each containing a big grid of sort of "link-boxes" - each had a coloured title bar, a picture and a line of descriptive text. The html was quite a mess and I began to wonder how the original author had the patience to type it all out or maintain it. My thought process from there was:

- The process for defining each box in this table is very similar, with only a few key things changing in each box (the text, the image and the link destination)
- It would be nice if adding or changing the content in the boxes in the future wasn't as laborious as it would be now
- But the boxes probably don't change frequently enough to need updating every time the page loads

And I instantly reached for a few bits of code I'd used before to cobble together what I feel is a solution fairly in keeping with the UNIX tradition:

A raw txt file with delimited entries of this form:

title text : image location : link destination : description text

which supports # comment lines and understands an escaped "\:" in case it appears in any of the arguments, created for each required page's table. This is complimented with a short bash script that parses the file and writes out the html.

Stick those files plus the script into a subdirectory where the pages are with a simple Makefile that can regenerate the html from all of the pages where the txt file has been updated, set the pages to include the generated html files and there you go - it's super easy to add new entries or modiy existing ones, and also very easy to edit the script to make changes to how the produced html looks across all the pages at once (though some of this is done with CSS already)

Disclaimer: Of course this isn't by any means the most super-amazing untouchable way to do things - as always there are many different approaches and I would be very surprised if this is the most efficient/elegant (I expect there is a neater way to do this with some javascript, but I'm more familiar with shell script).

Hacking something together like that is what programming in Linux shell is all about in my opinion...
 
You must log in or register to reply here.
Back
Top Bottom