Feeds

back to article Sysadmins! There's no shame in using a mouse to delete files

I am curious about the thought process of some systems administrators. When Linux is mentioned in an El Reg article, the discussion in the comments section can collapse into a tired debate of GUIs versus CLIs: a bitterly fought war over point-and-click visual interfaces in software versus typing out lines of commands and reading …

COMMENTS

This topic is closed for new posts.

Page:

Anonymous Coward

Things move in GUI's.

The cynic in me believes that this is to sell training with every version (Oracle, and your enterprise manager - I'm looking at you!). If you use the CLI then you only tend to have to learn things once.

There is nothing more frustrating than knowing a feature exists, but not being able to find it. Which is why I spend about 20 minutes swearing profusely when someone gives me something to do in office 2007+

13
0
Silver badge
Unhappy

Re: Things move in GUI's.

Which is why I spend about 20 minutes swearing profusely when someone gives me something to do in office 2007+

Yeah. I really miss clippy :(

5
0
FAIL

Re: Things move in GUI's.

Even worse than the location of GUI elements/widgets moving is the unholy piece of shit that is known as 'FriendlyTree' -- where when you drag a folder or files, folders open and close below it.

People that think this is a feature need to have horrible things done to them. It is the sole reason I refuse to use GUIs on Windows-based servers for file management -- you've never lived until you accidentally did that little fiddly click-swipe, and your critical files disappear into the nether regions of a random directory. Unless you're watching like a hawk for it, you will be well and profoundly screwed.

Yes, you can turn it off. Usually after you got burned by this product of the morons in Redmond.

3
0
Anonymous Coward

Re: Things move in GUI's.

I worked out where most the stuff I needed to use was before clippy existed.

Although you get points for reminding me of an old boss who must've been a fan; all you could hear all day was 'ting ting ting' as he worked away.

1
0
Anonymous Coward

Re: Things move in GUI's.

Dragging? You heathen! That's what cut and paste / paste into folder* is for.

*horrible word, you mean a directory, right?

3
0
Meh

Re: Things move in GUI's.

regarding the friendly tree accidental drag and drop issue: Usually CTRL-Z will undo this in my experience.

4
0
FAIL

Re: Things move in GUI's.

There is nothing more frustrating than knowing a feature exists, but not being able to find it. Which is why I spend about 20 minutes swearing profusely

If I know a feature exists but don't know where it is in a different version, then I click Help and enter a few keywords to show me what I'm looking for. The problem is so called 'IT Professionals' consider using Help beneath them, although if an end user asks them something 'stupid', then they're very quick to ask why they didn't use the Help function first.

2
0

This post has been deleted by its author

Anonymous Coward

Re: Things move in GUI's.

Yeah, that might might work for office. You try doing that in anything Oracle have ever made, ever.

Google usually works a lot better than in-built help, with it's shitty, invariably broken search function.

1
0
Anonymous Coward

Re: Usually CTRL-Z will undo this

Yep, fuck up with the pointy-clicky thing, and it's back to the good old keyboard to fix it. Par for the course.

0
0

Re: Things move in GUI's.

Ah the wonders of control z to undo eh?

0
0
FAIL

Re: CTRL+Z

Yeah, it works just fine if you were trying to do task A, something went wrong, and you knew about it when it happened. Again, the problem is when you do the click-swipe thing, and don't catch it immediately.

0
0
Bronze badge
Mushroom

Re: morons in Redmond.

I have learned a few years ago, it is best to stay away from the crappy software foisted upon the world created by those morons in Redmond.

0
0
Bronze badge

Re: swearing profusely

Is what I do when a WindblowZE using family member requests my assistance in fixing their fucked up system.

To deal with them, I have had a business card printed up, which looks like this:

http://www.cs.mcgill.ca/~kwysoc/windows/DontDoWindows.gif

0
0
FAIL

Re: Things move in GUI's.

How exactly would doing it in a command prompt make an excel task any easier?

1
1
Gold badge

Re: Things move in GUI's.

I wonder, does Lotus 123 from back in the day count as a CLI spreadsheet? No mouse interface on that...

0
0

The right tool for the job...

Use whatever works best for the task in hand given the constraints of the systems on which the task must be carried out and don't worry about the dyed in the wool CLI or GUI evangelists...

17
0

Re: The right tool for the job...

I was thinking about scripting yesterday. I used to write code for a living but don't much any more and, to my shame, am pretty rusty. Also I don't know any one command line inside out and so couldn't write anything but the simplest of scripts from memory. If I need to do anything more complicated, I need to reach for reference manuals (metaphorically speaking (I really mean 'man', /help, --help, Get-Help or google)). That means I often find myself staring at a command line weighing up if it is going to be quicker to manually enter a series of basic commands and collating the information generated or spend time trying to write a script to do it for me. Given the size of the information sets I am dealing with it is usually the former.

I often feel a twinge of shame that I don't spend longer trying to figure out how to script it, but when it takes longer to script something than to get the results manually is that wrong? (I should qualify that question by saying if it was something I was asked to do regularly then I would spend the time to figure out how to script it and automate the process - like 99% of my existing repetitive work (don't tell the boss)).

