How To Look Like A UNIX Guru Terence Parr Last updated: August 30, 2006 Translations: UNIX is an extremely popular platform for deploying server software partly because of its security and stability, but also because it has a rich set of command line and scripting tools. Programmers use these tools for manipulating the file system, processing log files, and generally automating as much as possible. If you want to be a serious server developer, you will need to have a certain facility with a number of UNIX tools; about 15. This lecture takes you through the basic commands and then shows you how to combine them in simple patterns or idioms to provide sophisticated functionality like histogramming. [By the way, this page gets a lot of attention on the net and unfortunately I get mail from lots of people that have better solutions or stuff I should add. Everything is a stream The first thing you need to know is that UNIX is based upon the idea of a stream . $ ls > /dev/null # ignore output of ls $ ls -l | grep Aug | wc -l cd
May 06, 2008 Archives | Blog of an Alpha animal There are some tools that look like you will never replace them. One of those (for me) is grep. It does what it does very well (remarks about the shortcomings of regexen in general aside). Yet, the other day I read about ack, which claims to be "better than grep, a search tool for programmers". The ack homepage lists the top ten reasons why one should use it instead of grep. It's blazingly fast because it only searches the stuff you want searched.Wait, how does it know what I want? Bottom line: yes, ack is an exciting new tool which partly replaces grep. I've written a followup on this, including some tips for day-to-day usage (and an explanation of grep's sucky performance). 'Tis well appreciated. UNIX tips: Learn 10 good UNIX usage habits Break bad UNIX usage patterns Michael StutzPublished on December 12, 2006 When you use a system often, you tend to fall into set usage patterns. Sometimes, you do not start the habit of doing things in the best possible way. Sometimes, you even pick up bad practices that lead to clutter and clumsiness. One of the best ways to correct such inadequacies is to conscientiously pick up good habits that counteract them. Adopt 10 good habits Ten good habits to adopt are: Make directory trees in a single swipe Listing 1 illustrates one of the most common bad UNIX habits around: defining directory trees one at a time. Listing 1. It is so much quicker to use the -p option to mkdir and make all parent directories along with their children in a single command. Listing 2. You can use this option to make entire complex directory trees, which are great to use inside scripts; not just simple hierarchies. Listing 3. Change the path; do not move the archive Listing 4. Listing 5. Listing 6. Listing 7.
Ghosts of Unix Past: a historical search for design patterns October 27, 2010 This article was contributed by Neil Brown The exploration of design patterns is importantly a historical search. It is possible to tell in the present that a particular approach to design or coding works adequately in a particular situation, but to identify patterns which repeatedly work, or repeatedly fail to work, a longer term or historical perspective is needed. We benefit primarily from hindsight. The previousseries of articles on design patterns took advantage of the development history of the Linux Kernel only implicitly, looking at the patterns that could be found it the kernel at the time with little reference to how they got there. For this series we try to look for patterns which become visible only over an extended time period. Full exploitation A very appropriate starting point for this exploration is the Ritchie and Thompson paper, published in Communications of the ACM, which introduced "The Unix Time-Sharing System". File Descriptors It was hierarchical.
BashPitfalls - Greg's Wiki This page is a compilation of common mistakes made by bash users. Each example is flawed in some way. 1. for f in $(ls *.mp3) One of the most common mistakes BASH programmers make is to write a loop like this: for f in $(ls *.mp3); do # Wrong! some command $f # Wrong! Yes, it would be great if you could just treat the output of ls or find as a list of filenames and iterate over it. There are at least 6 problems with this: If a filename contains whitespace (or any character in the current value of $IFS), it undergoes WordSplitting. You can't simply double-quote the substitution either: for f in "$(ls *.mp3)"; do # Wrong! This causes the entire output of ls to be treated as a single word. Nor can you simply change IFS to a newline. Another variation on this theme is abusing word splitting and a for loop to (incorrectly) read lines of a file. IFS=$'\n' for line in $(cat file); do … # Wrong! This doesn't work! So, what's the right way to do it? for file in ./*.mp3; do # Better! 2. cp $file $target
Debugging a segmentation fault using gdb « Tech Rants by Jitesh I am not a big proponent of gdb. If you *really* know what you are doing, gdb shouldn’t be required. But, every now and then, you come across code that has used function pointers exclusively and then, hand-debugging becomes painful. gdb to the rescue. You’ll need the following pre-requisites to use gdb to debug a segmentation fault: 1) make sure you have compiled the executable WITH debugging symbols. i.e. the "-g" flag. eg gcc -g -o hello hello.c Without debugging symbols, gdb won’t be able to do much. 2) Linux should core-dump on segmentation fault. Now just run that the excutable that is segfaulting. Now, we just have to tell gdb to analyze this core. eg. gdb hello core.1324 Check out the output spit out by gdb and make sure that all debugging symbols have been loaded. (gdb) bt (bt = backtrace .. prints stack strace) with this backtrace you’ll now know *exactly* where the program segfaulted. You can even analyze variable values on any frame. Like this: Like Loading...
Mastering the Bash History – Make Tech Easier The Bourne Again Shell, better known as bash, is the default for most Linux distributions. It’s extremely powerful as far as command shells go, and holds all kinds of nifty tricks for those willing to learn. One of the best features is, in my opinion, the command history system. There are many options to use with the bash history, some of them I use nearly every time I open a command shell. Up/Down Arrows Many of you probably know this one, but for anyone who doesn’t, it’ll make your life a lot easier. A similar feature to the one listed above is the double bang (!!). Bash will substitute the !! This also works further backward, you can do something like to recall the command 5 entries back in the history. ! Perhaps a few days ago you typed a long, complex command into your shell, for example a series of options for “wterm”. Be careful with this one. !? This is similar to the last feature in that it searches the history for the word entered, but unlike ! Ctrl-R Manual Search ! into your shell.
UNIX tips: Learn 10 more good UNIX usage habits Let's face it: Bad habits are hard to break. But habits that you've just become comfortable with can be even more difficult to overcome. Sometimes, a fresh look at things may provide you with an "A-ha, I didn't know you could do that!" moment. Building on Michael Stutz's excellent article, "Learn 10 good UNIX usage habits," this article suggests 10 more UNIX command-line commands, tools, and techniques that may make you more productive as a UNIX command-line wizard. The 10 additional good habits you should adopt are: Use file name completion.Use history expansion.Reuse previous arguments.Manage directory navigation with pushd and popd. Use file name completion Wouldn't it be great if you didn't have to type a long, convoluted file name at the command prompt? Which shell am I running? What happens if you don’t know which shell you're currently running? Listing 1. $ echo $0 -bash $ ps –p $$ PID TTY TIME CMD 6344 ttys000 0:00.02 –bash C shell Bash Korn shell Use history expansion Listing 2.
Linux tips every geek should know | TuxRadar What separates average Linux users from the super-geeks? Simple: years spent learning the kinds of hacks, tricks, tips and techniques that turn long jobs into a moment's work. If you want to get up to speed without having to put in all that leg-work, we've rounded up over 50 easy-to-learn Linux tips to help you work smarter and get the most from your computer. UPDATE: If these tips aren't enough and you want even more, make sure you check out More Linux tips every geek should know! #1: Check processes not run by you Difficulty: Expert Application: bash Imagine the scene - you get yourself ready for a quick round of Crack Attack against a colleague at the office, only to find the game drags to a halt just as you're about to beat your uppity subordinate - what could be happening to make your machine so slow? OK, let's list all the processes on the box not being run by you! ps aux | grep -v `whoami` Or, to be a little more clever, why not just list the top ten time-wasters: find . reset
How and when to use the dd command via reddit.com 58 Cool Hacks - LXF Wiki From LXF Wiki (Originally written for Linux Format issue 58, October 2004) Increase your guru points and apply these cunning hacks to boost performance, secure your system and increase productivity - or fun! One of the great things about Linux is that there's usually more than one way to do something. Chances are, the way you are doing a particular task right now isn't necessarily the best way either. This collection of hacks is the result of a lot of effort: some are functional, some are fun, but they are all cool! DISCLAIMER: Obviously, anything you do to your computer is your responsibility, and while we have made every effort to test these hacks, your mileage may vary. Fix a wonky terminal Difficulty: Easy Application: bash We've all done it - accidentally used less or cat to list a file, and ended up viewing binary instead. reset and all will be well again. Creating Mozilla keywords Difficulty: Easy Application: Firefox/Mozilla Running multiple X sessions #!