PLAYterm: a New Way To Improve Command Line Skills

chrb writes "Linux Journal points out PLAYterm, an interesting project that offers up recordings of Linux command line sessions, with the aim of helping viewers to improve their skills by watching gurus at work." And there's no bad excuse to link to Neal Stephenson's excellent (and free-to-download in delicious zipped-text form) In the Beginning was the Command Line.

Comments

CLI fetish

[sourcerror]

I never quite got this command line fetish (and I mean here bash). You're supposed to to simple things in the commandline, if you need something more complicated then use a proper scripting language like Python or Perl. And people shared Python/Perl snippets from the beginning of time.

Re:CLI fetish

[Nursie]

Python wasn't around at the beginning of time. Perl I'm not so sure about. Also, the users of both languages would probably get annoyed at them being called scripting languages. That's just one thing you can do with them.

Add on top of that that scripting in bash or csh is very powerful, and that you can get a lot of things done in a one liner if you know what you're doing...

It's hard to see how you could be more wrong!

Re:CLI fetish

[SuricouRaven]

The server room at my workplace has a temperature alert program written in perl. I've also made an IRC bot in perl. It does character descriptions and die rolls for a roleplay channel.

Re:CLI fetish

[Gordonjcp]

Perl and Python have both been around since the late 80s, with Perl being a year or two older. In terms of Linux, they have indeed both been around since the dawn of time.

Re:CLI fetish

[Gordonjcp]

Sorry, to reply to my own post, I hit submit instead of preview.

They've both been around about as long as bash. They all originate in the late 80s/early 90s. According to wikipedia (I don't remember this far back) csh dates from the late 70s.

Re:CLI fetish

[tepples]

You're supposed to to simple things in the commandline, if you need something more complicated then use a proper scripting language like Python or Perl.

Provided that a user already has Python or Perl installed on their PC. There are a lot of users for whom that is not the case, such as people running the scripts that set up Python or Perl on a system.

Re:CLI fetish

[Anonymous Coward]

CLI = interactive, perl and python are not particularly well adapted to interactive use. And neither perl nor python was around at "the beginning of [UNIX] time", dating from 1987 and 1991 respectively. Perhaps you meant awk? That's a decade closer, published in 1977, but still pretty late. Before that, bourne shell was really the only general purpose scripting language widely available, and as a result grew the capabilites needed to fill that role well.

Re:CLI fetish

[bobstreo]

Yeah python and perl on tty's and vt100s.

How simple are you supposed to be on the command line?

Oh python isn't installed on this machine.

  I can get this perl script to work, I just need to add a couple things from cpan (recurse until it actually works)

Re:CLI fetish

[JaredOfEuropa]

Doing complicated things is often easier and more straightforward in scripting languages than it is on the command line. You might be able to do it faster on the command line if you're clever. Perhaps the real advantage of the CLI however is not that clever people can accomplish things faster there, but it gives them a chance to show us how clever they are. As you say, people usually just share Python snippets, but they show off their CLI scripts with pride.

Re:CLI fetish

[Anonymous Coward]

It's incredible that you thought this was relevant to the topic at hand.

Re:CLI fetish

[drinkypoo]

If you don't understand the bourne shell (bash, indeed!) then you are boned when you are trying to diagnose boot on some antique Unix system. Since virtually all Unix systems depend heavily on the Bourne or Korn shell you need to know Bourne which will tell you all you need to know, in practice, to troubleshoot the Korn shell scripts actually created by vendors.
You can't call yourself a Unix geek without understanding the Bourne shell, at least tolerably well.

Re:CLI fetish

[Anonymous Coward]

Python is very well adapted for interactive use.

Re:CLI fetish

[Anonymous Coward]

$ ls

vs

>>> import os
>>> os.system("ls")

No, it's not.

Re:CLI fetish

[Anonymous Coward]

i concur. what a tool. there's no denying bash's usefulness

Re:CLI fetish

[martin-boundary]

bash is a lot more powerful than python or perl, for small and medium complexity tasks. It is certainly better at interactive uses, and it is much better at piping than either of those languages.

Use python or perl for complex tasks by all means, but they are a poor substitute for what the shell is good for.

Re:CLI fetish

[Anonymous Coward]

You should have made that: ls=os.system("ls") if you're going to be using it interactively. No wonder you cling to bash still.

Re:CLI fetish

[DarkOx]

Well, I don't see what would be *wrong* about using interactive python as your shell, if you like it. I think the point though is a good shell and solid set know how with it, makes complex things simple.

I should not need big heavy script interpreter to apply the same transform to names of files for instance. Even operations like find all the members of group A and group B and add them to group C, are simple enough that I would hope to be able to express that in a single line or two of shell code.

Re:CLI fetish

[superdude72]

Well, let's say you want to look up the process ID of the Bluefish editor you have running. You could write a perl script:

#!/usr/bin/perl
open(IN,"ps -ef |");
while (<IN>) {
        if (/bluefish/) {
                if (/^.*?\s(\d+)\s/) {
                        print "$1\n";
                }
        }
}

Or you could type from the CLI:
ps -ef | grep bluefish | grep -v grep | awk '{ print $2 }'

Which is more straightforward?

And I even cheated a little, by putting a bash system call in the perl script. I suppose there's a pure-perl way to get the process table, but why bother when I know what I want is ps?

Also, the mid-90s (for Perl) and early-2000s (for Python) is hardly the "beginning of time." (I know both languages have been around longer, but those are approximately the periods that each language began being used in production environments.) Please don't say that. I was doing stuff in Unix well before perl was considered anything but a toy language, and I'm only in my mid-30s! And that's not old, damn it!

Re:CLI fetish

[Anonymous Coward]

or in any way impressive in a discussion surely full of sysadmins

Re:CLI fetish

[Anonymous Coward]

Or you could type from the CLI:
ps -ef | grep bluefish | grep -v grep | awk '{ print $2 }'

Which is more straightforward?

ps ... | awk '/bluefish/ {print $2}'

You did ask, right?

As an aside, there's almost no reason to ever use a construct like 'grep .. grep -v grep'. So stop doing it.

Re:CLI fetish

[Hatta]

How would you get rid of the 'grep bluefish' entry in the process list then?

Re:CLI fetish

[martyros]

Perl was designed for text processing, and at that it excels. Bash was designed for starting and managing sequences of other commands, and at that it excels. Both languages are actually capable of doing the other; but in Perl, executing other programs and keeping track of them is a bit clunky and requires a lot of extra verbiage, and in Bash, doing string parsing is really clunky and requires a lot of extra verbiage.