2
0
Silver badge

Re: The right tool for the job...

Yes definately agree here. I perform at least 95% of what I do from the GUI. When the GUI is not able to offer the complexity for a given task I will move to the CLI.

There is no "ultimate" method, there is simply the method at hand which gets the job done. I won't argue that either is better, it's a case of both are good and when combined they are great.

It's like the Linux / Windows never ending debate, they are both great tools. You learn to live and adapt to their up and downs. At the end of the day I really don't care which system I use, I have to get the job done and I will always find a method which will allow me to do it.

Any tool is only as good as the person using it.

4
0
Paris Hilton

Re: The right tool for the job...

I'll be concise. Gui (mouse/wacom) only fits for deathmatching and photoshopping. If you do sysadmin tasks in GUI, you're a loser. Right tool for sysadmining is CLI, stupid

5
15
Silver badge

Re: The right tool for the job...

CLI? Real sys admins don't use a CLI. They use butterflies, stupid.

7
2
Bronze badge
Pint

Re: The right tool for the job...

Well said sir!

I use CLI for most day to day stuff at work as I know the systems and what I need to do, it's simply quicker to bounce about in the CLI on various servers. When I need to code Perl and shell scripts for work I use command line vi. Some SQL scripts I code in vi, some I use Oracle's SQLDeveloper GUI tool when I need to make a small change to an existing object in a DB. I use Oracle's Grid Control GUI console to get a quick overview of what a DB is upto, then I drop out to terminal session with my admin scripts to dig deeper into the DB problem at hand as I wrote them and I know them well.

When I have documentation to write, I push Linux desktop to one side and jump on to my virtualised Windows XP box and knock the documentation. Sadly it has to be written in Word and stored in Sharepoint, so I use a GUI to everything.

When I get home I use OSX GUI to work on my photos but I use a command line to rip off my DVD discs as Handbrake command line is the dog's wotsits on CLI, the GUI is awful.

I flip back and forth depending upon what is needed for the task at hand, neither is better than the other, just that I find more useful than another to get certain things done.

0
0
Anonymous Coward

Re: They use butterflies, stupid.

Yes, real professionals use the tool for the job, whether that's a gui file manager, a command line ...or a butterfly (God, even Emacs has its place!). Real professionals are not uncomfortable with that, and they do not feel threatened by it.

2
0
Gold badge

Re: They use butterflies, stupid.

I am now determined to somehow make a butterfly into a systems administration tool.

Thoughts on how this can be done?

3
0
Anonymous Coward

PS... they do not feel threatened by it

... Or feel the need to call others stupid for using what works for them.

0
0
Anonymous Coward

Re: butterfly tool. Thoughts?

Not yet, but if this becomes popular then I look forward to seeing yabt (Yet Another Butterfly Tool) in the manuals

0
0
Devil

Re: They use butterflies, stupid.

Butterfly = bug == random point of failure instance?

0
0
Anonymous Coward

I've actually found many of my CLI skills are transferable, with Windows Powershell being the obvious exception. The terminals of MacOS, Linux and Unix are all similar.. but then that's because they are all derived from or based on each other.

I've always been a mix and match kinda bloke though... I'll use CLI if that's the best thing for the job, or GUI if that is.

7
0
Bronze badge

bash and gawk

The terminals of MacOS, Linux and Unix are all similar.

For Mac OSX and most GNU/Linux :

:~$ echo $SHELL

/bin/bash

POSIX shells are very similar. As well as tools. However, on FreeBSD it took me awhile to figure out why some of my bash scripts did not work properly, even though the paths were correctly identified. Turned out, I had to use gawk instead of awk. Also FreeBSD tools utils are a little different, e.g., date.

1
1
Devil

Re: However, on FreeBSD

You ain't seen nothin' yet (TM). There are also SunOS(Solaris), HP-UX, Tru64(OSF/1), DIGITAL UNIX, AIX, HURD and so on, each with some shell/awk/find/etc quirk...

0
0
Gold badge

Re: However, on FreeBSD

@Ramazan

"Each with some shell/awk/find/etc quirk."

