CLI v. GUI: One more light homework assignment

[Merlin Mann]

Thanks to everybody for the [swell links about getting going at the
command line][1]. Just to expand a bit on why I brought it up (and
probably will continue to, going forward), it seems to me that I keep
encountering two very distinct sorts of OSX users.

There's the folks like me who spend 90% of the day in the GUI, then
type _very carefully_--mostly from others' recipes--in the command
line; then there are the Corys and Dannys and Bens of the world who
seem perfectly happy to do everything in an ssh tunnel, only
occasionally popping their heads up to perform some task in a GUI app,
then back down they go.

In most cases, I imagine the two approaches reflect where people
started out (UNIX vs. System 7 or what have you). But, I really do get
the feeling that I'm _missing out_ by not spending a *lot* more time
learning stuff like bash and regular expressions inside out. At the
same time, I don't want to make my own ketchup or line my own brakes,
you know? There must be a reasonable line for each person's skillset.

So I guess my next question for the floor: when you have the option to
do something in either a terminal or in a GUI and the results will be
identical, how do you choose which you'll use? Are there tasks that us
schlubs are doing above ground that can be accomplished much more
efficiently (and more _easily_) in the command line? Examples? Nominate
2-3 commands we should learn and use instead of the GUI equivalent, por
favor.

[1]: http://del.icio.us/tag/osxcli (Great links for us terminal
n00bs)

[John S J Anderson]

On Sat, 18 Sep 2004 10:27:48 -0700, Merlin Mann <merli...@gmail.com> wrote:
>
> Examples? Nominate
> 2-3 commands we should learn and use instead of the GUI equivalent, por
> favor.

1) Basic file manipulation commands (cp, mv, rm, mkdir, rmdir, touch)

2) Shell globbing and wildcard patterns, so that you can quickly and
accurately pick the
files you want to apply the basic file manipulation commands _to_

3) Vi for basic file edits (says the Emacs user)

cheers,
john.
--
genehack.org

[bryce benton]

I'll chime in to say I'm glad to find this community. Productivity for
sorta nerdy Mac OS X users. Nice niche.

I'm a lot like Merlin: I'm more comfortable with the GUI, but I'm not
afraid of the command line, either. I agree with Merlin's sentiment
that if something is easier to perform via the command line, then I'd
rather do it that way.

A bit of a tangent to the CLI discussion:

I generally prefer keyboard shortcuts, but *what exactly* is the key
sequence for changing the focus of a pop-up window button? Whatever it
is, it's not intuitive for me at all. I'm referring to Photoshop
"Don't Save" and also on the Reboot Dialog Box "Restart" (I've typed
my admin username/password and hit enter--which is actually "cancel"--
about 95% of the time).

--bryce

On Sat, 18 Sep 2004 10:27:48 -0700, Merlin Mann <merli...@gmail.com> wrote:
>

[James Rifkin]

Numero 1:
grep, sed, awk: Give me text manipulation or give me death.

I'm an admin. In my world, every thing important is a text file, and
Unix gives me 1000 tools to work with text files. Example: Yesterday,
I needed a list of all of the windows machines in the department. Our
computer inventory is (obviously) a text file.

# cat ~/work/inventory | grep -i window | awk '{print $4}' | sort |
mail -s "Windows Hosts"

For the uninitiated, this opened the file which contains the list of
computers, pulled out the lines which included window or WINDOW,
extracted the host name, alphabetized them, and composed an email
containing our findings.

Learning regular expressions is like learning another language, but
it's a language I use every day.

Numero 2:
I'll second John S J Anderson: file manipulation. Working with files,
especially multiple files at once, is an order of magnitude easier in
the shell than with any Finder (or replacement).

[Kyle Maxwell]

Disk administration: du and sort are your friends when you need to
clean up a filesystem and reduce the usage. I find that a few shell
commands (maybe with some scripting) are far more efficient at it than
any GUI app I've found.

Typically, actually, any task that should be doable in just a few steps
is faster in a CLI (especially when scripted) than 5-10 mouse clicks at
disparate points on the screen.

[Merlin Mann]

Slight derail: I've been drafting a little feature on [Path Finder][1]
and thought I'd share this screenshot I'll probably use (sorry, it's
kind of big: scroll down to that bottom/black drawer).

