by Chris Hargreaves
During the last two weeks I have spent a disproportionate amount of time staring at a command prompt. This has been for a couple of reasons, which will be mentioned later in this article. What was interesting from these experiences is how in one case the command line was something that was a complete pain to use and left me wondering why it was still necessary, but in another case, this was followed by a completely different experience that made me wish that more digital forensics tools had command line interfaces. This short article summarises some reflections on the use of command line tools and the advantages and disadvantages that they offer.
The main culprit for this article was Ubuntu Server Edition which needed to be installed and configured to host some files on a network in my office and to run a couple of other services. The server version is a more lightweight distribution that is more suited to run as a file store, and as a result of this, the default installation consists only of a terminal interface. Use of a terminal only, for many, is relatively unusual, and while basic commands such as navigation of the file system and installing software packages are no problem once the commands are learnt, some activities that are normally very simple using a GUI are extremely frustrating. One example is downloading files from the Internet. The command wget is itself very simple to use, but if the URLs are long and are stored on a different machine, then there are few choices but to type the URL in. This is a slow, inefficient and error prone process, and is necessary for the use of many other command line tools. In short, after a day I had achieved what I wanted but was fed up with this backward, user-unfriendly means of interacting with a computer system…
Please use this thread for discussion of Chris's latest column.
I personally have a preference for the command line - this though has been carefully crafted from years of UNIX work, early experiences of dial-up modems for remote administration and SSh sessions.
Even now though, I administer my remote servers through SSh and spend a reasonable amount of time in either a Cygwin shell, the MacOS shell or a Linux shell. There are still benefits of bandwidth to be considered, believe it or not, in the 21st century, as often I'm onsite using my 3G dongle ( 5Gb a month ) and not only do I not want to pay extra, I don't want to wait for a GUI to download extraneous data that I don't need !
The main reason though, that the command line rules over all others, is, as you say, the ability to pipe output from on command or program to another, in an almost infinite range of possibilities. The ability to schedule otherwise impossible tasks through cron and to run things in batch mode run a close 2nd and 3rd too !
My issue with the point and click interface, weither it is for forensics, security or administrative use is that it seems to me to remove the requirement to understand what it is that you are actually doing - some would argue that you don't need to understand how a car works to drive it - however, in the case of point and click we are claiming to be experts, and charging accordingly, for an ability to put a tick in a box.
Command lines should be enforced on all CS students for at least the first year and only then should they be allowed a graphical user interface (ideally having written it from first principles in machine code … 😉 )
I have taken an Intro to Linux course and just finished a UNIX Admin. course and both were all CLI. The reasoning is that if you know how to accomplish a task with the command line then you shouldn't have any problems when using the GUI.
Prior to taking the Linux course a few years ago I avoided the CLI as much as possible. I have since come to enjoy using it.
Don't confuse command line and Unix shell here.
Unix shells provides a command line, but the benefits mentioned are those supplied by the particular shell, not by Unix, or the command-line.
For another kind of command line, try, say. a telnet or ftp client that's also a command line interface. Or Kermit, if that's still around. Command line, but very much different from Unix sh, as there's no command piping. (Scripting was present in Kermit, I think, as command files.)
But that flexibility in Unix comes at a cost a command (ls, cut, join, grep, …) must follow certain rules, or they cannot be piped well. There must be no 'beautification' for the human eye when output is piped, for instance, as that makes parsing needlessly complex. Tools that don't follow those rules, simply won't fit in – they're not fully Unix. In fact, such tools, no matter if they are invoked from a command line, show all the characteristics of many GUI-based tools they seem wedded to the idea that there are no other tools to consider, and consequently lock you in.
GUI tools can be useful, but that, too, takes a certain discipline from the tool maker. Keyboard navigation is far too often missing or wrong, for example. And *all* screen contents should be possible to copy/paste, and even save to a file, not just those that are easy to do. Making a good GUI tool is much more of a software engineering exercise that many toolmaker care to admit.
I think it's a good idea to provide command line (or scripting support) in GUI applications, even though it means more extensive design work to make the pieces fit together. Many needs can be served by simpler means, though.
As a developer I hate the command line for anything more than a simple dir / ls command
I would like to suggest a slight change of the topic. What the command line often gives is the chance to pipe the data through several different functions. What I think we need is a standard way to pipe data in GUI programs.
The command line syntax is often very hard to implement, and for an occasional user, very difficult to remember. Anyone should beable go to a GUI program and work out how to use it - and hopefully, if stuck F1 will provide a separate help screen.
Ugh this is another one of those Mac vs PC, or "I use notepad to create websites" type of issues.
Both GUIs and command-lines serve different purposes; and using a command line versus a gui does not make you a better analyst in any way.
Understanding when to use either method is all that it takes.
Ugh this is another one of those Mac vs PC, or "I use notepad to create websites" type of issues.
Both GUIs and command-lines serve different purposes; and using a command line versus a gui does not make you a better analyst in any way.
Understanding when to use either method is all that it takes.
That's my take on it. I certainly have preferences when it comes to user interface design and I've recently been rediscovering the joys of using the Linux command line through tools like the SANS SIFT Workstation. There is a time and a place for everything. I like my GUI tools and my command line tools.
I would agree slightly with the above, that there is a time and place for everything, however, my experience, 10+ years worth now, shows that - in the administration world at least - a GUI encourages laziness on the part of admins in understanding the fundamentals of what they are doing.
In the security space, we laugh out loud at "script kiddies" - those who excecute code provided by others, without understanding what it is actually doing. This attitude really should pervade for other things too.
Going back to Athulin's comments - I don't think that we've confused the two - a UNIX shell _is_ a command line, as is a DOS prompt and the Cisco IOS - yes, there are also CLIs to applications - FTP being one of them, Telnet, as you say, another. However, where you list commands, these are not part of the shell, these are stand-alone applications - the shell is primarily a scripting language, and provides some niceties - tab completing, prompt change etc. They do _tend_ to conform to a standard for the command syntax although as with all good rules there are exceptions (ps for example) - however there are a myriad of outputs with a range of "beautifications" - to be fair, in an 80x40 window these tend to be columns - and the output needs only to conform to being output to stdout in order to be piped to the next command, it is upto the piper to filter and process the output of one command into the next using the available tools - grep, sed, awk etc. and the infinite pipe chain allows plenty of flexibility in doing so. "ls" and "ps" are both good examples of programs that output in a perfectly readable human format that is simple enough to parse.
mscotgrove said "The command line syntax is often very hard to implement …", in comparison to a GUI that seems a little difficult to believe, I'm not a great programmer by any stretch of the imagination, and one of the reasons that I know that is that I can manage a command line interface with no problem at all - however all I can get out of a GUI is a "Hello World" text box (with a "Close" button if I try really hard)!
GUIs do make things easier, and I use them constantly, (they help me keep all of my open shell windows in order for a start!), there are so many tools that I wouldn't even consider going back to (anyone else remember WordPerfect for DOS ?, I've not used either Lynx or Pine for a long time either …), and the right tool for the job is common sense to all of us who have put in a screw with a knife blade …
I'm really happy working at a command line, since I started hacking my C64 to work out how computers work when I was 15. (That's the proper meaning of hack, not the criminal meaning of hack.) Then I worked in DOS environments before Windows had any real market, studied the unix command line in Uni, and then worked with FreeBSD and Linux in my forensic jobs.
I generally prefer a GUI when I'm having to look at large amounts of data, and for things like selection, copy and paste. For the longest time I preferred to use BSD scripts for imaging, but now I'm lazy and use a Linux GUI (or FTK Imager) for that. However, it's great being able to drop back to the command line when something fails (x-windows won't run, or a GUI script/program breaks) and be able to image by hand if needed.
If you're serious, you should have the underlying knowledge for when automated tools break, but there are many times when a GUI is more efficient for reviewing data, which is a larger part of our work than running processes.