Command Line Goodness, Introduction

[RoyGBiv]

In the past few years, Linux proponents, myself included, have taken a defensive posture regarding Linux and the use of the command line. One reason those unfamiliar with it often cite for being "afraid" of it is the apparent need to type commands, and they just don't have the time to learn it or don't think they can. This is a legitimate concern. Back in the day when just using a computer actually required some level of skill with such things, the often arcane command line utilities required to get anything done could be daunting. Even today, it's hard to remember all those options and sometimes just the name of the command/application itself. For example I use an app called 'iptraf' a lot, but I regularly forget what it's called. Furthermore, the plethora of options for a simple command like 'ls' can lead one to believe it requires a degree in computer engineering just to use it.

For example, there's this mess:



Will I ever use that? No.

With the proliferation of GUI wrappers to many of the most popular and useful command line applications, why bother? You can get a directory listing with the file browser and have the advantage of being able to use mv, cp, chmod, chown, etc. all with a point and click. Many of the options are inherent in the the way the GUI functions. Others are available via convenient check boxes, sliders, and buttons.

But not everything, and for a number of reasons, I still find the command line (CLI) a valuable tool. Over the next few weeks, whether you want me to or not, I'm going to put together some very simple examples of why I still use the CLI and explain why it is both more efficient and in fact easier to use than the GUI counterpart.

I am going to do this for a couple of reasons, so by way of introduction I want to explain what those are in addition to explaining what I actually intended and perhaps more importantly what I do not intend.

I've been spending a lot of time lately in the #ubuntu IRC chat room. Before long I became frustrated at the complicated mess many so-called Ubuntu gurus were putting newbies through just to perform simple tasks. GUI based applications to perform these takes vary. The path to opening those applications varies with different distributions. Very often a simple command in the terminal can accomplish exactly what the user needs without having to endure all the side discussion that inevitably follows about the "best" app to use, most of which are simply GUI front-ends for a single command line app. Offering a newbie the command line way of doing something often kills several birds with a single stone and helps them become acclimated to the idea that the CLI is actually your friend.

Secondly, I sometimes forget than even Linux gurus don't know everything and sometimes have never learned these simple ways of doing things. I certainly don't know everything and regularly read blogs and browse man pages just to see what I might be missing. The other day, in fact, I introduced a long-time Linux user to a very simple command that he'd been doing via a GUI and that took him ages of tedious work to accomplish. The command line variant took a couple seconds. Turns out he knew how to do this but had lost sight of it because he'd become accustomed to using the GUI app. Even experts can learn or, in some cases, need reminders.

What I intend to do is semi-regularly offer some simple command line methods of doing things we commonly do. I'll even offer up a few simple BASH scripts that combine commands that would be difficult to remember but placed within a script would be easy to use just by remembering the name of the script.

On the other hand, this will not in any way be intended as an exhaustive primer on using any individual command nor an exploration of the numerous ways things can be done. I do not intend to show that the command line is "better" than the GUI, just different, and for some purposes, more convenient. In fact, several of the examples I would like to offer will use the GUI and CLI in combination, sticking with my developed philosophy that it's generally not an either/or situation when it comes to technology.

If you have no interest, feel free to ignore me. :)

[Syrinx]

1. Looking forward to it, Roy!

I program in C, C++, Python. I have programmed in, but have mostly forgotten, Fortran and assembly language, among others. And I'm kind of ashamed to admit that I've never really learned how to do anything beyond the most basic shell scripting. I've never learned to do loops or decisions in bash, for example. Python just seemed more fun, I guess. :)

[RoyGBiv]

2. Hey, well ...

I'm not sure I can teach you anything.

Scripting in bash certainly isn't as elegant as python, more of a quick and dirty way to get things done.

And I certainly don't claim to be an expert. There are just a whole slew of simple things that bash is good for that I find tedious using a GUI based app. File searching, per my Part One, is one of them.

[ConsAreLiars]

3. One thing I've discovered about CLI

is that even for one who sees typing and grokking arcane magic spells as a bit beyond my skill-set, cutting and pasting into a terminal is a lot easier than click-hunt-click-huntmore. And when doing so, just pasting, I learn a little more.

[darkstar3]

4. Here's another example of WHY the CLI rules.

This script will take any DVD and turn any title on it you
choose into a beautiful but still tightly packed XVID file.

Yes, I made it myself. I need to tweak it now that the new
version of mencoder doesn't support one of my features, but it
still works.

#!/bin/sh
#framerate=24000/1001
echo "Enter DVD Device (0=top, 1=bottom)"
read device
case "$device" in
	0 )
		dvd=/dev/sr0
	;;
	1 )
		dvd=/dev/sr1
	;;
esac
lsdvd $dvd
echo "Enter VolumeName"
read VolName
echo "Is this a cartoon? (0=no, 1=yes)"
read cartoon
if [[ "$cartoon" -eq "0" ]]
then
	vrate=900
else
	vrate=750
fi
echo "Enter chapter numbers to rip (0 to exit and begin
ripping)"
a=0
while (true)
do
	read "chapter"
	if [[ "$chapter" -eq "0" ]]
	then
		break
	else
		chapters[$a]="$chapter"
		let "a += 1"
	fi
done
for ((a=0; a < ${#chapters[*]}; a++))
do
	mencoder -mc 0.003 -oac copy -ovc x264 -x264encopts
subq=4:bframes=4:b_pyramid=normal:pass=1:bitrate=$vrate:turbo=1:threads=8
-dvd-device $dvd -o /dev/null dvd://${chapters[$a]}
	mencoder -mc 0.003 -oac copy -ovc x264 -x264encopts
subq=5:partitions=4x4:8x8dct:frameref=3:me=umh:bframes=4:b_pyramid=normal:pass=2:bitrate=$vrate:threads=8
-dvd-device $dvd -o ../$VolName-00${chapters[$a]}.avi
dvd://${chapters[$a]}
	rm divx2pass.log*
done

exit 0

[RoyGBiv]

5. That's awesome ...

I shall be trying it out myself, I believe.

Which option is mencoder no longer supporting?

[darkstar3]

6. b-pyramid.

I left it in there because it's not really an mencoder problem, but an x264 problem, and they're working on it. Right now, b-pyramid simply doesn't do anything, because x264 now uses a better rate-control algorithm called mbtree and it's incompatible with b-pyramid. One day in the near future, though, I expect that to change.

The script works with or without b-pyramid, but I expect soon my files will be just a teensy bit clearer once they finish encoding. :)

[Occulus]

7. Heh. I see what you did, there.

:D