Some diverge more from "what you're used to" than others. The beauty of learning bash and other POSIX-like shells as "baby's first CLI" is that there are just so many that more-or-less follow the same rules. You don't have to relearn an entire CLI interface to get the job done (like moving from bash to CMD.) You mostly just have to internalise the exceptions and differences.

PowerShell is different for me here I think largely because a lot of the tools I got used to using with *nix operating systems aren't there. Chaining also works slightly differently, with the weird emphasis on OO shell structures, there are just some things that require a different headspace. (Linear scripting and I are just fine, but OO starts to wander outside my bailiwick.)

More to the point, some of the fundamental assumptions about system usage are different in Windows versus most POSIX systems. Flat-text configuration as one example. (Though I must point out that more and more I can just feed XML into PowerShell-compliant apps and that works. It’s a start.)

Where I start really getting outside my comfort zone though are programming-language CLI shells. Cshell, Rhino, etc.

That’s all a really long way of saying “I think it really matters which CLI is your first.” You never forget your first, and it deeply influences how you view and interact with CLIs forever. Using something like Bash is grand, because it’s close enough to all the other POSIX shells that you can adapt quickly.

Using a real outlier on the POSIX branch might not be as good; the mental list of “exceptions” to what you perceive as “normal” might be significantly higher than otherwise.

I can’t find much empirical research into the difficulties of learning (specifically) shells – nor the deltas imposed on cognition by different POSIX shells – but there is plenty into similar areas. GUI design – as one example – has had billions put into fundamental research on “how far from what someone first learned” you can stray before they get really uncomfortable or have a hard time. Similarly, keyboard design…even the design of musical instruments.

How much those “little differences” matter amongst similarly structured CLIs really could boil down to “which CLI you learned first!"

1
0
Silver badge

Tool for the job

A CLI is a tool.

A GUI is another tool.

The CLI is easily scriptable, a GUI usually not.

The GUI is often just a pretty wrapper on the CLI, but maybe not exposing all the features.

The GUI may not even be a desktop app, it could be in a browser.

The CLI is often backwards compatible, the GUI can change radically yet offer no new features.

Sometimes one is better, sometimes the other.

Learn both, their strengths and weaknesses.

Profit.

Leave the holy wars to the wannabes who think reading everything in hex makes them 1337.

26
1
FAIL

@Sometimes one is better, sometimes the other.

The only time when GUI is better for sysadmin tasks than CLI is when there's no CLI option at all (e.g.: braindamaged vendor like Microsoft).

4
10
Silver badge

Re: @Sometimes one is better, sometimes the other.

A GUI is better (generally speaking) when a graphical layout is better able to display the current problem/fix/layout/whatever.

At other times, a CLI can be better.

You pick the best tool for the job.

Did you know Windows now has a CLI back? I've not had cause to use PowerShell, but it is there.

0
0

Did you know Windows now has a CLI back?

Windows has cmd.exe, and you can always install some kind of POSIX environment like Cygwin there and run sshd, but this won't make it fully scriptable. My job involves systems integration and glueing a lot of things with Tcl/Expect (and bash and awk and grep and sed...). Good luck doing the same with Windows.

1
3
Bronze badge

super-gui or super-cli

May I suggest GNU Emacs, which maybe seen to unify the power of CLI and demonstrativeness of GUI, say M-|, M-!, dired, tramp etc? The ncurses stuff is very blessed type of tools too, like the orthodox mc :)

0
0
Anonymous Coward

Re: @Sometimes one is better, sometimes the other.

@Ramazan - You obviously don't really know much about Windows - Every single thing that you can do from the GUI (and more) you can also do from the command line.

1
0
Anonymous Coward

Re: Did you know Windows now has a CLI back?

You've obviously never heard of Power-Shell.

0
0
Mushroom

Re: Windows - Every single thing ... you can also do from the command line.

So educate me - lsof|awk|kill, umount, fsck, lvreduce/lvextend, cryptsetup, mkfs, mount, for the start, from cmdline. And we use Windows NT 4.0 in production BTW.

0
0
Gold badge

Re: Windows - Every single thing ... you can also do from the command line.

UMOUNT/MOUNT = MOUNTVOL http://ss64.com/nt/mountvol.html

FSCK = CHKDSK

CRYPTSETUP = CIPHER

MKFS = FORMAT

LVREDUCE/LVEXTEND = FSUTIL (Is this in Windows NT??)

4
0
Bronze badge

Re: Windows - Every single thing ... you can also do from the command line.

And how to properly "find" if I can ask?

0
0
Gold badge