http://pix.merlinmann.com/PathFinderBlowout.jpg

So, just in terms of workflow, if you find you need the CLI for a quick
task but don't feel like lugging out a new terminal window, you can
just pop a terminal drawer for whatever directory you're in.
Surprisingly handy and very much of the "two worlds," I think.

There's some other stuff there that's pretty nice too that I'll go into
in the article: text preview, running apps drawer, a drop pile, and a
series of "favorites" drawers. It's pretty great and well worth the
modest registration price (US$34).

[1]: http://www.cocoatech.com/pf.php (Path Finder is a very
powerful Finder replacement with a built-in terminal drawer, per-window)

[John S J Anderson]

> So, just in terms of workflow, if you find you need the CLI for a quick
> task but don't feel like lugging out a new terminal window, you can
> just pop a terminal drawer for whatever directory you're in.

I think you're still approaching this from a perspective that's too
GUI-centric. From a position that's probably too CLI-centric, the only
reason I have for using a file browser (Finder, etc.) is because I
haven't gotten around to finding a better image browser for my
particular needs.

I need to sit down and a write up a response to your "How Does a Nerd
Hack GTD?" post, because I suspect we're about as far apart on the
GUI/CLI thing as it's possible to be...

cheers,
john.
--
genehack.org * weblog == ( bioinfo / linux / opinion / stuff )

[Merlin Mann]

I'd actually *really* enjoy that perspective, John. I've only caught
it from glances and it seems fascinating and totally useful to me.

I'm not sure I get your point about GUIs, though. They've arguably
been the defining characteristic of the Mac experience for over 20
years, and I doubt that'll change for most folks (including me)
anytime soon.

Roll that response though, by all means. I have a *lot* to learn about
what's happening under the hood, believe me. :)

Thanks.

--
Merlin D. Mann
mail: merli...@gmail.com
site: http://www.merlinmann.com

[Kyle Maxwell]

Just to point out a similar feature in Linux for us non-MacOS users: In
GNOME, there's an applet you can add to the panel called, surprisingly
enough, "Command Line". It lets you run little one-line commands that
don't need output (useful if you need to mount/unmount a drive or
something similar). It's not what you're describing but is great for
when "you need the CLI for a quick task but don't feel like lugging out
a new terminal window".

[restiffbard]

Similarly, on OS X for those of using Quicksilver (we all should be)
there is a plugin for QS that provides basically the same function as
the one-liner Linux Command Line interface does.

[restiffbard]

For anyone interested in learning Vi or more likely ViM (Vi Improved) I
recommend perusal of the ViM Tips pages at
http://www.vim.org/tips/index.php

As for ways to make the CLI work for you and how to approach I would
suggest learning about Bash aliases as a first step.

One thing everyone should do is customize their CLI environment. In
the CLI world many programs are customized through their various .
(dot) files. Bash itself is set up by .profile and .bashrc. ViM is
governed by its .vimrc. All of these are located in your home folder
(directory).

Now, how does one get started customizing all these varied dot files?
I started by cribbing from this site
http://www.dotfiles.com/

This is all just turning into some sort of massive mish-mash how-to.
But, I just highly suggest that once you start learning to make the CLI
a place you like, that looks the way you want and behaves as you want
that you'll find it far less intimidating. Once you've configured your
own prompt there's something of a feeling of satisfied conquest. Sort
of a "look ma, I did that" effect that just makes doing more, easier.

And, lastly don't be afraid to screw up. You will. The most that will
happen is you'll get an error message. And don't be afriad to ask some
Linux Guru. They're not the evil ogres they're made out to be and a
lot of them use or like OS X too.

Sorry to drag on like this but there's so much to learn about the CLI.
And, none of it should be frightening.

[fired...@gmail.com]

I don't understand why this is, but when I'm using OS X or Windows, I
instinctively use the GUI for both. This is depite having either a
terminal or cygwin environment available on both.

When I run Linux, I instinctively use the shell. I just don't get it.
There's something in the UI that's forcing me this way, and I don't
know what it is.

[Merlin Mann]

Well, I'm finally taking the plunge: grabbed the [OSX build of GNU
emacs][1].

Looks incredibly flexible, but quite a learning curve. I'll pick up the
O'Reilly book I guess, and start whacking my way around.