Moral of the story: choose the right tool for the job.

Re:CLI fetish

[Anonymous Coward]

I was going to write something clever, but ultimately the only thing I could come up with was "Do you expect anything else from your average Slashdot reader?"

Re:CLI fetish

[DrgnDancer]

He's using awk to find the string 'bluefish' and eliminating the greps entirely (the capabilities of awk are a superset of the capabilities of grep), but I don't know how he's eliminating the "awk '/bluefish/ {print $2}'" entry in the process list. I suspect he didn't think about it in his attempts to look 1337. You could probably design an awk regex that would eliminate the awk process from the output, but in the end I think the GGP's is simpler.

Re:CLI fetish

[Anonymous Coward]

I believe PowerShell was the first.

Re:CLI fetish

[Shoe Puppet]

That would assign the result of os.system("ls") to the variable called ls. The closest thing would be:

>>> import os
>>> def ls(): os.system("ls")

>>> ls()

Re:CLI fetish

[lahvak]

It depends what you are trying to do. If you want to do things like manipulate the filesystem or directly interact with the OS, for example start bunch pr processes, string them together in some way, like create a pipe, etc, you are much better of using a proper shell. If you need to actually generate and manipulate significant amount of data, you want to use perl, lisp, python, slang, octave or whatever fits the type of data you have best.

This also has nothing to do with CLI. You can write script in any of these languages, and most of them can be used from a command line.

Re:CLI fetish

[excitedidiot]

Perl WAS around at the beginning of time. http://xkcd.com/224/

Re:CLI fetish

[Nimey]

Scripting in csh is Considered Harmful and you shouldn't do it. It's really only good for interactive use.

Re:CLI fetish

[hedwards]

It is, but you can go a long with with grep, sed and awk. I don't look fondly on the days before I learned that I could use those three commands to mostly eliminate the time I spent looking through results and trying to compare strings when I could just use those thrown together with md5 and cmp to compare the checksums for me.

Re:CLI fetish

[Anonymous Coward]

pgrep bluefish

Re:CLI fetish

[Requiem18th]

Also, the users of both languages would probably get annoyed at them being called scripting languages.

Well, I don't. I use Python for both applications and small scripts. I find bash and sh weird with its if-fi case-esac things and have troubles remembering all its rules and how-tos. I already know Python, I don't need to learn sh. Even Perl is easier to grep than sh.

Obviously I can read enough sh to know to look for things like `sudo rm -R /` but not enough to write complex scripts by my own.

Re:CLI fetish

[tele]

Why use grep (twice) if you call awk at the end anyway?

ps -ef |awk '/[b]luefish/ { print $2 }'

And to get back to the topic at hand: Even if your unix/linux box is hardly booting any longer due to severe issues, at least /bin/sh will be available (while python, perl and all the other fancy stuff may already be gone).

Re:CLI fetish

[superdude72]

Why use grep (twice) if you call awk at the end anyway?

Because I have no idea why /[b]luefish/ doesn't match the "awk" line in the process list while /bluefish/ does?

Re:CLI fetish

[Anonymous Coward]

Tell that to my university. The default menu system for shell access to the big mail servers is scripted out in csh. Just looking at the code makes my eyes bleed; I was able to write an equivalent in bourne shell (/bin/sh) in about five minutes.

Re:CLI fetish

[Anonymous Coward]

He was talking about the power of perl vs. python/bash/csh.

Clearer now?

Re:CLI fetish

[PwnzerDragoon]

-f causes ps to print the full command lines. /[b]luefish/ will match "bluefish" but not "awk /[b]luefish/", because the [] characters are regex operators and are not part of the string that gets searched for.

Re:CLI fetish

[Urkki]

I never quite got this command line fetish (and I mean here bash). You're supposed to to simple things in the commandline, if you need something more complicated then use a proper scripting language like Python or Perl. And people shared Python/Perl snippets from the beginning of time.

The thing with command line, doing the "more complicated" thing is often just adding an extra switch to relevant command, or adding an extra command to a pipe, or something. And it's no co-incidence that the command usually have the switches needed to do whatever "more complicated" thing needs to be done.

But I guess the most obvious proof of the value of bash and the like is, at least I don't know anybody who uses Perl or Python as their shell interpreter. There must be some reason for it. And if bash is good enough for doing whatever one-liners interactively, then putting a series of already-tried one-liners into a shell script follows quite naturally, and sounds more sensible than re-writing the thing they do in an entirely different scripting language.

Re:CLI fetish

[superdude72]

/[b]luefish/ will match "bluefish" but not "awk /[b]luefish/"

Aha.

Re:CLI fetish

[dougmc]

What I don't get is why are people using "bash" as if it was synonymous with "the command line" ?

It's not.

We've had command lines for far longer than we had bash, the Bourne shell or even *nix. And even after bash was created, even on *nix systems -- people use other shells other than bash. csh, sh, zsh, tcsh, and lots of even more obscure ones.

And of course, most OSs have had a command line. *nix and it's shells just make it that much more powerful and flexible than most of what's available on other OSs, though from what I've heard, Windows PowerShell sounds pretty amazing.

Re:CLI fetish

[Anonymous Coward]

Or you could type from the CLI:
ps -ef | grep bluefish | grep -v grep | awk '{ print $2 }'

Which is more straightforward?

ps ... | awk '/bluefish/ {print $2}'

You did ask, right?

As an aside, there's almost no reason to ever use a construct like 'grep .. grep -v grep'. So stop doing it.

If you're going to advocate not using a "grep foo |grep -v grep", you should give an example that is correct, like

ps -ef | awk '/[b]luefish/ {print $2}'

Instead of what you wrote, which gives a redundant awk process instead of a redundant grep process.

Re:CLI fetish

[johnmorganjr]

I learned the bash shell and some korn shell many years ago. Then I discovered perl and how powerful and really helpful it is in sys administration. Most things can be done with perl, especially text editing. I believe perl makes sed and awk obsolete. No offense to any one that uses sed and awk they are both powerful but not as versatile as perl.

Re:CLI fetish

[Onymous Coward]

psh (Perl shell) sounded like a good idea. Never looked into it, though. Wonder what happened to it.

Re:CLI fetish

[Onymous Coward]

... but I don't know how he's eliminating the "awk '/bluefish/ {print $2}'" entry in the process list

