Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Education Unix Linux

PLAYterm: a New Way To Improve Command Line Skills 162

Posted by timothy from the if-they-say-the-word-paduan-run-away-fast dept.
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.
This discussion has been archived. No new comments can be posted.

PLAYterm: a New Way To Improve Command Line Skills More

PLAYterm: a New Way To Improve Command Line Skills

Comments Filter:

  • 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)

      by Nursie ( 632944 ) on Saturday September 24, 2011 @04:44AM (#37500314)

      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!

      • 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: (Score:2, Insightful)

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

      • 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.

        • 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)

            by dougmc ( 70836 )

            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)

        by Anonymous Coward

        I believe PowerShell was the first.

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

      • Re: (Score:2)

        by Nimey ( 114278 )

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

      • 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)

      by tepples ( 727027 )

      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)

      by 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.

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

    • 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)

    • 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.

      • 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.

    • 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)

      by martin-boundary ( 547041 ) on Saturday September 24, 2011 @07:21AM (#37500752)
      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.

      • "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)

      by DarkOx ( 621550 )

      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.

    • 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)

        by tele ( 246082 )

        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).

        • 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?

          • -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.

        • 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

    • 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)

      by lahvak ( 69490 )

      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)

      by Urkki ( 668283 )

      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)

    by ardiri ( 245358 ) on Saturday September 24, 2011 @05:01AM (#37500368) Homepage

    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)

      by tepples ( 727027 )

      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.

      • 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.

      • 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

        • 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)

          by AK Marc ( 707885 )

          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.

    • "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.

         

    • Comment removed based on user account deletion

    • Re: (Score:2)

      by gerddie ( 173963 )

      ... and disable x11 :) ...

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

    • 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 i

    • Fast typing is a menace on critical servers.

  • "Command Line" is obsolete, says Stephenson (Score:2, Informative)

    by 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 [slashdot.org]

    • 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)

      by Hatta ( 162192 )

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

      • 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.

    • You realize that OS X is a certified Unix [arstechnica.com] ?


  • 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.

    • Comment removed based on user account deletion
      • 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.

        • 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)

          by Riskable ( 19437 )

          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 :)

  • 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.

    • 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

  • Command Line Interface? . . . Luxury! (Score:3)

    by PolygamousRanchKid ( 1290638 ) on Saturday September 24, 2011 @05:16AM (#37500422)

    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.

  • Watching Gurus? (Score:3, Interesting)

    by thegarbz ( 1787294 ) on Saturday September 24, 2011 @05:30AM (#37500472)

    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.

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

    • Re: (Score:2)

      by SendBot ( 29932 )

      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)

      by paradxum ( 67051 )
      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

      • 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

  • 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
  • Funny, stumbled upon PLAYtern two weeks ago and found it cool. But what I wanted to do was posting videos of me playing Zork [wikimedia.org] on YouTube so I wrote a PHP script that converts ttyrec recordings into a bunch of PNGs and an AviSynth [wikimedia.org] script that generates a video (demo [youtube.com]). 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.

  • # ./do_magic
    Profit!!
    #

  • interesting project that offers up recordings of Linux command line sessions

    Like .bash_history ?

    • I wish I could mod you up.

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

      • 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.

    • 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

  • 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.

  • Zork (Score:1)

    by xdor ( 1218206 )
    I blame my command-line fetish on the Legend of Zork.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close