Here goes nothing. :)

[1]: http://www.mindlube.com/products/emacs/ (OSX build of GNU
emacs)

[John S J Anderson]

> Well, I'm finally taking the plunge: grabbed the [OSX build of GNU
> emacs][1].

I eagerly await hearing what you think.

> Looks incredibly flexible, but quite a learning curve. I'll pick up the
> O'Reilly book I guess, and start whacking my way around.

The ORA book might not be the best choice -- it's rather out of date.
The GNU manual should come with your download (or it's trivially
available online), or you can order it from Amazon. It's more a
reference than a tutorial. You might want to consider the "GNU Emacs
and XEmacs" book by Larry Ayers -- I think I'd recommend that one
before the ORA book at this point.

Still working on a response to the GUI/CLI thing; it's turning into a
bit of an essay, and I don't really have the time for that at the
moment... 8^/=

Do keep us posted on the Emacs Adventure.

[Christopher Elkins]

On Sun, 19 Sep 2004 20:28:20 -0700, Merlin Mann <merli...@gmail.com> wrote:
>
> Well, I'm finally taking the plunge: grabbed the [OSX build of GNU
> emacs][1].
>
> Looks incredibly flexible, but quite a learning curve. I'll pick up the
> O'Reilly book I guess, and start whacking my way around.
>
> Here goes nothing. :)

One thing you can do to ease the transition is enable some of the
traditional Mac keybindings (e.g., Cmd-Q, Cmd-C/Cmd-V) by adding the
following to your .emacs file:

;; --------------------------------------------------