ps without -f does not show the full command line — you won't see the args to awk.

Re:CLI fetish

[Anonymous Coward]

Since he didn't point out that he couldn't write those utilities in python or bash (which would be bogus) or that they would be harder to implement (possibly true, but specifics would be needed), it's a pretty useless way of talking about that.

Also, csh sucks for programming. Everyone knows this, everyone accepts this, and even the people who still use tcsh as an interactive shell wouldn't use it for those examples, so not sure why anyone bothered to bring it up. I used to use tcsh, but these day I just use bask or pdksh -- all the innovative features of csh have been adopted in one form or another by every other major shell.

Re:CLI fetish

[lee1]

If you're going to use python as a shell you don't use the simple interpreter, in which you will have to do all that. You use ipython, especially in its system shell mode. Then you just need to type this:

ls

All the power of python in your command line! You just don't get job control, because you're one layer up, running on bash or whatever. Perhaps some day someone will create a real python shell; that would be even greater.

Re:CLI fetish

[Onymous Coward]

"More Powerful than" and "better at" here mean "lend themselves conveniently to such tasks in the given context (of the command line)".

Yes, for file handling, launching commands, and for simple inter-process communication shells — all shells, not just bash — are far more convenient than Python or Perl.

Re:CLI fetish

[Anonymous Coward]

I looked at this with some interest... until I realised that 'ls' is a special case, and any other command will need ! escaping each time you use. Looks a lot more clunky than a normal shell in that light - too painful for day-to-day use in which 90% of what is typed is a single command A B C, or a simple pipe A B C | a b c | x y z.

Re:CLI fetish

[justforgetme]

well..... .... ....
Bash is an interpreter just like all the other ones you {"mentioned","didn't mention"}. They only difference I can tell about interpreters is that they have `some` different keywords and some command structures might differentiate but in general they all represent the same thing, a line input to throw commands at an OS and some space to visually retrieve the impact of what you did (think `rm -v- r -f /`).

So there really isn't a big deal when people treat cli as a synonym for bash because, functionally, there isn't a huge difference. From a historic standpoint sure but we are not debating the evolution of OSs do we?

Re:CLI fetish

[justforgetme]

Bash is (conveniently supporting the story's title) more of a play thing than a power tool imho. Sure as a sysadmin you might do a hell of a lot of work in it, on it or through it, but its quirky command structures and compactness really make me perceive it more as a toy than a tool. Normal programing languages (C, C#, java, py... NOT haskell/lisp) are very straight forward as far as a well documented/structured source goes but CLIs have that very interesting part of being line oriented in their program structures.

Opening up a bash script to see how it ticks is much more an adventure (decrypt all the loaded one liners) than a boring code review in an IDE (take a peek at the functions you are interested in).

Also CLIs are very very immediate in their responses, which means you can see your nifty, godlike command wreaking havoc on your system immediately after you pressed Enter. Of course when examining your history you will find out that that grep loop grepped much more than you originally expected (thank you perl). This leads you to respect (actually: fear) the CLI. Of course your unending curiosity (ie what happens if I `dd if=/dev/rand of=/dev/speaker` ) will keep driving you towards it. In the long term the fear and agony will fade and be replaced with the endorphins that flood your bloodstream once that godlike command actually does something that it was supposed to do. Make sense?

Actually CLIs are just like a BDSM session with Jigsaw they are a lot of pain and you most probably will self mutilate and die; but there is a small chance you might live and have a long live filled with mind therapy and night terrors. So yes, CLIs do have the qualities to become fetishes. :-)

On another note: that playback thing needs some better controls/UI, clicking on the progress line doesn't do anything and when you pause to copy something that huge play button hides everything...

Re:CLI fetish

[garaged]

People like you are the reason us sysadmins make a living

Thanks a lot o/

Re:CLI fetish

[garaged]

I have made bash scripts that took me maybe in sum 2 hours and reached a point where they made the job let's say in 90 seconds, then migrated it to perl in somethin like 8 hours and made the job in 15 seconds

In my experience it is good to know both kinds of scripting

Re:CLI fetish

[lee1]

'ls' is a special case, and any other command will need ! escaping

Not true. Commands that conflict with python names need escaping; others can be typed just as in a normal shell.

Re:CLI fetish

[justforgetme]

I think you are replying to the wrong post.
Otherwise your reply would be just nonsensical and unfounded.

Re:CLI fetish

[chmod a x mojo]

"pidof bluefish" is probably the simplest of the simple for BASH.

Now lets say you wanted to KILL that process with fire ( and you only have one / want to kill them all )

kill -9 `pidof bluefish`

VS

Some long string of perl that looks like you sat on your keyboard.

Re:CLI fetish

[sir_hawell]

or killall -9 bluefish

Re:CLI fetish

[PoopCat]

Or pkill -9 bluefish

"guru" unix command line users - watch and learn?

[ardiri]

guru "unix" command line users know pretty much exactly what they are doing and mostly escape extend their commands and type like there is no tomorrow - you would have to play back these videos in slow motion to really learn from them, command typed, enter pressed, pages of stdout scroll by. nice reference point for learners. the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely. try doing stuff from your tty terminals and disable x11 :) learn to do word processing with latex, telnet into your routers to configure them. if your not up for doing that, forget about using the command line tools. back in the early 90's, we couldn't afford RAM to even start x11 :) i personally use cygwin on windows and terminal on macosx for as much as i can.. never know when you need those command line skills again

"Command Line" is obsolete, says Stephenson

[Anonymous Coward]

According to wikipedia, Stephenson said the following in 2004, right here on /. : "I embraced OS X as soon as it was available and have never looked back. So a lot of In the Beginning...was the Command Line is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."

Here's the article

Re:"Command Line" is obsolete, says Stephenson

[BrokenHalo]

According to wikipedia, Stephenson said the following in 2004, right here on /. : "I embraced OS X as soon as it was available and have never looked back.

Well, to be fair, OS X has all the advantages of any other *nix, while also having a GUI that (while inflexible) is pretty much OK. Until recently I had a MacBook as well as my Linux-based desktop machines, and I used the CLI on it fairly extensively. In fact, Apple sort of seems to anticipate this by including zsh, ksh and csh in addition to bash by default.

Re:"Command Line" is obsolete, says Stephenson

[Hatta]

OS X has a command line. It's a lot more usable than the finder.

Re:"Command Line" is obsolete, says Stephenson

