×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PLAYterm: a New Way To Improve Command Line Skills

timothy posted more than 2 years ago | from the if-they-say-the-word-paduan-run-away-fast dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

162 comments

CLI fetish (1)

sourcerror (1718066) | more than 2 years ago | (#37500302)

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 (4, Informative)

Nursie (632944) | more than 2 years ago | (#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!

Re:CLI fetish (1)

SuricouRaven (1897204) | more than 2 years ago | (#37500348)

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

Anonymous Coward | more than 2 years ago | (#37500588)

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

Re:CLI fetish (0)

Anonymous Coward | more than 2 years ago | (#37500750)

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

Re:CLI fetish (0)

Anonymous Coward | more than 2 years ago | (#37500874)

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

Re:CLI fetish (0)

Anonymous Coward | more than 2 years ago | (#37501102)

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 (1)

Gordonjcp (186804) | more than 2 years ago | (#37500350)

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 (1)

Gordonjcp (186804) | more than 2 years ago | (#37500358)

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 (1)

Anonymous Coward | more than 2 years ago | (#37501170)

I believe PowerShell was the first.

Re:CLI fetish (1)

Nimey (114278) | more than 2 years ago | (#37501420)

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

Re:CLI fetish (1)

Requiem18th (742389) | more than 2 years ago | (#37501702)

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 (1)

tepples (727027) | more than 2 years ago | (#37500390)

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

Anonymous Coward | more than 2 years ago | (#37500396)

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 (0)

Anonymous Coward | more than 2 years ago | (#37500624)

Python is very well adapted for interactive use.

Re:CLI fetish (0)

Anonymous Coward | more than 2 years ago | (#37500696)

$ ls

vs

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

No, it's not.

Re:CLI fetish (1)

Anonymous Coward | more than 2 years ago | (#37500760)

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 (1)

Shoe Puppet (1557239) | more than 2 years ago | (#37501280)

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 (1)

bobstreo (1320787) | more than 2 years ago | (#37500434)

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 (2)

JaredOfEuropa (526365) | more than 2 years ago | (#37500526)

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 (1)

hedwards (940851) | more than 2 years ago | (#37501438)

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 (2)

drinkypoo (153816) | more than 2 years ago | (#37500620)

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 (5, Interesting)

martin-boundary (547041) | more than 2 years ago | (#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.

Re:CLI fetish (1)

DarkOx (621550) | more than 2 years ago | (#37500824)

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 (1)

superdude72 (322167) | more than 2 years ago | (#37500848)

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 (0)

Anonymous Coward | more than 2 years ago | (#37500908)

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 (1)

Hatta (162192) | more than 2 years ago | (#37501006)

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

Re:CLI fetish (1)

DrgnDancer (137700) | more than 2 years ago | (#37501160)

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 (0)

Anonymous Coward | more than 2 years ago | (#37501648)

pgrep bluefish

Re:CLI fetish (1)

tele (246082) | more than 2 years ago | (#37501804)

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 (2)

superdude72 (322167) | more than 2 years ago | (#37501910)

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 (2)

martyros (588782) | more than 2 years ago | (#37501098)

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 (1)

lahvak (69490) | more than 2 years ago | (#37501320)

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.

"guru" unix command line users - watch and learn? (2, Interesting)

ardiri (245358) | more than 2 years ago | (#37500368)

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:"guru" unix command line users - watch and lear (1)

tepples (727027) | more than 2 years ago | (#37500404)

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:"guru" unix command line users - watch and lear (1)

ZankerH (1401751) | more than 2 years ago | (#37500498)

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 (2)

Alex Belits (437) | more than 2 years ago | (#37500516)

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.

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

hackertourist (2202674) | more than 2 years ago | (#37500682)

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.

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

Anonymous Coward | more than 2 years ago | (#37500828)

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 (1)

hackertourist (2202674) | more than 2 years ago | (#37500856)

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.

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

AK Marc (707885) | more than 2 years ago | (#37500822)

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 (0)

Anonymous Coward | more than 2 years ago | (#37500786)

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 (2)

julian67 (1022593) | more than 2 years ago | (#37500458)

"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:"guru" unix command line users - watch and lear (0)

Anonymous Coward | more than 2 years ago | (#37500486)

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.

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

Gaygirlie (1657131) | more than 2 years ago | (#37500562)

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:"guru" unix command line users - watch and lear (1)

gerddie (173963) | more than 2 years ago | (#37500732)

... and disable x11 :) ...

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

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

Anonymous Coward | more than 2 years ago | (#37501716)

... and disable x11 :) ...

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

man screen

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

Anonymous Coward | more than 2 years ago | (#37500378)

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:"Command Line" is obsolete, says Stephenson (2)

BrokenHalo (565198) | more than 2 years ago | (#37500538)

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 (1)

Hatta (162192) | more than 2 years ago | (#37501062)

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

Re:"Command Line" is obsolete, says Stephenson (1)

hedwards (940851) | more than 2 years ago | (#37501458)

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.

I feel the knowledge seeping into my head already (1)

Anonymous Coward | more than 2 years ago | (#37500412)


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.

Re:I feel the knowledge seeping into my head alrea (1)

houghi (78078) | more than 2 years ago | (#37500612)

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:I feel the knowledge seeping into my head alrea (2)

catmistake (814204) | more than 2 years ago | (#37500734)

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:I feel the knowledge seeping into my head alrea (1)

foniksonik (573572) | more than 2 years ago | (#37501574)

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.

Fetish? (1)

zarlino (985890) | more than 2 years ago | (#37500416)

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? (0)

Anonymous Coward | more than 2 years ago | (#37500524)

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? (1)

DarwinSurvivor (1752106) | more than 2 years ago | (#37500594)

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? (1)

Dr_Barnowl (709838) | more than 2 years ago | (#37500686)

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

find _directory_ -name Thumbs.db -delete

Re:Fetish? (1)

Rhodri Mawr (862554) | more than 2 years ago | (#37500704)

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

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

Re:Fetish? (0)

Anonymous Coward | more than 2 years ago | (#37500768)

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? (0)

Anonymous Coward | more than 2 years ago | (#37500792)

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? (2)

tmcb (2136918) | more than 2 years ago | (#37500866)

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? (1)

Anonymous Coward | more than 2 years ago | (#37501042)

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? (0)

Anonymous Coward | more than 2 years ago | (#37501100)

Eat shit, lamer

Re:Fetish? (1)

Man Eating Duck (534479) | more than 2 years ago | (#37501652)

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? (0)

Anonymous Coward | more than 2 years ago | (#37501734)

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? (1)

grumbel (592662) | more than 2 years ago | (#37501076)

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? (0)

Anonymous Coward | more than 2 years ago | (#37501138)

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? (1)

Man Eating Duck (534479) | more than 2 years ago | (#37501588)

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.

Command Line Interface? . . . Luxury! (2)

PolygamousRanchKid (1290638) | more than 2 years ago | (#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.

Re:Command Line Interface? . . . Luxury! (3, Funny)

DarwinSurvivor (1752106) | more than 2 years ago | (#37500600)

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

Hi peeps, where is the "guru"? (0)

Anonymous Coward | more than 2 years ago | (#37500446)

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

huh. useless. (0)

Anonymous Coward | more than 2 years ago | (#37500462)

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 (0)

Anonymous Coward | more than 2 years ago | (#37500466)

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 (1)

digitalchinky (650880) | more than 2 years ago | (#37501354)

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? (2, Interesting)

thegarbz (1787294) | more than 2 years ago | (#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.

Re:Watching Gurus? (1)

SendBot (29932) | more than 2 years ago | (#37501364)

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? (0)

Anonymous Coward | more than 2 years ago | (#37501480)

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

Cannot recognise file format (1)

Dupple (1016592) | more than 2 years ago | (#37500482)

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 (-1)

Anonymous Coward | more than 2 years ago | (#37500672)

Yes yes, I know I'm offtopic, but everytime I hear a PC and MAC in the same sentence I cringe.

Nice idea/principle for a shell education (0)

Anonymous Coward | more than 2 years ago | (#37500492)

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

Slowly typed text in a lousy terminal emulation? (0)

Anonymous Coward | more than 2 years ago | (#37500544)

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

Let's hope we don't see stuff like... (0)

Anonymous Coward | more than 2 years ago | (#37500684)

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

VT100 to video converter (1)

Crouty (912387) | more than 2 years ago | (#37500776)

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.

Dazzling project (1)

arisvega (1414195) | more than 2 years ago | (#37500962)

interesting project that offers up recordings of Linux command line sessions

Like .bash_history ?

mod this up! (1)

lahvak (69490) | more than 2 years ago | (#37501352)

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 (1)

lahvak (69490) | more than 2 years ago | (#37501602)

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.

nice and all... (0)

Anonymous Coward | more than 2 years ago | (#37500994)

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

Youtube tutorials (0)

Anonymous Coward | more than 2 years ago | (#37501688)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...