(when (featurep 'mac-carbon)
;; Gobble command key
(setq mac-command-key-is-meta nil)
(setq mac-pass-command-to-system nil)

;; Support traditional Mac keybindings for cut, copy, etc.
(global-set-key [(alt q)] 'save-buffers-kill-emacs)
(global-set-key [(alt m)] 'iconify-or-deiconify-frame)

(global-set-key [(alt s)] 'save-buffer)
(global-set-key [(alt w)] 'kill-buffer)

(global-set-key [(alt x)] 'kill-region)
(global-set-key [(alt c)] 'kill-ring-save)
(global-set-key [(alt v)] 'yank)
(global-set-key [(alt a)] 'mark-whole-buffer)

(global-set-key [(alt f)] 'isearch-forward)
(global-set-key [(alt g)] 'isearch-repeat-forward)
)

;; --------------------------------------------------

The above plus some additional entries in my system-wide OS X
keybindings means that whether my fingers are in "Mac mode" or "Emacs
mode", the right thing generally happens no matter what kind of text
box I'm looking at. (Well, except for Carbon apps, but I don't use too
many of those.)

--
Christopher Elkins

[John S J Anderson]

On Sun, 19 Sep 2004 22:11:06 -0700, Christopher Elkins
<christoph...@gmail.com> wrote:

> One thing you can do to ease the transition

[ snip ]

Another thing you can do is be aware of the excellent emacswiki.org.

[James Clarke]

There is also Enhanced Carbon Emacs[1] which comes preloaded with
various packages. Not only is it great to use as a latex environment
but it also provides other packages that you would typically want. As
it is emacs you can easily add other packages and customisations via
your dotfiles.

James

[1]: http://www.inf.unibz.it/~franconi/mac-emacs/

--
http://jamesclarke.info

[Tim Conrad]

I've been using MacOS for a long time, basically since the late 80's.
I've been using Unix for probably 7 or 8 years now. In short, I think
there's a place for GUI's and I think there's a place for
commandlines.I'm going to give some examples of where I use
commandlines over the GUI's.

Probably the most important thing to understand about the way that Unix
works, in general, is that it's a 'tool-based' system. Instead of doing
the Microsoftian design concept, wherein a single tool does everything
under the sun, there are a bunch of small tools that can be hooked
together to do something complex. There are some other examples in this
group of parsing a file and printing out a certian column of the data.

Some of my examples given, there are certianly Apple-specific ways to
do these things. But, these are things that *I* would do in the
commandline instead of manually.All of these things are also
'portable', in other words, they should work across all Unix-like
operating systems.

For a pre-flight checklist item, learn the 'man' command. It takes a
bit of getting used to to get the hang of how manpages are written.
But, once you do, you'll cry when you have to use systems that don't
have them. (e.g. windows) Being a good System Administrator doesn't
mean that you know everything. It means that you can quickly and
effectivly find answers to your problems.

I'm assming at this point, that you can do very basic shell commands,
such as:
mv - move a file (You can also use this to 'rename' a file)
cp - copy a file
rm - remove (delete) a file
ls - list contents of a directory
cd - change directory to something

After the basics, learn the 'find' command. Find out how powerful it
is. Say you have to do some housecleaning on your home directory
becuase you're out of disk space. So, try:
find ~/ -size +1024 -atime +30 -print

So, what does this do? ~/ is telling it to search your home directory.
~/ is short for your home directory on virtually all unix-like systems.

-size is finding anything above 1024 characters. You'll probably have
to mess with this one a bit to truly find large files

-atime is finding all the files that haven't been accessed in the last
30 days.

-print will print the results.

Unless you're amazingly tidy, unlike me, you'll probably end up with,
say, images in random places in your home directory. In a fit of
organization, you decide to make an images directory. Keep in mind,
this is somewhat dangerous, because you could move things you didn't
intend to. But, let's do a:
find ~/ -type f -name "*.jpg" -exec cp {} ~/images \;

Swahili, you say! Not quite. As a point of practice, do 'man find' find
specifically what this does. In short, it's going to find every 'file'
in your home directory that looks like *.jpg and copy it to ~/images.

One more example that I do use from time to time. You've downloaded
some sort of tarball from somewhere containing something. Some yo-yo
before you set permissions that makes it quite impossible for you to
reasonably use the contents. It's a bunch of flat text files/html
files/non-executable files.

find /path/to/dir -type f -exec chown 644 {} \;

We're going to go and find all of the files, and change the
permissions. Likewise, changing -type f to -type d to find the
directories. Change chown to 755 here, though. Read 'man chown' to get
an idea of what that does.

Find is a powerful tool, but it takes some getting used to. I've
certianly shot myself in the foot a number of times with it.

Another concept that I've brought up through the find examples above is
that of 'regular expressions.' If you've been around a commandline of
any sort, you've probably come across the * character, which stands for
'glob'. Basically, this means match anything.

Want to show all of the word documents in a given directory? Use ls
*.doc. Over the weekend I was scanning a bunch of images, doing minor
modifications to them in Photoshop, saving them as .psd, then using
photoshop to make a low-res .jpg version of them to put on my website.
I created a simple Photoshop action to help me with this, but it dumped
all of the images into the same directory. I find it kind of a pain to
sort through .psd and .jpg, because sometimes my itchy mouse finger
picks the wrong one when uploading images.

I always keep a 'temporary' folder in my home directory. It's ~/tmp,
and I use it in times like this. I can easily dump files in there, and
I know that it's safe to nuke them. So, I can do the following:
cd ~/Documents/images/tickets
mv *.jpg ~/tmp
Then I can go through them when I do the upload.

I haven't really gotten into chaining tools together, or using other
tools to do things. But, this is a good start. Good luck!

[Matthew Barger]

On Sep 19, 2004, at 11:28 PM, Merlin Mann wrote:

> Looks incredibly flexible, but quite a learning curve. I'll pick up the
> O'Reilly book I guess, and start whacking my way around.

FYI, O'Reilly has a new edition of "Learning Emacs" slated for release
this December.

http://www.oreilly.com/catalog/gnu3/

-Matt Barger

[Jeff Youngstrom]

Tim wrote some great stuff about basic command line stuff, but before
people get really really confused I wanted to point out that here:

> find /path/to/dir -type f -exec chown 644 {} \;
>
> We're going to go and find all of the files, and change the
> permissions. Likewise, changing -type f to -type d to find the
> directories. Change chown to 755 here, though. Read 'man chown' to get
> an idea of what that does.

everywhere Tim said "chown" he meant to say "chmod". chown changes
ownership, chmod changes "mode" or permissions.

Another tool that works really nicely with find(1) is xargs(1). You
could rewrite the find command above like this with xargs:

find /path/to/dir -type f -print | xargs chmod 644

xargs will gang up a bunch of files from the find command onto a
single chmod command line which makes it a bit faster than the -exec
version.

Note that either one of these methods is likely to choke on filenames
with spaces in them. In the -exec version you might have to put some
quotes around the {} to protect the spaces. In the xargs version
you'll have to learn the arguments to treat each line of input as a
single argument. man is definitely your friend.

I've got some unixy tutorials on my web page here:
http://tomecat.com/jeffy/tttt/
including one that will demystify that chmod command line a little
(explains the meaning of 644 vs. 755).

jeffy
bearded, long-haired unix weenie

[John S J Anderson]

On Sat, 18 Sep 2004 14:58:32 -0700, Merlin Mann <merli...@gmail.com> wrote:
>
> I'd actually *really* enjoy that perspective, John. I've only caught
> it from glances and it seems fascinating and totally useful to me.

My response to your "hacking GTD" post is up at
<http://genehack.org/2004/09/21#just-another-gtd-hacker>.

> I'm not sure I get your point about GUIs, though. They've arguably
> been the defining characteristic of the Mac experience for over 20
> years, and I doubt that'll change for most folks (including me)
> anytime soon.

See, that's what I talking about with the GUI vs. CLI thing -- even
though I'm using an iBook to write this response back to you, I'm not
having "the Mac experience". I'm having the Unix experience.

[Joseph Chilcote]

I think of the CLI as a way of reducing overhead on my Mac by crunching
real work, and leaving the video card to do important stuff like
watching movie trailers. For instance, copying files between various
locations connected over dubious speeds while dealing with the Finder's
stuporous shortcomings can cause several hundred simultaneous
headaches. Ok, Ok, I'll stop with the alliterations already... anyway,
here's my example:

1) Add Terminal's ability to create a filepath out of a drag-and-drop
to perl's ability to, well, do just about anything, and you have the
makings of a custom, background file copy over the WAN that won't force
you to stay logged in while it chugs away (see #2). For example, I
have a script that accepts input (in the form of a dragged-and-dropped
file or folder), and copies (using psync) files between the two.
There's also an option to syncronize, ie delete at the target end. I
have other, longer scripts that run over rsync/ssh for when you're not
on the LAN/WAN, but this one I use daily and often. To wit:

#!/usr/bin/perl -w
print "Drag your source to the Terminal Window and hit the Return
key\n";
$FILESOURCE = (<STDIN>);
chomp($FILESOURCE);
print "\nDrag your destination to the Terminal Window and hit the
Return key\n";
$FILEDEST = (<STDIN>);
chomp($FILEDEST);
print "\nDo you want to delete files on the Destination that are not on
the Source? [y/N]:";
$DELETE = (<STDIN>);
chomp($DELETE);
## THIS IS WHERE THE PSYNC STARTS ##
if($DELETE =~ "y") {
print "you've chosen to delete...\n";
system("time psync -dv $FILESOURCE $FILEDEST
2>~/Desktop/logged_errors");
}else{
print "you've chosen not to delete...\n";
system("time psync -v $FILESOURCE $FILEDEST
2>~/Desktop/logged_errors");
}

2) Run the above in a custom screen (type "man screen" for more
information on this nifty feature), and I can log off my work computer,
take a leisurely walk home, have dinner, watch Law & Order, log back
into my work computer via ssh, type screen -R, and see the progress of
the file copy.
psync can be found at http://www.dan.co.jp/cases/macosx/psync.html

-J

[John S J Anderson]

> (type "man screen" for more information on this nifty feature),

screen(1) just hard-core *rocks*. For those of you that haven't seen
it, it's the way people did tabbed terminal windows back in the Dark
Ages, before tabs were invented. It also gives you the utterly nifty
"start something running, connect to it later on a different machine"
feature that Joseph mentions. screen should be in everybody's CLI
toolbag, IMO.

[Edward Vielmetti]

screen++

One more vote for screen. Can't tell you the number of times I've
been saved by running something under screen when I have a flaky
network connection so that when the link inevitably drops I just
reconnect and pick back up where I started again.

(hey John)

Ed

--
Edward Vielmetti
317 S Division St, PMB 218
Ann Arbor, MI 48104
+1 734 276 5910

edward.v...@gmail.com
edward.v...@socialtext.com

[Leland]

Is screen something specific to the Mac? I'm a new Linux convert, and
I've picked up a ton of Unix tips by reading these posts -- thanks,
everyone, for the help. Anyway, I have no idea what this "screen" thing
is that you speak of, and it doesn't appear to be present on my
machine.

bash-2.05b$ man screen
No manual entry for screen
bash-2.05b$ screen --help
bash: screen: command not found

I think I'll go sulk for a while.

[Mando Escamilla]

It's a GNU thing. And it's hawt :).

http://www.gnu.org/software/screen/

Download. Install. Love.

--
Mando

[Art Taylor]

screen is a unix/curses app that has been around for ages, and what I
would consider The Most Important Unix Tool No One Knows About. You
should be able to use apt-get or whatever your platform's package
management system is to procure and install it. I've run it on Mac,
IRIX, Linux, and Solaris without problem.

It's commonly referred to as "gnu screen", so if nothing else you can
download it from a gnu mirror. See
http://www.gnu.org/software/screen/.

It's actually very good at abstracting a very clean vt100 terminal
emulator on whatever weird terminal you're using.

-a.

[nf0]

I use screen all the time also. I agree that its one of the best unknown
tools. At work I ssh into several linux servers everyday. I have a
..screenrc that I really like setup. It pulls up a could of bash terms in
tabs and a vi /etc/LOG. That way I never forget to note what changes I've
done on the servers. Since I'm consistant with the log and tools across
servers, I keep my .screenrc in CVS and keep them all updated with the
latest version. When I'm at work I stay connected to my powerbook at home
with ssh and have a even more complex .screenrc that I use there with
about 6 active tabs. When I get home I can pickup where I left off thanks
to screen. I also use it with my windows laptop at work under cygwin. I
can't say enough about the power and importance that screen has for me.

[Tim Conrad]

Oops. As someone pointed out, I did mean chmod in the example
previously mentioned.

As I previously mentioned, Unix is a group of tools that are designed
to be chained together. I'm going to give some examples that people
would find useful, as well as examples of more complex things that can
be easily done from the commandline. When trying new things out, it's
important that you don't do it as root, and it's always nice to have a
'sandbox' in my home directory to play with. Usually I use ~/tmp for
this. Simply COPY files you'd like to muck with to there, and have fun!

Probably two of the most common things you'll see in the Unix CLI is
that of a pipe, or |, and 'grep'. Piping commands can include
redirecting output somewhere, as we'll see. 'grep' is short for 'Global
Regular Expression Parser', which is short for 'find'. Although, 'grep'
is very powerful, more powerful than many 'find' implementations I've
seen.

The command 'ps' shows the processes that are running. The -aux flags
find all processes. We can pipe this to the 'more' command, which will
paginate the data based on your terminal breaks. So, at the prompt,
type 'ps -aux | more'. As you can see, you should get a page full of
data, whith a bytecount at the bottom. Simply press the spacebar to
continue through the listing. (As an alternative, try 'less'. How is it
different? Sometimes, more isn't less.:) )

As an example, consider that you have installed PostgreSQL on your
machine, which is a database server. You think it's running, but you're
not quite sure. How can you check? With the 'ps' command, of course!
We'll pipe the output of ps to grep to find the 'postgres' user, or
anything with 'postgres' in it. Use 'ps -aux | grep postgres'. You
should get a nice output of stuff with postgres.

The ps output can be used for troubleshooting purposes as well. Each of
the columns has information that is useful. For performance reasons,
the %CPU, %MEM and TIME columns are important. The PID column is
important if you want to kill a process, or do some other things for
it. Use 'man ps' for more information on this subject.

There are also some simple tools that I use. I know there are
alternatives for these, but these are easy for me to get to. 'bc' is a
simple calculator. 'cal' will show a calendar of the current month.
'date' shows the current date and time. Not sure what a file is? Use
'file filename'. Displaying the contents of a file? Use 'cat' for
nonstop display, 'more' or 'less' for a paginated display. I'm sure
there are more, but these are ones I use on a regular basis.

A task that I end up doing from time to time is trying to figure out
how many lines there are in a certian document. 'wc' is a command that
can help you do this. So, use 'cat filename | wc -l' to count the lines
in filename. Want to see how many processes are running on your system?
'ps -aux | wc -l'. Want to see how many times the word 'passed' is on a
line in a document? 'cat filename | grep passed | wc -l'.

If you poke around with CLI's very much, you'll eventually get to 'sed'
and 'awk'. Each of these are super-powerful command parsers that have
many many features.However, there are two fairly basic things that I do
with each on a regular basis.

First, with awk, it's really easy to print out a column of data. From
the previous paragraph where I was finding certian processes running. I
mentioned the PID column. As an example, say you want to print just
that column, along with the process.Using 'ps -aux | grep postgres |
awk '{print $2 $11}' ' will do this. The $2 and $11 are split off by
whitespace, so your milage may vary. However, you can easily change the
$2 to $1 to display the first whitespace column of data. This will work
on virtually any file.

Second, sed can be used to do find and replace in files. Where this
gets hairy is that the 'find' portion of this string can be a regular
expression, so it can be very complex to match very specific things in
a file. Regular Expressions are literally a programming language in
themselves, and take a lot of practice to get good at them. But, that
shouldn't stop us from trying. I have a log file from something that
has a bunch of lines with 'passed' in them. I want to change them to
failed. Use 'cat filename | sed -e 's/passed/failed/g' ' to do this.
You should immediatly see an output from this with your changed
strings.

>From any of these commands, if you want to save output to a file for
printing or for emailing to someone or whatever, use 'command >
file.txt'. after that, you'll get everything in the file.

Okay, now for the most complex part of this. Sometimes I have problems
with my cablemodem at home, and I'd like to keep track how long it
takes for pings to return from a certian host. I don't want to do these
forever, just a few pings every so often. Fortunatly, there's the
'cron' facility, which will allow you to schedule tasks at given
intravels. So, I'm going to schedule a ping every 5 minutes.

Type 'crontab -e' and enter in the following line. Of course, edit the
Ip address you'd like to ping:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /sbin/ping -c 3 -s <somehost>
| grep icmp > /tmp/pinglog.txt

Exit out of your text editor, and it should activate the crontab. Wait
until the next period, and look at /tmp/pinglog.txt. Of course, you
might not want to do it all the time. Maybe just during work hours. Or
maybe weekends. Use 'man 5 cron' to find out. The 5 is important.

As a brief aside, man pages are broken up into sections. One section is
for programmers, one section is for commands, and so on. There's two
'cron' sections. Use 'man cron' and then 'man 5 cron' to display the
different sections.

Next, I'll do a 'good CLI tools to have installed' section as well as a
'slightly more advanced' troubleshooting guide.

[John S J Anderson]

> A task that I end up doing from time to time is trying to figure out
> how many lines there are in a certian document. 'wc' is a command that
> can help you do this. So, use 'cat filename | wc -l' to count the lines
> in filename. Want to see how many processes are running on your system?
> 'ps -aux | wc -l'. Want to see how many times the word 'passed' is on a
> line in a document? 'cat filename | grep passed | wc -l'.

Why the useless use of 'cat'? Is there something wrong with 'wc -l
filename' or 'grep passed filename | wc -l' (or even 'grep -c passed
filename'?)

(Sorry, I think you might be triggering a pet peeve...)

[Charles Starrett]

I'm surprised. My understanding is that screen is pretty standard to
all UNIXes. Perhaps if you post what particular distribution/version
you're running, a Linux guru here could help you. (That wouldn't be
me...)

[John S J Anderson]

It'll run on anything Linux, but most distributions don't seem to
install it by default. Hunt around in your package manager; you're
looking for a package called 'screen' or 'gnu-screen'.

[joe.m...@gmail.com]

screen should be happily available for your machine. Fret not.

[Matthew Freeman]

Screen made me the most productive geek I've been in years. All hail
the almighty power of screen!

~ Matt

[Andy J. W. Affleck]

How so?

I keep lookinng at this and thinking that it's pretty cool but with
multiple terminal windows (even when I remotely connect to another
box) I'm not seeing what it can do for me.

'splain?

-A

[eric Farris]

On Wed, 24 Nov 2004 08:27:49 -0500, Andy J. W. Affleck
<aaff...@gmail.com> wrote:
>
> How so?
>
> I keep lookinng at this and thinking that it's pretty cool but with
> multiple terminal windows (even when I remotely connect to another
> box) I'm not seeing what it can do for me.
>
> 'splain?
>
> -A

If you only use it for disconnecting at one remote place and picking
it up at another, it's worth it. I have several servers with screen
sessions on that i can pick up from my office, from the console, if i
have downtime in a client's office, etc. One of the machines running
screen is my main desktop, which allows me to work just like i'm at my
desk. one of the screen virtual sessions is mutt, there are some
tail-ing of logs, and so forth. In fact, all my saved terminal
sessions now do a 'screen -D -R' as the default command. it's just
really really cool. There's even 'split screen' wonderfulness, but i'm
not that advanced.

Where it's better than a bunch of terminal windows is:
- less screen, er, um, desktop, clutter
- no need to stop what you're doing, or to open another window, to
get another shell, just C-A C
- remotely connect to an already running session <- the 'big one' for me

I have my .screenrc automatically start 10 sessions, print the footer
so i know which virtual screen i'm using, along with the name of the
machine and the time. It's great; the single best tool i've found in
my seven years or so of messing around with *nixes. (no, maybe that's
mutt, no, it could be vim, no, it's probably perl...)

--
e

[Adam Rice]

I knew screen was powerful, but I hadn't looked into the footer
feature, which would make it a pleasure to use. Care to share your
.screenrc or at least the relevant bits?

Adam

[Michael Grant]

On Nov 24, 2004, at 7:27 AM, Andy J. W. Affleck wrote:

> I keep lookinng at this and thinking that it's pretty cool but with
> multiple terminal windows (even when I remotely connect to another
> box) I'm not seeing what it can do for me.
>
> 'splain?

What comes to mind for me is having a man page open in one window while
working in the other.

Michael

--
<http://globalocal.blogspot.com/>

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

[Andy J. W. Affleck]

Sold!

I, too, would like to see your .screenrc...

-A

[eric Farris]

On Wed, 24 Nov 2004 10:29:52 -0500, Andy J. W. Affleck
<aaff...@gmail.com> wrote:
>
> Sold!
>
> I, too, would like to see your .screenrc...
>
> -A
>

Pasted below. It's pretty much the same for every box that I administrate.
---Begin Pasted Text---
startup_message off
shelltitle '$ |bash'
caption always '%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%H %D %d%M%Y %c'
screen 1
screen 2
screen 3
screen 4
screen 5
screen 6
screen 7
screen 8
screen 9
screen 0
---End Pasted Text---

startup_message off gets rid of the banner screen when screen starts.

shelltitle is a cool idea, but right now it only works in linux: it's
supposed to change the name of the screen to either 'bash' (which is
my shell) or the name of the running process. I think it's not working
in OSX right now because there are some incantations I need to add to
the PROMPT variable in my .bashrc which I've not yet done on my Macs.
When it works, it's really cool: if I'm doing a "tail -f
/var/log/apache/access.log | ccze" or similar, the title of the screen
would be "tail." If I'm in a mysql session, it would be "mysql."
sweet, especially when paired with caption always.

The clincher is the caption always one. The man page will help you
decipher the gobbledygook, but what it does is create something
similar to the following on the last line of the display:

0 bash >1 mutt< 2 bash 3 tail (and so on until) 9 bash hostname date time

where the stuff in > < is in reverse video, and is the currently
active screen, hostname is the name of the box (because I'm usually
ssh'ed into three or so, so it reminds me where i am), then the date
and time, just because I can. Sometimes it's just fun to see how many
clocks I can have on one screen at one time.

The rest of the stuff goes ahead and starts 10 sessions for me. Note
that this will start 10 bash processes, so it's a bit hungry, lean
machines might not want to bother. But this gives me ample room to
play. It's not too uncommon for me to be using six or seven of those:
checking man pages, doing a large rsync, tailing a few logs, and so
on. It really does fill up quickly.

Nothing too spectactular. Again, see the man pages, particularly the
section on "STRING ESCAPES" to see what goodness can go into the
caption. mmm. powerful.

--
e

[Andy J. W. Affleck]

This, coupled with the great article at O'Reilly
(http://www.macdevcenter.com/pub/a/mac/2004/07/06/unix_gems.html --
check out Remind as a way to also work with lists of hard landscape
tasks) has got me going and I am hooked. I never realized the power of
being able to launch terminal and be right where I was last time I
used it. All the commands I was last using, still there, the output
all still there. I don't have to remember what I was doing. Perfect,
just perfect.

Thanks!

-A