[hedwards]

As a general rule, I tend to say that anybody that says that you can use an OS without the CLI is either fooling themselves, limited to a small number of tasks or has the most bloated OS ever. Even Windows has certain things like renewing the IP address that are a lot quicker from the command line.

Re:"Command Line" is obsolete, says Stephenson

[CharlyFoxtrot]

You realize that OS X is a certified Unix ?

Re:"guru" unix command line users - watch and lear

[tepples]

learn to do word processing with latex

For live preview, you'll need LyX and that needs X11.

telnet into your routers to configure them

Which for some users would require them to buy a router supporting telnet, as opposed to a home gateway appliance supporting only HTTP.

I feel the knowledge seeping into my head already

[Anonymous Coward]

kn0r tmp # how to ssh?
kn0r tmp # ssh yourusername@someserver.com
^C
kn0r tmp # ..ok that does not exists..but that is the way to do it.

If only there were a standard file format for textual content.

Fetish?

[zarlino]

It's very simple. With CLI you do stuff that cannot be done (easily) with a GUI. Ever used rsync, grep, find or sed? If not, you probably don't really *work* with computers.

Re:Fetish?

[Anonymous Coward]

Nice try - go and lurk on some mainframe forums for an education. *nix isn't the only operating system out there, you know.

Re:Fetish?

[DarwinSurvivor]

Windows user right? You would have to be since that is just about the only OS that doesn't have those 4 commands either pre-installed or 1 command away from being installed (I know about cygwin, but few windows users do). I've seen college industry projects that took the group 3 months to build (the client specified writing in C) that could have been accomplished with 3 unix commands in a 10 line shell script written in 5 minutes.

What the OP meant was that if you are doing rsync/grep/find/sed stuff via a GUI it's as much "using" a computer as taking the bus is "driving". Here's an example, if you wanted to delete all the Thumbs.db files from a directory (recursively of course) in windows, you would have to:

1) Open search
2) specify that you are searching for files & folders
3) specify the directory in the directory field
4) specify "Thumbs.db" in the name field
5) hit search
6) quickly scan the list to ensure nothing else got hit (ex: PaintedThumbs.dbrain.jpg)
7) Select all (advanced users will click one and hit CTRL+A
8) hit delete
9) close the search window

in linux you
1) open terminal
2) "find _directory_ -name Thumbs.db --exec rm {} \; ; exit"
3) hit enter

Now you tell me which is easier to do...

Re:Fetish?

[Dr_Barnowl]

Such a common usage, that find has an option to make it even easier...

find _directory_ -name Thumbs.db -delete

Re:Fetish?

[Rhodri Mawr]

I'm no M$ apologist, but have you heard of Windows PowerShell?

http://technet.microsoft.com/en-us/scriptcenter/dd742419

Re:Fetish?

[Anonymous Coward]

Oh, you mean the CLI functionality MS recently added after spending years attacking things like terminals and CLI used in Open Source operating systems? It was bullshit FUD one day, a 'feature' the next day.

Re:Fetish?

[Anonymous Coward]

Are you kidding? The GUI way is easier. Obviously so. The CLI way may be more concise, faster even if you know the exact syntax by heart, but certainly not easier.

The primary problem of the CLI is the lack of clues as to what you can do. That there is a command called find may be considered intuitive. How to search for files with a given name using the find command is not intuitive: Is the order of the arguments relevant? Is the name a parameter or a named option? Does -name take a regular expression or will it match verbatim or is it something else? Then there's the matter of running a second command on the output of the first. Is that another option or do you pipe the output to the next program? What's a pipe? Etc.

Re:Fetish?

[tmcb]

It is important to remember that CLIs were the oldest way to interact with a computer system of both. It was made by programmers, to programmers. But, still today, they prefer to have a concise and consistent way of accomplishing their tasks. Guessing positions in an Euclidean plane based on less-than-descriptive tips contained on pictograms and labels isn't something we can call "concise" and "consistent".

Re:Fetish?

[Anonymous Coward]

It depends on what definition of easy you use. Something that's hard to learn may end up to be easier to use in the long run. Intuitive user interfaces are relatively easy to learn for a beginner, but may not be the best option for a power user who's willing to spend time and energy learning useful skills. Different people have different needs. Something is easy or difficult for someone. The lack of power of many more intuitive user interfaces makes using them difficult for people who are able and willing to learn and understand a bit more.

To speak for myself, I found I was using a terminal window more and more, gradually stopped using the file manager that came with my desktop system, started GUI applications from the bash prompt more and more, and found that all those mouse oriented overlapping windows and other desktopy things got more and more in my way, so now I use a tiling window manager (with lots of things for which you need to learn keyboard shortcuts that don't explain themselves) and the bash prompt to do all my work. This setup is the easiest to use that I ever had. For me. Not for everyone.

Re:Fetish?

[grumbel]

The biggest problem with complaining about GUI is that none of the problems are really GUI specific, they are specific to bad GUI implementations. Searching for files for example has been getting worse and worse with every Windows version, back in Windows95 days on the other side it was great:

1) Hit F3 to launch the search dialog (no need to specify directory, as that comes from the folder you are currently in)
2) Type search pattern (limit by date, filesize, filecontent if you like)
3) Start search
4) Observe the results and do something with them (delete, copy, etc.)

It was faster and more comfortable then 'find' as it gave you visual confirmation of what it was doing and gave you the option to subselect and sort the result. Shell is only easy when everything fits into computer readable patterns, if you ever wanna delete some photos and want to have a visual thumbnail confirmation that those are the right ones, classic shell isn't all to much helpful.Equally it is all that helpful if you only want to toy around with some files in the results, not all of them. And that shell only gives you text, not data, also leads to a lot of problems (i.e. half the shell scripts you find will explode when somebody put a newline in filename), a GUI doesn't have those problems, of course a more modern shell won't either, but those aren't exactly part of the classic Unix toolbox.

The tragic part of this whole depate is that it is really missing the point, Shell and GUIs are not opposites, they are both part of the same interface and there is absolutely no reason (aside from messy historic ones) why they shouldn't be able to work together. "ls" for example should give me a list of files that I can click and move around like everything my file browser would show and equally whenever there is a textbox or listbox in my GUI I should be able to grep and awk on it. Yet no modern GUI really tries to bother with that stuff, they are all stuck in the mindset that command line is evil and not worth bothering with. While command line people get all agressive when somebody mentioned that the world has evolved in the last 30 years and serial terminals are no longer state of the art.

