Why do software tools often make us go and type commands into the command line? I don’t understand why so much software does this. Why can’t we just click a button and everything is automated or use a GUI?
I often avoid software if the guide tells me to open the command line and type some commands because I can come across problems. They may have something to do with my lack of experience but why should I have to use the command line?
I hate typing commands into the command line! I prefer software that is automated as possible.
Although this seems a bit unrelated to what I have just been saying, I also hate it when software uses an annoying project format. For example, I had massive issues trying to get Visual Studio to work because of some error in some sort of XML document which seems to define the UI (from what I can remember). Why doesn’t it just block out the ability to tamper with the XML files. Tbh I do not even think I touched the XML files but I probably did something wrong which interfered.
This is no rage, I am not even frustrated I am just curios to see what people think. As far as I can tell, this annoyance does not particularly apply to Xojo even but it is just a general thing which I dislike.
Legacy operating system level code, or OS commands that may be used by other parts of the operating system… These would be things that an end user doesn’t need to interface with often (or at all)
Things where a GUI makes NO SENSE… this for example is one reason XOJO (and other tools) can create “console” apps
This may also include utilties on a computer where the operator needs to interact during a startup procedure to issue commands before the GUI protocols have been initialized…
[quote=161979:@Dave S]1) Legacy operating system level code, or OS commands that may be used by other parts of the operating system… These would be things that an end user doesn’t need to interface with often (or at all)
Things where a GUI makes NO SENSE… this for example is one reason XOJO (and other tools) can create “console” apps
This may also include utilties on a computer where the operator needs to interact during a startup procedure to issue commands before the GUI protocols have been initialized…[/quote]
I agree with your points however my problem is not with just simply the whole idea of the command line but my problem is when you have to manually copy commands when following instructions for an installation (for example).
I am more thinking about how you are required to follow a guide for installing things when really you just want a one-click solution rather than having to write for the command line. Shouldn’t tools give you the option for an easier (possibly less customized) installation) than copying commands from a guide.
[quote=161982:@Oliver Scott-Brown]I agree with your points however my problem is not with just simply the whole idea of the command line but my problem is when you have to manually copy commands when following instructions for an installation (for example).
I am more thinking about how you are required to follow a guide for installing things when really you just want a one-click solution rather than having to write for the command line. Shouldn’t tools give you the option for an easier (possibly less customized) installation) than copying commands from a guide.[/quote]
In general, a well built installer should carry out all these command line operations transparently for the user through a shell.
But some (sloppy) developers, especially when it is assumed the user will be another developer, often (carelessly) neglect creating a proper installer. Ensue a long list of things to do that the (unclean) guy could have programmed.
As a general rule, no user should ever have to enter the command line today.
But for the developer, using system commands and shell is often key to quickly get a good result in minutes, instead of reinventing the wheel. System engineers have worked since the inception of computing to bring powerful commands that are here for grab through a shell, and that is truly valuable.
For some reason, because it is so easy to use, some snobs will tell you the shell is inferior to API calls. They often do not realize that the very commands they put down have been written by the engineers who created the API
I can’t remember the last time I had to open the command line. What kinds of tools are you monkeying with? I hear the Mac guys talking all the time about using Terminal. You unix guys really love your cryptic command line tools, don’t you?
Linux in general - lots of things aren’t possible except via the cmd line
Linux servers - I dont know anyone that has a gui installed on one
Lots of fun Unix tools in OS X that you CAN take advantage of but, unlike Linux, its not “required”
Nightly build tools - they’re almost invariably run by something that just does cmd line based builds
Oliver, not all functionality is exposed in the GUI. Often there are advanced/niche features that are accessible from the command line. OS X is full of them. The other reason I use the command line daily is to SSH into remote computers and servers - it’s much more lightweight to do that than use something like VNC or Teamviewer to take control via the GUI.
I have a couple apps in the MAS that simply wraps functions that are not available otherwise in a user friendly UI. Customers are grateful to have the features without need to learn Unix.
I know several members who do the same.
On PC, in the early days, PKZip did not have any UI and was command line only. Then developers created UI wrappers for it, and eventually the light dawned on the creators of the format who at last thought about the user, instead of their own nerdish selves
To be fair, most of the intricate things in Batch are not necessary for everyday use. But sometimes, you do find a nice market helping users get results that were possible only with command line.
Even today when you are working with Microsoft Sharepoint or Windows Servers you have to use PowerShell Commands to tweak the system. No Gui exist for that, as the systems has tremendous of features, that would require to much maintenance to have a gui interface for that. Only way Command line.
The simplest way to zip/unzip a file on the Mac the way the Finder does it is to call ditto on the command line. The easiest way to find out about a system is to use system_profiler. And that’s just off the top of my head. There are a million tools to take advantage of behind the scenes without losing the GUI experience.
I can’t speak to others, but I can tell you why I mask super features from the GUI user. On average, a GUI app user is generally less computer savvy than the user that should have a need for some of the hidden features. If the GUI user can’t click on a button to shoot themselves in the foot, my support guys don’t need to worry about performing triage on those users. On the other hand, the user that understands the importance of the command line also understand the fact that they “could” shoot themselves in the foot and also know what to do if that happens.
In another pair of tools, we send users to the command line to remove the GUI overhead from the resolution steps - and in one case, remove the potential for the GUI’s code to mislead the user as to what actually happened.
In fact, to open up a whole new world of usefulness for your Mac, I recommend Mark Sobell’s “A Practical Guide to UNIX for Mac OS X Users”. It’s old, but the general rules are still the same.