Re: Windows - Every single thing ... you can also do from the command line.

@eulampios FINDSTR might do you...http://thesystemguard.com/TheGuardBook/CCS-Ext/helptext/FindStr-NT.txt.htm

0
0
Bronze badge

Thanks, Trevor

However, this one looks like semi-find, semi-grep semi-bulldog. I asked that question because I know there is nothing even getting close to "find" with its -printf, -exec, -regex, -type, -atime and so on in Windows.

If I need to grep it, I'd "-exec grep {} "or | xargs -0 grep"...

0
0
Gold badge

Re: Thanks, Trevor

@eulampios You are absolutely correct; until PowerShell, there wasn't anything grep-like. PowerShell 2.0 however...it'll take grep on.

In the Windows NT 4.0 world (which was the context of the original question,) nothing from that era of Microsoft software can match a modern grep command.

0
0
Anonymous Coward

Re: Thanks, Trevor

Of course you can either install the gnu grep for windows of me sfu, if you specifically want grep...

0
0
Bronze badge

In terms of computer *administration* (i.e. running networks, etc.):

If you use only CLI, you're an idiot.

If you use only GUI, you're an idiot.

Because each provides ways to do things safer, faster or more efficiently than the other. Hint: Repermission all files dated 12th of June, 2012, filesystem wide, so that user X doesn't have write access to them any more. You can do it in both, but one way will work better than the other depending on your experience and familiarity with the system. Now try to select 20 essential files out of 2000 by going through them and opening them up and assessing their contents. Similarly, just dragging a folder with Gb's of data to copy it is often a nightmare of needing to be in front of the computer till the bitter end (Ten minutes into the copy: "Are you sure you want to move this read-only file?" Yes to all. Ten minutes later: "Are you sure you want to move this system file?" Yes to all. And if you don't answer, you can wait forever and the copy will never complete). Not to mention the performance comparison between doing that via CLI and GUI. But, equally, I wouldn't want to manage an group-policy-like structure without a tree-based, multi-panel graphical app with help text.

An admin who uses only one, all the time, doesn't have enough experience of the other and is wasting time and/or risking accidents that could be avoided the other way. This is *why* I whinge when MS (and now Ubuntu) tries harder and harder to hide the command-line from me on my personal machine too. There are some things that are either a) not possible, b) not sensible (e.g. "mv" versus an undo-able drag-drop) or c) plain inefficient when it comes to using just one method of issuing commands.

And how, precisely, would you set up a GUI so that someone familiar with "sed"/"grep"/"awk" syntax could create the complex rules necessary for some tasks in the same amount of time? You wouldn't. I've run entire schools off sed and grep commands that are pages wide, something I'd have to write a graphical program specifically to do if I wanted a pretty button that did the same.

7
0

Different tools for different situations

Completely agree with you. I regularly use both method, with the choice depending purely on which is more suitable and convenient for a given situation. If I want to do the same exact task lots of times then being able to script and automate it is fantastic, but for those simple tasks I do once in a blue moon I'd never remember the specific command, but a GUI is easy to remember.

I loved it with SQL 2005 when they introduced the option to generate the script for what you'd just setup in the GUI. It might not have been the most efficient code, but for something I want to run at night once a week / month I don't care, it's not worth spending hours working out how to script it manually. On the other hand, I hated how MS decided with Exchange 2007 that lots of functions (including some simple day to day ones) should be done exclusively via PowerShell! Why? Allow me to do everything via either interface (allowing for some specific, unusual, high level options you couldn't fit into the GUI) and let me decide which one suits my current task.

GUI wizards may be simplistic at times, but they do make delegation of simple tasks to junior staff much easier. I can show a junior how to run through the wizard and be confident of them not screwing anything up, at the command line I wouldn't feel as secure. But having the command line option means I can use that method when something more complex comes along that the GUI can't handle.

1
0

@Lee Dowling

I agree with everything you said, but I upvoted you specifically for this:

"Ten minutes into the copy: "Are you sure you want to move this read-only file?" Yes to all. Ten minutes later: "Are you sure you want to move this system file?" Yes to all. And if you don't answer, you can wait forever and the copy will never complete"

Grr.

1
0

It's all about automation, which is usually via CLI.

3
0
Bronze badge

I agree with Trevor

I make use of CLI for some things, and GUI for others, across a wide range of server and desktop operating systems and differing network appliances.

Some of the appliance GUIs available are excellent, obviously well thought out, others not so much, just as is the case with the operating systems.

I fail to see the need for the snobbery associated with using a CLI for everything, it can be work for work's sake sometimes.

1
0

Page:

This topic is closed for new posts.