Re:Fetish?

[Anonymous Coward]

Eat shit, lamer

Re:Fetish?

[Anonymous Coward]

Windows user right? You would have to be since that is just about the only OS that doesn't have those 4 commands either pre-installed or 1 command away from being installed (I know about cygwin, but few windows users do).

GP was talking about mainframe forums. The mainframes I used to work on didn't run Windows, and didn't have those 4 commands (although I suppose they would be available through unix system services or linux nowadays).

Re:Fetish?

[Man Eating Duck]

It's very simple. With CLI you do stuff that cannot be done (easily) with a GUI. Ever used rsync, grep, find or sed? If not, you probably don't really *work* with computers.

Our central IT department migrated our file storage area to a new server a while ago. After the operation the whole thing was a mess, with missing and misplaced files all over the place. I called them up, wondering how on earth they'd managed to screw it up, and it turned out that the guy had done it with several drag'n'drop operations which he'd fucked up in numerous ways. Several operations due to the fact that some files caused an error because they were in use at the time. I was flabbergasted and asked why on earth he didn't use a proper tool like rsync. "What's sync? Command line you say? Nah, I try to avoid that stuff because it's way to error-prone. I'll just take the whole server offline (!?), delete everything from the target, and redo the copy. It should be ready by tomorrow" *facepalm*.

For any GUI heroes who play at being admin out there: a good way of doing it would be to stage the transfer by doing an rsync preserving all file attributes, feel free to do this while the share is online. Take it offline and do a final sync, which should be very quick. There are other methods, but this one works fine and is quite easy.

Re:Fetish?

[Man Eating Duck]

Are you kidding? The GUI way is easier. Obviously so. The CLI way may be more concise, faster even if you know the exact syntax by heart, but certainly not easier.

That's incredibly naive, it depends on what you want to do. Rename or copy one file in a GUI? Sure. Flatten a directory structure containing thousands of dirs and files by prefixing the path to the file name? Good luck with that...

Re:Fetish?

[Anonymous Coward]

No, it does not depend on what you want to do. An example was given and the question was whether performing that specific task with a GUI or with the CLI was easier.

Re:Fetish?

[WorBlux]

No it is easier if you have the training and experience. Just like touch typing is easier than hunt and peck if you that the training and experience. Certainly not less complex, but after a point you stop thinking about it an can just make it work. -name is a shell pattern. '?' '*' and '[]" will expand as if done by bash.

Re:Fetish?

[WorBlux]

Right CLI is often short on visual data. Mainly because its often run on systems that can't handle much more than a simple framebuffer. Seeing a file manager that would accept shell commands would be cool as well. At best now you have to filter on the terminal and then pipe the file names into a file manager. I think emelFM is the only one that actually combines a command line into a file manager.

Re:Fetish?

[mattventura]

1) Hit F3 to launch the search dialog (no need to specify directory, as that comes from the folder you are currently in) 2) Type search pattern (limit by date, filesize, filecontent if you like) 3) Start search 4) Observe the results and do something with them (delete, copy, etc.)

It's exactly the same in 7. Press F3 to focus the search box, type a search term, press enter, do something with the results. In fact, you can even just hit winkey and start typing a search, which doubles as a run prompt (try typing "ping -t 4.2.2.2" or "compmgmt.msc" into the start menu search box).

Re:Fetish?

[ToasterMonkey]

Guessing positions in an Euclidean plane based on less-than-descriptive tips contained on pictograms and labels isn't something we can call "concise" and "consistent".

Look, I'm going to be nice and only ask that you reread that to yourself a few times.

Think about stdout. And pictograms... really man.. pick up a book on Japanese sometime. What do you interact with in the real world, bundles of letters?? There is nothing inherently more or less concise about CLI or GUI.

Re:Fetish?

[tmcb]

I understand your point of view, but I really meant to focus on the position-guessing mechanism. It brings some problems, such as low "batching power" and great reliance on the widgets positioning.

IMHO, GUIs lack of conciseness, because of the big screen area demanded to properly represent all the necessary interaction elements, and consistency, since actions taken by the user (that unconciously performs bidimensional pattern recognition at each interaction) are not easily reproducible by a machine. It would demand that all windows are the same size, and positioned at the same place, they were when the user interacted first.

Obviously we could compare that with a CLI, that demands a proper construction of a syntactically correct commands. Though it is true, commands and settings can be properly stored (in a history file or a shell script) for future execution.

Command Line Interface? . . . Luxury!

[PolygamousRanchKid]

When I was a lad, we had to enter JCL commands on punch cards! And if you saw someone with a deck of cards in their hands, you could grab them and scatter them on the floor. Have fun sorting them!

This was probably one of the earliest forms of malicious hacking.

Re:Command Line Interface? . . . Luxury!

[DarwinSurvivor]

No, malicious hacking would be taking a pencil and popping out an extra hole in one of the cards while they weren't paying attention :P

Re:Command Line Interface? . . . Luxury!

[Anonymous Coward]

You are the reason for "defensive programming," aren't you?

Re:Command Line Interface? . . . Luxury!

[lsatenstein]

No, it is going to the keypunch, duplicating a card to a dsn= position, and change a few letters in the name field. Or change the DCB=( )

Re:Command Line Interface? . . . Luxury!

[Anonymous Coward]

Unless using a port-a-punch, all that malicious hacker would likely accomplish was to jam the card reader. Hardly a hack worth noticing, as they happened all too often anyway.

Hi peeps, where is the "guru"?

[Anonymous Coward]

I watched two of the sessions, didn't see a guru at work.

Re:"guru" unix command line users - watch and lear

[julian67]

"if your not up for doing that, forget about using the command line tools."

That's simple conceit, pure snobbery.

Because I am utterly uninterested in using Latex I should forget about ssh, encfs, apt, yum, git, tar, mencoder, ssh, locate, find, grep, echo, cat etc?

If "your" not up to learning basic English, forget about telling other people in writing what they should or shouldn't be doing.

   

huh. useless.

[Anonymous Coward]

unless they show the reasoning behind the commands and where you can find the knowledge related to that, it is pointless.

i could show you how i use my hp48, that doesn't mean you will understand ANYTHING and you will learn even LESS.

Code snippets are better

[Anonymous Coward]

