PLAYterm: a New Way To Improve Command Line Skills 162
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.
CLI fetish (Score:2)
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 (Score:5, Informative)
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: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:1)
I believe PowerShell was the first.
Re: (Score:2)
Re: (Score:2)
Scripting in csh is Considered Harmful and you shouldn't do it. It's really only good for interactive use.
Re: (Score:2)
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: (Score:2)
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: (Score:2, Insightful)
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: (Score:2)
psh (Perl shell) sounded like a good idea. Never looked into it, though. Wonder what happened to it.
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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 [folk.uio.no]. 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: (Score:2)
Not true. Commands that conflict with python names need escaping; others can be typed just as in a normal shell.
Re: (Score:1)
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: (Score:3)
Re: (Score:2)
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: (Score:3)
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 (Score:5, Interesting)
Use python or perl for complex tasks by all means, but they are a poor substitute for what the shell is good for.
Re: (Score:2)
"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: (Score:2)
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: (Score:2)
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
Re: (Score:1)
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: (Score:3)
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: (Score:1)
Re: (Score:2)
/[b]luefish/ will match "bluefish" but not "awk /[b]luefish/"
Aha.
deref the article's topic (Score:2)
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 '/b
Re: (Score:2)
How would you get rid of the 'grep bluefish' entry in the process list then?
Re: (Score:2)
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: (Score:2)
ps without -f does not show the full command line — you won't see the args to awk.
Re: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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 go
"guru" unix command line users - watch and learn? (Score:3, Interesting)
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
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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 v
Re: (Score:2)
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 us
Re: (Score:2)
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,
Re: (Score:2)
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.
Word has style sheets (Score:2)
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 (
Re: (Score:3)
"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.
Re: (Score:2)
Re: (Score:2)
... and disable x11 :) ...
... but I need X11 to open all these terminals!
Re: (Score:2)
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.
screen ain't hard (Score:2)
That's about all you need to start.
command line skills are useful _now_ (Score:2)
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.
See, this is a weird idea, too. That command line skills might come i
Re: (Score:2)
Fast typing is a menace on critical servers.
"Command Line" is obsolete, says Stephenson (Score:2, Informative)
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 [slashdot.org]
Re: (Score:2)
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: (Score:2)
OS X has a command line. It's a lot more usable than the finder.
Re: (Score:2)
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: (Score:2)
You realize that OS X is a certified Unix [arstechnica.com] ?
I feel the knowledge seeping into my head already (Score:1)
kn0r tmp # how to ssh?
kn0r tmp # ssh yourusername@someserver.com
^C
kn0r tmp #
If only there were a standard file format for textual content.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
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 :)
Fetish? (Score:1)
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: (Score:1)
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
Re: (Score:2)
What the OP meant was that if you are doing rsync/grep/find/sed stuff via a
Re: (Score:2)
Such a common usage, that find has an option to make it even easier...
find _directory_ -name Thumbs.db -delete
Re: (Score:1)
http://technet.microsoft.com/en-us/scriptcenter/dd742419 [microsoft.com]
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:1)
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 t
Re: (Score:1)
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...
Being Pedantic and Wrong is Ill-advised (Score:1)
Re: (Score:2)
Command Line Interface? . . . Luxury! (Score:3)
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! (Score:4, Funny)
Watching Gurus? (Score:3, Interesting)
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: (Score:1)
I thought the same thing. If that's a guru then I'm the Maharishi Mahesh Yogi.
Re: (Score:2)
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: (Score:3)
I have to agree on the points that the submitter's type rather slow (watched quite a few tutorials
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
Re: (Score:2)
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
Cannot recognise file format (Score:1)
Re: (Score:2)
StuffIt? BOMArchive is the default Mac app.
Re: (Score:1)
Re: (Score:1)
VT100 to video converter (Score:2)
i saw this! mystery solved! (Score:2)
# ./do_magic
Profit!!
#
Dazzling project (Score:2)
interesting project that offers up recordings of Linux command line sessions
Like .bash_history ?
Re: (Score:2)
I wish I could mod you up.
Re: (Score:2)
> Like .bash_history ?
Nobody reads the 2000 page *nix manuals anymore, I guess? [about.com]
mod this up! (Score:2)
Somebody please mod this up. Having bunch of, possibly commented, history files, would be much better than having this information as a movie.
Completion and substitution (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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
Meh. (Score:2)
Zork (Score:1)
Re: (Score:1)
$ SHUTDOWN -slashdort NOW!!!!!!
>> HOORAY!
Thanks for shutting down Slashdort. Too many people confused it with Slashdot.
SCNR
Re: (Score:2)