Script vs. graphical tool

Introduction

guivsscriptCommand line or graphical application, typing or clicking, for geeks only or for lamers too?

When I was in college I often heard that Linux is for professionals who know what they want to do with their computers and Windows is for office workers who play Solitaire. Why was that? Was it because a few/several years ago in Linux you had to do most of the configuration in shell so you had to know how to do it, which command execute and with what parameters? While in Windows anybody could just go and change half of the system just using a mouse. The only key thing was to know where to go to find the right check box.

 

Why the simplicity of Windows has created so many opponents of this system? Some time ago, five minutes of famous had Gentoo, a Linux distribution where most of the apps had to be compiled from source code to install them. There were some reasons behind it but compiling Open Office took 6-10 hours when installing MS Office on Windows was about 30 minutes. Is the simplicity that bad to spend a few times bigger effort to do a simple task? No, I don’t want to go into endless Windows vs. Linux discussion … I am just mentioning it because I think it is closely related with the topic of this article – script vs. graphical tool.

In the past configuring Linux was mainly executing commands and writing shell scripts, on Windows everything was done with graphical tools, scripting was extremely painful.

Now, you can use Power Shell for Windows and more and more configuration options are available on GUI for Linux. Even Linux dedicated Oracle tools have graphical interfaces (like ASMCA, Oracle Universal Installer). DBAs using a mouse to set up a database cluster … sounds strange, doesn’t it? But it is a reality. Is it bad?

 

Battle

My experience shows me there are cases when configuring something with a mouse on GUI is not the best way. A few reasons why command line might be more suitable:

  1. Automation and repeatability
    It is incredibly easier to automate a sequence of steps when all of them are commands. If you want to apply the same configuration on multiple servers, most likely it will be much easier to do with a script than manually clicking on a graphical tool.

  2. Accessibility
    A DBA not always has an access to run a graphical tool. Sometimes all you have is SSH connection. I know, you may be surprised, but in some organizations roles separation has gone so far that there is no chance for you to run graphical tool or it is complex. On Windows if you have remote access it is usually Remote Desktop so this point does not apply.

  3. Testability
    Which one is easier to do:
    • go through ten screens in GUI tool on a test environment and repeat exactly the same process (because it was tested) on a production
    • or to write a script once and execute it on test environment and production with different parameters?

    In most cases the second option.

  4. Traceability
    If after a few days you noticed that the system does not behave as expected, it is much easier to find out what was actually done by your change when all you did was executing a script rather than using a graphical tool. You can just take a look at the script what it did instead of trying to remind which option you selected on GUI. I know, many tools still allows to save output to a file … it is a kind of a solution.

  5. Productivity
    If you spend enough time working with a set of commands you will gain higher productivity than doing a similar action for a thousandth time on GUI.

 

Of course there is also the other side. Reasons that fight on the GUI tools side:

  1. Easiness
    If you are a beginner in a particular technology, you may find a GUI tool better because most common options can be easily discovered. Even if you see the tool for the first time, there is a big chance you will use it properly. When it comes to a command, you have a manual or the internet which is not simpler in my opinion.

  2. Obviousness
    It is easy to follow someone’s using a graphical tool. You can say what that person is doing. Probably you are able to repeat the same steps to achieve the same result just by seeing it once. Contrariwise, following someone’s shell is sometimes difficult. Not intuitive command switches do not help. If you don’t agree - if you don't use this combination, can you guess what it does –ls -ltu in Linux? -l adds more columns, -t sort by modification date, -u as manual says "with  -lt:  sort  by, and show, access time with -l: show access time and sort by name otherwise: sort by access time"–u sorts by access time, seriously?

  3. Files selection
    If you need to commit multiple files from many different directories to SVN and you really want to do that through command line, there is no way to say it is user friendly:
    svn ci com/company/MyClass.java com/company/dao/User.java com/company/process/UsersCreator.java /com/company/conf/initialization.xml
    This example commits only 4 files which is unusual. An average commit consists of much more files. In GUI like TortoiseSVN it is easy peasy.

 

Verdict

It is important to emphasize that the reasons listed above are not equal and cannot be counted up and the numbers compared. Many depends on a usage, users skillset etc. Productivity point is not the command side if we are talking about one time use. Easiness does not give an advantage to a GUI tool if you need to repeat the same steps on 20 different machines.

Verdict cannot be different than "it depends on the case". Yes, I have been going to this statement from the very beginning.

But I still hope some of you found the text useful :)

We use cookies

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.