I've opened some of the "videos" and while I think it's a nice idea, it has serious drawbacks. Watching the commands get typed in takes a lot longer than reading code snippets. Also, code snippets will be indexed by search engines, so you can usually quickly find what you need. Here you are completely dependent on the quality of submissions, which is frankly not that high.

Re:Code snippets are better

[digitalchinky]

Search engines can suck too.

Since we're on the subject of shells, up until earlier this year with bash I could use environmental variables to navigate my way around; for example, ls $HOME/<tab> would show me a listing of everything in my home directory, now when you hit the tab it escapes the $ so you end up with \$HOME/ and the expected functionality that has been present for well over a decade no longer works - try searching for that little problem :-)

Search engines can be a pain in the backside just as much as video.

Watching Gurus?

[thegarbz]

Either the the supposed "gurus" are actually people who have done nothing more than read the idiots guide to the command line, or we aren't watching them work. Somehow I don't think gurus type out an explanation of what they are doing mid work, somehow I don't think gurus type quite so slowly. Having had a look at these videos they aren't about becoming better at the commandline. They look very basic and require no prior knowledge.

Not that theirs anything wrong with the project, the summary and title are just a load of crap.

I'm actually not quite sure who they are targeting. On the one side they describe how "ls" works, and on the other there's no mention of the tab key, man pages or any of the other really useful things that show what's currently going on and how to get ahead in your terminal session.

Re:Watching Gurus?

[outsider007]

I thought the same thing. If that's a guru then I'm the Maharishi Mahesh Yogi.

Re:Watching Gurus?

[SendBot]

Yeah, I sat through the "cat" example and it was annoying to watch. I then searched for some awk examples, and I came up with a page full of "insert title here" entries that were all noise and no signal.

And you can't control the playback apart from starting it. THAT SUCKS! Can't even pause? rewind, move the time cursor or w/e it's called.

This site is *not* ready for public consumption. I really wish it were.

Re:Watching Gurus?

[Anonymous Coward]

Well technically... "guru: one who has expert knowledge of a technical area and serves as an advisor to others; an expert and teacher." So conceivable a TRUE guru would be probably would move slower and provide explanations as any good teacher would. Just saying...

Re:Watching Gurus?

[paradxum]

I have to say that quite a few people would call me a guru, I work on a command line most of the day. I have to say that I kinda like this site. (I know it's unpopular on slashdot to actually like someone else's effort but I do.)

I have to agree on the points that the submitter's type rather slow (watched quite a few tutorials ... some on things i know about, others I didn't.)
However I have to say that if you do not already know what to do, the speed is reasonable.

Unix is a very large beast, there are always new more elegant solutions problems. Much like the world of math. I think this site could work well for people of quite a few skill levels. After using unix for over 20 years everyday I still find that I'll learn a new command or pattern every couple months that adds to my toolkit. If this site adds to peoples toolkits, I'd say it's a plus.

Re:Watching Gurus?

[Anonymous Coward]

You can click the screen to pause, although it will put a huge Play button on the center of the screen.

Re:Watching Gurus?

[Anonymous Coward]

The site is boring AND pointless, and you're complaining? You must be new here.

Re:Watching Gurus?

[thegarbz]

What you said is true, and the idea of the site is great. But the site doesn't appear to know what it wanted to be. Does it want to be us learning by watching gurus work (it isn't) or does it want to be a tutorial site (looks like its trying to be).

If its the former than eliminate the comments and let us watch ACTUAL work.
If its the latter than fix up the presentation. Let people talk rather than type an explanation of what they are doing since people can absorb more information that way. Let people re-wind, fastforward, stop and pause.

Re:Watching Gurus?

[Anonymous Coward]

yes agreed, I think they fixed the 'no title' search by now.
Good thing: it is free.

Cannot recognise file format

[Dupple]

The Mac archive was unopenable on my Mac, so I opened the PC version instead. Just incase others encounter the problem. I think Stufffit didn't like what the file was called, but I couldn't be bothered to tinker

Re:Cannot recognise file format

[Dupple]

My bad, I hear it every day. I should know better

Re:Cannot recognise file format

[foniksonik]

StuffIt? BOMArchive is the default Mac app.

Re:Cannot recognise file format

[Dupple]

That's what I opened the PC version with...

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

Just because the command line is useful doesn't mean GUI doesn't have it's advantages. I use whatever tool fits the job best.

Nice idea/principle for a shell education

[Anonymous Coward]

I've even checked out TA this time. I am very fond of the principle and the idea behind this. c00, finally some shared shell stuff, should be better than reading BSD fortunes :>

Re:"guru" unix command line users - watch and lear

[ZankerH]

For live preview, you'll need LyX and that needs X11.

Live preview, pfft. Real gurus write LaTeX code in ed and render it in their heads.

Re:"guru" unix command line users - watch and lear

[Alex Belits]

For live preview, you'll need LyX and that needs X11.

[La]TeX source does not specify exact layout, and its user should not rely on previews, tweaking the output by issuing random formatting commands until the output looks "right". X and frontends are useful for other purposes, for example, to avoid wasting paper when checking for mistakes in formulas, but this has nothing to do with running a WYSIWYG wordprocessor or imitation of one.

I think, we all went through this discussion when every moron used WYSIWYG HTML generators, and web pages looked like someone vomited markup over a block of text, unless user happened to have exactly the same 800x600 screen and fullscreen IE4 running on it, that "web artist" happened to have.

Which for some users would require them to buy a router supporting telnet, as opposed to a home gateway appliance supporting only HTTP.

All OS used on routers support command line interface. If router does not have command line interface, it was intentionally crippled by manufacturer.

Slowly typed text in a lousy terminal emulation?

[Anonymous Coward]

Seriously, this isn't recordings... This is just some bloke typing what he learned about bash.

Re:"guru" unix command line users - watch and lear

[Gaygirlie]

the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely. try doing stuff from your tty terminals and disable x11 :) learn to do word processing with latex, telnet into your routers to configure them. if your not up for doing that, forget about using the command line tools.

That's just a load of bull. Learning to use Latex or Telnetin to routers has nothing to do with learning to use command-line.

Re:I feel the knowledge seeping into my head alrea

[houghi]

Not sure if serious or humorous, so I'll bite:
ssh
ssh --help
info ssh
man ssh

That said, I must admit that I seldom learn anything from it. The reason is that all options are shown. While this is good as a reference when you forgot how to use a program, it gives too much information if you want to find out basic usage.

Re:"guru" unix command line users - watch and lear

