• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What do you guys like about the command line over a GUI?

I hear lots of talk about the power of the command line and I'm interested to know what you can do with it that can't be done in a GUI.

What makes *nix/*BSD command line better than Windows command line?

 
Everything is possible in a GUI, it's just buried deeper. To get the same options I have in my command line programs, you'd have to have a million menus in a GUI based one. 😕

It's great for remotely administering a server. I haven't found a GUI remote admin program yet that is good and fast on a slow crappy connection.

 
Scriptability is also important. Anything you can do with the CLI can easily be put into a script and automated.
 
If you know what you're doing, most things are faster from the command line than from the GUI, especially if you're working remotely, even more so if that remote link is "slow". Here are some examples, some wintel, some unix.

think about running chkdsk on a NTFS volume in windows, and how many clicks it takes you to actually do it.

...or, you can just type chkdsk f: (if the drive happens to be f).

Commandline is also more likely to give you better feedback from the operation. Here is the output from the chkdsk I ran, for example:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\random>chkdsk f:
The type of the file system is NTFS.
Volume label is RAID0.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.

144601033 KB total disk space.
65465892 KB in 38162 files.
15740 KB in 743 indexes.
0 KB in bad sectors.
109341 KB in use by the system.
65536 KB occupied by the log file.
79010060 KB available on disk.

4096 bytes in each allocation unit.
36150258 total allocation units on disk.
19752515 allocation units available on disk.

C:\Documents and Settings\random>

The GUI will hide most of that stuff from view, just to keep things simple and clean for your basic user.

Some of the best GUIs I use on UNIX have a popup command window, which gives you the exact commandline syntax of any operation you perform with the GUI, so you can see exactly what it is doing, which makes it very easy to script something you've not touched before.

Basic manipulation of flat files is quick and easy from the commandline. Your boss wants a lists of all your hosts, but he doesn't want to see the IP addresses.

cat /etc/hosts | awk ' { print $2 } ' > /tmp/hosts_for_boss

I can type that line faster than any way I can perform the same manipulation in a GUI.

Another example, say you've got a common directory for downloads. Now you want to go in a copy downloads of a certain file type to a different directory.

copy c:\downloads\*.mp3 f:\mp3_archive

Now that is much quicker than opening a explorer/filemangler view of the download directory, sorting by filetype, highlighting all of the mp3 files and then dragging and dropping to a view of mp3_archive or using CTRL-C/X CTRL-V. Pretend you do this on a regular basis, and you do it for 5 or 6 different filetypes. You can just create a batch file(dos script) that has lines like that copy for each filetype/destination, and then put it in your path for easy execution from the commandline, or even create an icon on your desktop for the process.

The difference between UNIX and Windows is kind of highlighted by how they treat the commandline/gui relationship. In UNIX, the GUI is the extra addon, in Windows, the commandline feels like the addon/extra. 🙂

 
If I want to get something done, and quickly (with the keyboard), I use the command line. I also use it for everything on my linux server which doesn't have a monitor connected.
 
In *nix, I've alwasy used on servers, with no GUI, so I've learned to do things CLI. I'm trying to learn to use it as a desktop, but still a lot of things it's easier to use CLI than search through menus.

On Windows, there some things you have to use CLI for. Lets say you want to copy some files, a LOT of files, and you don't want any prompts to interrupt it while you go do something else and you want to preserve NTFS permissions; you can't do that in GUI but you can with XCOPY and the right switches.

or, you must use the CLI to open regedit.

Even on Windows it's faster/easier to hit Start>run and type "calc" or "notepad" than finding them in the list under Accessories.

Scripting.
 
the biggest reason CLI in *nix is better then Windows, is the better shells....Bash scripting owns batch files evey which way, you can ADD functionality to windows scripting, and its been getting BETTER (slowly) with vbscript, netsh, etc, but those are all seperate from the shell.

the big one I can see that CLI is easier then GUI is web server administration. Take my httpd.conf, compare that to the multitude of menus, property boxes, tabs, etc and you can find stuff much easier. Also, if I'm looking for something, like what port my server runs on, I open the file and just search for it. /port is much easier then IIS' GUI.
 
A good hybrid would be nice. I like having a GUI, but having things buried and having to look for them kind of sucks. It's like programming in a 4G language that is template driven. It makes things easier until you have to do that one thing that requires you looking EVERYWHERE to do it, when in a 3G language it's a single line of code.
 
I like the command line because of the flexiblity.

With the command line your telling the computer what to do. It's difficult to know the language and different small options, but this is were good documentation is key.

With a GUI your very limited to what you can do.. The programs and the interfaces are all dialogs that were designed by some committee that tried to figure what you need the program for. It's very limiting. It's always asking you what to do.. should I do "a", "b", "c", or "d"?

However if you want to do "z", then your screwed.

With the command line it's much more difficult to do a, b, c, d, were in the GUI you just open a menu or start a wizard... but if you want to do z all you have to do is be creative and smart enough to figure out the magic combination of commands, pipes, and redirects.

The ideal situation is going to be the combination of both a GUI and command line.

It seems lots of the best GUI programs that I use in Linux are front ends to command line stuff. That way you end up with programs that take care of specific functionality, like cdrecord utility for writing cdroms and dvds, and cdparanioa for error-compinsating ripping of audio cd. Those programs are good at what they do.. Then you use other utilities for creating and formatting a loopback iso9660 file system.. then you write a GUI program for all that to makeit easy to select files and media and all of a sudden you have a high quality cdrom authoring program that can be used to create images, burn, and rip disks.. and flexible enough that a end user could extend it to suite different circumstances that you never thought about.. like a front end for a farm of computers for cheap mass making of cdroms.

If it was pure GUI it would limit functionality and lead to more untested buggy code that is limited in functionality while increasing work load for the developers.

I think the future is going to be managed code for the GUI.. such as garbage collecting programming languages like Python or something like .NET/C# or even Java with speed-sensitive or specialized code written in C or C++ style languages.

That way you get speed for were it's important, a GUI that is flexible and easy (or easier) to program, and you still have all the easy scriptability that the command line enviroment can offer.
 
The latency involved in a long distance administration session isn't a big deal to a commandline. It's a serious hassle for a gui.
 
On remote admin with a GUI - we have a server to administer in Tokyo (from Manchester) and it only a 56k pipe 🙂 Still RealVNC manages to do the job - it really is fantastic especially if you set it up to poll on the correct events.

As for the command line vs the GUI ... I like to feel like a real man so I do it all bit by bit in binary and compile on the fly 😛
 
Bash is what makes me use the command line, being able to automate tasks and write scripts. Cron is also another useful tool that I can use to leverage bash. Plus I've even written gui apps in bash.
 
UNIX was built on the concept of small software tools that accept input from one process and pass their output to another. So you can pipe together several programs and do very elaborate things. There are thousands of these utilites so chances are excellent that whatever you need to the tools exist.

Last night I wrote a script on my Linux box to capture audio from XM radio using SoX and encode it to OGG Vorbis using OggEnc on the fly. I'm planning to add a condition that starts new recordings once the current file reaches 700MB ( `stat -c %s $OGGFILE` > $CDR_LIMIT ). I can get about 9 hours of music on a CD and it sounds great.
 
1. Pipes
2. Shell scripts
3. Odd combinations of the above.

The command line today is more of a programming environment than a user interface. For day-to-day file browsing and copying, the GUI is probably easier. For anything that involves a large amount of repetitive tasks, the command line is your friend.
 
Wildcards. I can copy all files that have "apple" in the middle to the root of my current drive with ease: copy *apple*
In Explorer I'd have to select them manually, and you couldn't sort them based on that criteria. Well actually you can in a common dialog (File Open, Save, etc.) by typing in *apple* and pressing Open/Save, but you still can't in Windows Explorer which is what you'll be copying files with, most likely, if you use Windows.

I haven't found much use piping stdout of one CLI program to another, unless everything you use is based on the command line.

Software like AutoCAD is a pleasure to use because of how it combines a GUI with a command line. It's really great.
 
Originally posted by: omissible
1. Pipes
2. Shell scripts
3. Odd combinations of the above.

The command line today is more of a programming environment than a user interface. For day-to-day file browsing and copying, the GUI is probably easier. For anything that involves a large amount of repetitive tasks, the command line is your friend.

Of course, the best way to learn a programming interface is to use it all the time. I've found that the only time a GUI file manager betters the command line is when you need to process a number of files that don't follow some kind of pattern; and even then, there are exceptions: if the files are all in the same directory, it's easier to use a GUI file manager; but if the files are in completely different parts of the file system, a CLI with autocomplete is better.
 
Originally posted by: xtknight
I haven't found much use piping stdout of one CLI program to another, unless everything you use is based on the command line.

You generally use this in conjunction with tools that transform text, like sed, awk, and perl. I'm sure you can install ActiveState Perl, put it in your PATH, and do some useful one-liners.

Software like AutoCAD is a pleasure to use because of how it combines a GUI with a command line. It's really great.

Not having an engineering as a major, but despite being surrounded by such people on a daily basis, I have never used or seen-used AutoCAD. What makes its CLI-GUI combination so special?
 
Inputing specific angles to plot the next line, but not defining a specific length (which you will define with the mouse) is an example.
 
It's really great. Everything you do with your mouse is just inputted in to the console below so you can type perp (perpindicular) and then select the points with your mouse for example. I'm not an engineer either so I never use it much but my dad and electrical-engineer brother do.
 
The ability to perform repetitive tasks on large numbers of files defined by use of * ? and the like is absolutely lovely. I have 350 .zip files that need to be extracted: Click, click through archive manager 350 times, or
"unzip /*.zip unzipped"?
 
It's much more flexible for ad-hoc kind of stuff. Like that post in off-topic from some guy that wanted to reorganize his mp3 collection based on some playlist. That'd be about a 4 to 6 line shell script, but forever on a gui.
 
Originally posted by: omissible
The command line today is more of a programming environment than a user interface. For day-to-day file browsing and copying, the GUI is probably easier. For anything that involves a large amount of repetitive tasks, the command line is your friend.

It's always been like that. Whenever your using a computer your programming it, interacting with it.

Everything from setting up your email to working on a spreadsheet to writing a shell script to writing a kernel driver is programming.. The difference just a matter of degrees, level of professionalism, the depth of the software layers, and complexity exposed to the end user (programmer).

The Unix shell, especially in the form of open shells like Bash, continue to evolve and change over time.

For example somewhat recently Bash 3.x series has been released.. When I am using Debian Sid with the 'bash completion' option enabled for my shell account I have several things that I can do that I couldn't do before.

(to do that you have to edit your ~/.bashrc file and uncomment if... fi part were it deals about bash completion, then logout and log back in)

Such as if I download a mp3 or whatnot.. I can cd to the download directory and if I want to listen to it I can type:
$ mpg123 <tab><tab>

and get a list of all just mp3s (and subdirectories incase I want to play a mp3 in one of those) in that directory. That way if I have a directory full of random stuff.. zip files, pdf files, text files, etc etc I don't have to search thru all of them.

It's a lot easier for me to do that then to open up a directory and try to visually scan thru a dozen or more random files for the one paticular I want.. and if I downloaded it I often don't know the exact name of it.

I often use the "find" command and the "file" command to locate files or specific types of files. I've made m3u playlists by doing stuff like.

I like to investigate files I download often, also. Handy commands for things like that are something like:
strings filename|less

I find out amusing things sometimes.. like pdfs made by Novell to promote Linux over Windows were made by adobe pdf distiller for windows, jpegs for Redhat's website were made using Photoshop on OS X, Microsoft uses OpenBSD code for lots of it's unix compatability stuff. Stuff like that. It's kinda interesting what you can find out about stuff by snooping around.

Also I like to go like:
ssh -X mydesktop

and open up my email client or amarok (advanced mp3 player) on my desktop system from my laptop to check email or play music on my stereo remotely without having to setup some sort of web based interface or a deamon listening on a paticular port.

Since X Windows is a network protocol and ssh can act as a tunnel for X it's very handy.. Once it's enabled in the server (allowing X over ssh by default poses certain specific security risks for if you allow other people to login thru ssh) I can run commands and open GUI programs on any of my computers to appear on any other of my computers. (X has limited use over the internet though.. but that's what freenx is for.)

There are lots of little things like that.



Myself and most other more comfortable Linux desktop users will pretty much always have a xterm or two open for various different reasons. It's a nice thing to have...

 
Back
Top