Why Linux Command-Line?

[colorend]

That was was both entertaining and informative. It should also be used to show off the capabilities of command-line.

[zetra]

I hate it to see people are against command-line in fanatic way.

[Mark Greaves (PCNetSpec)]

Hi zetra, and welcome to the forum

[SeZo]

I hate it to see people are against command-line in fanatic way.

I think it is more likely that they are scared from the command line.

[Emegra]

I think it is more likely that they are scared from the command line.

I'm scared of it as well but I can appreciate it's power, just wish I had the brains to use it

[Mark Greaves (PCNetSpec)]

I can't understand why people are quite happy to explore parts of their OS by GUI, yet immediately become "scared" to do the same in the CLI .. you can just as easily screw your system either way .. but once you understand a handful of commands for the CLI (and how to understand the documentation for what you don't know) you may find fixing things a little easier
(oddly, the CLI tends to be better documented .. once you learn how to read it)

Sure, you'll make mistakes (hopefully not big ones) .. but isn't that the way we learn .. and that equally applies to the GUI.

I found the easiest way to pick up the command line was every time you see a command given on a forum that you don't understand .. use the man pages to try to work it out .. some of it eventually sinks in

So if you see say

Code: [Select]

dpkg -l | grep flash

You'd look at:-

Code: [Select]

man dpkg

and see what the "-l" option does.

"|" means pipe (redirect) the output to the next command .. which is "grep" .. so then look at:-

Code: [Select]

man grep

to see what it's going to do with the output from "dpkg -l"

and you'll find that:-

"dpkg -l" will list the current install status of ALL packages you have installed, but it would be a long list  .. so instead of printing it ALL to screen, the output was piped (|) to the "grep" command which will search that output for all lines containing the string "flash" which are then printed to  screen.

So whoever wrote the command was looking for the current installation status of all packages containing the string "flash" .. or put another way, what "flash" packages you have installed.


Once you get your head round how to understand the man pages, it all starts to fall into place pretty quickly.


FYI, you can exit a man page and return to a normal $ prompt by hitting the "Q" key.


Here endeth the lesson for today

--

[Emegra]

if Linux in general is to gain more widespread adoption good and intuitive gui's are imperative

I would agree with that but there's no reason we can't have both for those who want it and in that regard Linux is way ahead of Windows



Graeme

[jamieb158]

When I used windows I would often use a dos box to run commands, file management etc us far easier and faster from the command line. In Linux the "average user" could happily run without ever opening a terminal, the likes if zorin have done an outstanding job of that. When I help friends convert I always use zorin full image, one of my colleagues is still running zorin 6 having never needed to open a terminal some 2 years down the line.

Sent from my GT-N7100 using Tapatalk

[Mad Penguin]

$0.02

• "Users" should never need to use the command line - and with GNOME/KDE etc I believe that is true
• You can never program "all" eventualities into a GUI - so you still need the command line

Consider something I use in various forms on a regular basis; "show me the top 10 hitting IP's on the forum"

Code: [Select]

cat linuxforum.access_log|cut -f1 -d" "|sort|uniq -c|sort -rn|head

It's something an admin familiar with bash scripting will just "know" and be able to type / modify as suits in around 10 seconds. To guess that this might be needed, and moreover finding a way to implement this as a flexible option in a GUI - that would be something else. Or alternatively; "show me the number of log entries in all log files over 20M in size";

Code: [Select]

find . -size +20M -exec wc -l {} \;

GUI .vs. CLI is the difference between trying to talk to the computer in a foreign language using a dictionary, .vs. speaking the computer's native tongue. The former is fine if you're a tourist, but the latter is really needed if you live there ..

[videobruce]

For the average PC user like myself the command line is really a non starter and if Linux in general is to gain more widespread adoption good and intuitive gui's are imperative and something I think Linux is still lagging behind Windows although I think the gap is closing

I couldn't agree with that more.

I'm not anti-command line. There is a place, but to use it for tasks that have been available in GUI form for decades (literally) is very dated thinking.

[Mark Greaves (PCNetSpec)]

I'm not anti-command line. There is a place, but to use it for tasks that have been available in GUI form for decades (literally) is very dated thinking.

I have a couple of problems with that statement...

a) What if it's easier/faster to achieve my goal at the command line .. is it still "dated thinking" to not use the slower/harder GUI front end, or is it "common sense" to learn/utilise the best method to get the job done ?

b) (and I think this is what you mean) Providing help on a forum it's MUCH easier to type up command line instructions, and MUCH easier for the person getting the help to give a concise response via copy/pasting the terminal output.
(it also leaves little room for misunderstanding)

Try typing full GUI instructions to simply copy a file from one place to another .. it's going to take a paragraph compared to:

Code: [Select]

cp /file/to/be/copied /place/to/put/it/

Command line instruction leave no room for "interpretation" issues .. "go into your menus and click the media player icon" is not as clear as .. run:

Code: [Select]

vlc

(for all I know he has more than one media player)

A GUI application gives little in the way of feedback .. a misbehaving GUI app is more likely to fail silently, whereas attempting to run it from the command line nearly always returns useful information on *where/why* it failed, this output is generally invaluable in finding a solution.

Command line instruction can be copy/pasted into the terminal .. and the output copy/pasted back to the forum.
(try doing that with point and click instructions)

My point is, use the best tool for the job .. where the command line is the best tool why use an often inferior GUI front end that makes things unnecessarily more difficult ?