[hackertourist]

Writing and structuring a book by relying only on inline formatting commands is horribly inefficient and has rightly gone the way of the dodo about two minutes after the GUI was invented. Using visual cues to relay structuring or formatting information is not a sin, but an efficient use of a communications channel.

As LyX, FrameMaker, AuthorIT and a host of other applications show, it's entirely possible to separate presentation from content in a GUI (and even a WYSIWYG) environment. You're right that the user should not engage in visual 'cargo cult' formatting, but forcing the user to write in a text-only interface is not the best way to achieve that.

Let's hope we don't see stuff like...

[Anonymous Coward]

Username: bobpassword^H^H^H^H^H^H^H^H

Re:"guru" unix command line users - watch and lear

[gerddie]

... and disable x11 :) ...

... but I need X11 to open all these terminals!

Re:I feel the knowledge seeping into my head alrea

[catmistake]

GP was probably alluding to the fact that any cli session is already txt... what is the point of videoing txt?? You'll still be reading txt, just in a massively less efficient format.

Re:COMMamd

[maxwell demon]

$ SHUTDOWN -slashdort NOW!!!!!!
>> HOORAY!

Thanks for shutting down Slashdort. Too many people confused it with Slashdot.
SCNR

VT100 to video converter

[Crouty]

Funny, stumbled upon PLAYtern two weeks ago and found it cool. But what I wanted to do was posting videos of me playing Zork on YouTube so I wrote a PHP script that converts ttyrec recordings into a bunch of PNGs and an AviSynth script that generates a video (demo). Different TrueType fonts and much of the VT100 command set is supported but I haven't yet found the time to clean up the code. If you are interested voice yourself and maybe I make a release out of it.

Re:VT100 to video converter

[Anonymous Coward]

If you are interested voice yourself and maybe I make a release out of it.

Please do.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

You can add a serial port to the WRT54g and probably other routers, it's fairly simple.

Re:"guru" unix command line users - watch and lear

[AK Marc]

I think, we all went through this discussion when every moron used WYSIWYG HTML generators, and web pages looked like someone vomited markup over a block of text, unless user happened to have exactly the same 800x600 screen and fullscreen IE4 running on it, that "web artist" happened to have

Yeah, but just about everyone on the planet uses either letter or A4 paper, and so a hard-coded WYSIWYG approach is reasonable for print, with a low chance that you send an A4 formatted document to a person in the UK who complains because it looks like crap when they try to print it on legal-sized paper.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

If by "gone the way of the dodo" you mean "become the way that the majority of books are now sold", then yes, you are correct (hint: ebooks).

Re:"guru" unix command line users - watch and lear

[hackertourist]

If a book is published on paper as well as e-book, there's about 0% chance the book was written using an HTML editor. Instead, it'll be written in a WYSIWYG package and an output processor will be used to create the HTML and PDF.
For ebook-only publications, there may be masochists who'll do the whole thing in an HTML editor, but I suspect that won't be the majority.
The same goes for instruction manuals. WYSIWYG package or a document management system as the source, and automatic processing to create HTML, PDF and whatnot.

i saw this! mystery solved!

[sam0737]

# ./do_magic
Profit!!
#

Dazzling project

[arisvega]

interesting project that offers up recordings of Linux command line sessions

Like .bash_history ?

Re:Dazzling project

[sourcerror]

I wish I could mod you up.

Re:Dazzling project

[marcello_dl]

> Like .bash_history ?
Nobody reads the 2000 page *nix manuals anymore, I guess?

Re:Dazzling project

[Anonymous Coward]

Didn't know about this, I've used only ttyrec. It's funny when you start script and then execute "cat typescript". Infinite loop xD

Re:Dazzling project

[weibin]

or script? Oh, I forgot, you just want to watch and not to type.

Re:Dazzling project

[CheerfulMacFanboy]

interesting project that offers up recordings of Linux command line sessions

Like .bash_history ?

Yeah, that's the perfect way to show interactive use of the CLI.

N - O -T

nice and all...

[Anonymous Coward]

..but they really need to realize that people do want to skip ahead of introductions or things they already know in the videos. it would make more sense if it was a pseudo video glued together with javascript just printing lines from a text file imho. (possibly including comments that would be shown as annotations or links to refer to deeper documentation or information of some of the more intrinsic command, like a link to a regular expression tutorial for sed.)

mod this up!

[lahvak]

Somebody please mod this up. Having bunch of, possibly commented, history files, would be much better than having this information as a movie.

Re:mod this up!

[Anonymous Coward]

Somebody please mod this up. Having bunch of, possibly commented, history files, would be much better than having this information as a movie.

A history file from a guru is going to have limited value. Occasionally you'll pick up a trick like:

  "tar cf - /foo | (cd /bar;gzip -9c > baz.tgz)"

or

"wget -O - http://example.com/dvd/iso | tee dvd.iso | md5sum > dvdiso.md5"

  But anything really clever is going to be hidden away in aliases, functions or scripts. For example, just looking at my history, could you tell me what "extract snortrules.tgz" does? You might, but then again, you might not. Without the corresponding .alias file, you would just be guessing, and that doesn't help if you're trying to learn.

Re:mod this up!

[lahvak]

That's why I was suggesting that comments are added, that would, hopefully, explain these things.

Anyway, in a movie, you will see somebody typing "extract snortrules.tgz", without comments it will not tell you anything that the history file doesn't.

A movie could, however, show you command line completion and command substitution tricks that will not show up in the history file.

Re:mod this up!

[Anonymous Coward]

That's why I was suggesting that comments are added, that would, hopefully, explain these things.

Anyway, in a movie, you will see somebody typing "extract snortrules.tgz", without comments it will not tell you anything that the history file doesn't.

True, comments could be helpful, but if you're going to go through the effort of commenting a history file, wouldn't it be more useful to write up a proper tutorial explaining the thought process behind the command(s), using the history file as a guide? Or if you're making a video demonstration, do voice annotations as you type out the commands?

A movie could, however, show you command line completion and command substitution tricks that will not show up in the history file.

Good point with the command line completion/command substitution. It's one thing to read about it, it's another thing to see it in action.

Re:I feel the knowledge seeping into my head alrea

[foniksonik]

Video does help, you see cadence and sequence much more effectively. You see the actual env being targeted which may not be the same as your own but with the context you can map it to your env more easily.

Completion and substitution

[lahvak]

