The shell way or the highway [long rant]

[snowpine]

Good points above; I agree with many of the other posters. But there's one thing that hasn't been mentioned yet about the terminal:

It is easier for the person being helped to attempt a CLI solution, because if error messages arise, they can simply cut and paste to the forum.

If I give you instructions for installing something in Synaptic, but it doesn't work, you have to take a screenshot and figure out how to post it to the forums.

If I give you a terminal command, and it generates errors, cut & paste and the people here on the forums can help you, instead of guessing.

"I tried installing wine but I got some error" is an all too common type of post on the forums. "Here is the terminal output when I try to install wine" will get you a much more helpful response.

[mick55]

Hi BarisBlaq

you're not really helping, unless you explain what those commands do

If someone takes the time to analyze your problem, then
troubleshoot it, then provide a solution, you should
be grateful, not annoyed that they didn't explain it.

When you use the GUI does anyone explain what commands
were invoked by all that pointing and clicking?

As others have stated, with all the different flavors of Ubuntu/Linux
the CLI is the only constant.

BarisBlaq the only person who can stop you gaining knowledge is you.
Otherwise i suggest you change your nickname to "Spoonfed"

mick

[yknivag]

Basically what i mean to say is - when you provide a bunch of terminal commands to solve whatever the question is, you're not really helping, unless you explain what those commands do, and what the other options are.

I think this is the crux of the problem.

I too give advice in the form of terminal commands because, as others have said already, they are (for the most part) desktop-agnostic and work for all users.

However, I do think that the OP makes a very valid point and that, especially when dealing with new(er) users there is much to be gained by taking the extra time to explain the command.

This needn't mean typing out the man page, but could simply be a sentence stating what it will do.

This is especially important in three cases I believe:

1. When requesting people post output for diagnostic purposes. Eg "post the output of ipconfig", say "the command ipconfig will list the current network configuration, post the output of it here so we can review it with you." Then when offering advise based on that output, explain where in the output the useful information was. This helps the poster to be able to diagnose the issue for themselves next time.

2. When requesting a user runs a command that makes a change to the system. Rather than saying "run xxxxx to fix your issue." say "running xxxxx with do yyyy and this will fix your issue. If it doesn't work you can undo it by running zzzzz".

3. When giving complex command strings where the output of one is piped to another etc. Taking the time to break this down and explain each section again gives the OP of a thread the chance to learn how the command works and how similar commands may be structured for other purposes.

I appreciate that it's extra work and that sometimes it can appear patronising, but as the OP of this thread says: "give a man a fish and you feed him for today, give him a rod and you let him feed himself" and by extension become part of the community to help others.

[yknivag]

If someone takes the time to analyze your problem, then
troubleshoot it, then provide a solution, you should
be grateful, not annoyed that they didn't explain it.

I disagree, if that person doesn't take the time to explain how they analyzed, troubleshooted and solved the problem then all they have done is solve that one specific problem.

Taking the extra time to show how it was solved means that should the person encounter a similar problem in future (either themselves or from another user on the forums) they will be able to help themselves or that other new user.

The only way that the community will nurture the next generation of those trouble-shooters is to explain how it's done.

[snowpine]

I'll teach a man to fish if he shows interest in getting his feet wet.

I'm not going to waste more than 15 seconds (sudo apt-get install flashplugin-installer) on "How do I install Flash???"

Google is a much better fisherman than I could ever hope to be.

[issih]

The problem with cli commands is that for most users it is the equivalent of just presenting them with a fish...ready filleted and steamed.

An explanation of that cli command is like passing them a book on fishing and a recipe...perfect if you want to know all the little details, but somewhat overwhelming for a first stab.

A gui method explanation is like letting them watch as you catch the fish with the rod...gut it and then cook it.

They certainly won't be an expert in any of the steps after having seen that...but they could take a stab at most of them.

New users learn more from a gui than a cli methodology, at least until they have a decent feel for how the cli works.

Having said all that, I fully own up to being too lazy to properly explain sometimes...it is just human nature.

[krakenfury]

Like you I have used Ubuntu for about a year and until about a month ago, I wasn't using the terminal unless I had to. I wanted to learn, I just didn't know how to teach myself, and I wasn't just picking it up through the forums. I'm not completely comfortable with the terminal yet, but I am learning how to use it.

I can't believe no one has posted this yet:

http://www.linux.org/lessons/beginner/index.html

AWESOME. I'm going through this lesson by lesson and my fear of the terminal has disappeared. I'm not completely proficient at it, but I'm getting better. I do things from the terminal now just to get used to using it. Just basic stuff like mv, mkdir, cp, rm, rmdir, all my updates, new packages. Also info stuff like ls, grep, whatis, whereis, piping, less, more... These lessons ease you into the terminal at the perfect angle. It's painless, trust me.

[mick55]

Hi yknivag

Taking the extra time to show how it was solved means that should the person encounter a similar problem in future (either themselves or from another user on the forums) they will be able to help themselves or that other new user.

The only way that the community will nurture the next generation of those trouble-shooters is to explain how it's done.

Show me one post on this forum where anyone does that.

People want their system to work, most don't give a rat's *ss
about how you deduced their problem.

Also the answers here are not empirical.
Most of the time we don't know what's going on and we throw
out suggestions.Look how many posts say"Try this" or
"run this command and post the output"

If I had to explain my reasoning behind every suggestion i give
i would stop being a contributor.No one has that kind of time.
This isn't a job.

I believe the onus for learning to be on the student
not the teacher.

Look at things from a real world viewpoint.

When a Doctor gives you a prescription, do you expect him
to tell you how he arrived at that diagnosis?
Of course not.

This is no different.

cheers
mick

[blueridgedog]

My .02:

The CLI is Linux. As a Linux user, I can have any number of window managers and desktop environments. I can not give instructions that assume you have xfce, when in fact you have gnome, or KDE. In the future, you will use a different window manager and you will rely on your command line skills.

In giving commands, we are in fact trying to teach you to fish. The graphical tools are overlays on top of a rich and functional base that is the foundation and heritage of the OS. We are teaching the core when we give commands. Yes, that assumes we explain them and I sometimes forget to do so.

Secondly, there are people who are here for help and there are people that are here for learning. Some people just want problem X solved. If I can help ten people with efficient commands and links to other posts or websites or one person with hand crafted replies detailing what each command consists of (or long posts of click this then that and look for this and the other thing), I will opt for the ten. I try and give enough detail to be informative and helpful, and the opportunity always exists to ask for more information. If I have helped you and you want to learn more, fantastic.

Finally, I have used Linux since 1994 and when I have a problem, I am using a terminal to solve the problem. I can only teach what I know. The GUI is in a state of flux and as stated above, not standard from user to user. Solutions that require a GUI can not be implemented in many recovery situations.

[mick55]

Blueridgedog you hit the nail on the head.

Here's a scenario for you.

Complete noob needs to compile from source.
Walking them through this is going to be extremely
difficult due to lack of familiarity with the CLI.
If we can accomplish this daunting task we are all happy.
Now, imagine having to explain to the noob exactly what all
those commands mean and what they do

Hey, be my guest and explain them all to a noob

# tar xvzf package.tar.gz (or tar xvjf package.tar.bz2)
# cd package
# ./configure
# make
# make install


My point is when the student is ready the teacher will appear.

peace
mick