Replying to myself: when thinking about it some more, I realized there are two extremely important aspects of CLI use that will not show up in the history file: completion and substitution. The history file will only show the commands that got executed, not how they were entered.

Youtube tutorials

[Anonymous Coward]

I've recently created a similar set of tutorials, but with a verbal description of what I'm doing while I'm doing it
http://www.youtube.com/watch?v=emJUvMLsU30
http://www.youtube.com/watch?v=18d-OdMHv3Q
All I needed for these was gtk-recordmydesktop and sound recorder. I prefer to have some explanation associated with the commands and seeing the description typed out on screen is too slow.

It would be handy if there were a way to speed the playback up, since the tutorials are sometimes too slow for my pace.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

... and disable x11 :) ...

... but I need X11 to open all these terminals!

man screen

Meh.

[Securityemo]

There's only one good way to learn programming/scripting/whatever technical: sit down with the reference and study, apply what you've learned in examples so it "sticks", lather, rinse, repeat. If the material is difficult to comprehend on an abstract level (or you don't have a reference) it's nice to have someone explain it to you - but learning a new programming language isn't like that unless it incorporates concepts that are foreign.

Re:"guru" unix command line users - watch and lear

[CronoCloud]

GNU screen is as user unfriendly as GNU Info is. Sure if you're a suspender wearing unix graybeard you probably live it.. O course you probably browse the web with wget, use emacs and still use IRC and USENET for communication and NOT piracy.

but normal people are probably better off using a tabbed terminal in X.

Dated

[Anonymous Coward]

In the Beginning was the command line? I guess you're a fan of The Diamond Age, because how can you possibly be convinced by "BeOS is like a Tank that can go 80 mph!" Or "Sell Microsoft, they'll never make it past the 90's." It's dated and stupid and wrong.

Zork

[xdor]

I blame my command-line fetish on the Legend of Zork.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

When already we have a program like "script", what is so new about it?

Re:I feel the knowledge seeping into my head alrea

[Anonymous Coward]

yaml is a standard file format for txt-files, not sure if that might be of any interest to you

Being Pedantic and Wrong is Ill-advised

[Capt.Albatross]

Just because an example was given, it does not mean that the issue collapses to that one point. Man Eating Duck is correct to say that it depends on what you want to do.

Re:Being Pedantic and Wrong is Ill-advised

[Anonymous Coward]

I responded to a question about a specific example. "Man Eating Duck" and you apparently find answering specific questions "incredibly naive" and instead expect answers to questions that haven't been posed. Good luck with that.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

When I learned LaTeX, there wasn't a live preview. I edited on my home computer (not a PC), uploaded to the Vax, ran LaTeX to get a DVI, then downloaded and looked at it with my DVI previewer. If it was good, I ran DVI to 24 pin printer or to postscript and printed. Later I could do it all on DOS. Or a Macintosh. Or SunOS.

Mostly, I didn't care about how it looked. I focused on the content, dividing into chapters, lists, equations, references etc. LaTeX had the eye candy part.
I *wish* I could get rid of the live preview in Word and just tell it : here's a header, just like all the others. Maybe LaTeX just had a design I didn't feel compelled to tweak. Oh, LaTeX I could say switch to Helvetica from Times everywhere. I have to highlight every instance in Word.

Re:I feel the knowledge seeping into my head alrea

[Riskable]

I am developing a web- based terminal emulator and one of the most useful features I added was the ability to record and play back sessions in a video- like way. Have you ever tried to read a text log of someone's vim session? Ever wish you could play back the output of top so you could see the history of a process utilization?

Not only that but it wicked cool :)

Word has style sheets

[tepples]

What you did when authoring LaTeX documents sounds like what I do when authoring HTML: I want a heading now, and I can style it later, so I put in <h2></h2>. But nice editors can be scripted to allow for mapping a single keystroke to do the equivalent of save, upload, render, download, and open the previewer.

then downloaded and looked at it with my DVI previewer.

If not X11, then what did your home computer's DVI previewer run on?

I focused on the content, dividing into chapters, lists, equations, references etc.

How many iterations did it take to get an equation looking right?

I *wish* I could get rid of the live preview in Word and just tell it : here's a header, just like all the others.

I thought Word had character and paragraph style sheets (e.g. "Normal", "Heading 1"), where changing the style associated with a style preset would change all text associated with that style preset that hasn't had its style overridden. Templates from publishers come with the style presets that they want you to use.

screen ain't hard

[Onymous Coward]

• screen start screen
• Ctrl-a c create new screen
• Ctrl-a 3 go to screen number 3

That's about all you need to start.

command line skills are useful _now_

[Onymous Coward]

the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely.

That doesn't sound quite right. I did personally learn most of my basic command line skills in a windowing-free environment, but I don't think it's necessary.

I think that even after 20 years of command line experience I could learn new things. Regardless of running X.

never know when you need those command line skills again

See, this is a weird idea, too. That command line skills might come in handy. I use the command line every day. Maybe you use some kind of file management app like Windows Explorer? I file manage through the command line. Probably not the most efficient way (I never did learn tools like Midnight Commander), but the command line works well enough.

deref the article's topic

[Onymous Coward]

Alternatives:

Don't fire off grep when you fire off ps (which you did by piping to grep) — do your grep after the ps completes.
  O=`ps -ef`;echo "$O"|grep bluefish|awk '{print $2}'
  O=`ps -ef`;echo "$O"|awk '{/bluefish/ print $2}'

If you're not actually looking for something on the command line, don't print whole command lines, just the commands. ps without flags.
  ps|awk '/bluefish/ {print $1}'

Specify to ps the executable command you wish ps to show you.
  ps -C bluefish|awk '/bluefish/ {print $1}

And output only its PID (and hide output headers).
  ps -C bluefish -o "pid" --no-headers

Or use pgrep.
  pgrep bluefish

Re:"guru" unix command line users - watch and lear

[garaged]

You've never used cisco, right?

Re:"guru" unix command line users - watch and lear

[CharlyFoxtrot]

Fast typing is a menace on critical servers.

Re:"guru" unix command line users - watch and lear

[PoopCat]

telnet router.home.net 80 # No http needed (bonus points for using netcat)

for a slightly more friendly experience:

lynx router.home.net
links router.home.net
or one of the other fine command-line HTTP clients.

Re:"guru" unix command line users - watch and lear

[Anonymous Coward]

... and disable x11 :) ...

... but I need X11 to open all these terminals!

No. Use screen.