Many freetards think the CLI is the ultimate in low level communication with their operating system. They scoff at the notion of using GUIs and point-and-click interfaces, claiming them too dumbed down for their elite keyboard skills.
In a way, they’re right. This is a very low level way to communicate with the OS…FOR HUMANS! The CLI, like a GUI, is a human interface. This means it was built for humans to interact with their computer back in the days when it wasn’t possible to render GUIs. The original CLIs were printers. You typed on the keyboard and the printer spat out the results. A result which no computer can use and is specifically designed for human consumption.
But what could possibly be lower than the CLI? An Application Programming Interface (API), that’s what. This allows the application you’re writing to communicate directly with the OS, without having to open shells in the background or wrap human-readable text commands. Instead, you issue the command directly, with no conversion required.
Many CLI zealots don’t know what an API is, however. They believe the CLI is the API. They think that to manipulate files on the file system with their application they simply need to wrap bash commands. If only they understood what bash was actually doing under the hood…
CALLING AN API!
Automating with the CLI is akin to building a robot with fingers to type on a keyboard in order to transcribe one text file to another. Or using a mouse-simulator to click buttons in a GUI for you. Sure, it works, but why not just tell the API in the OS to copy it for you?
Comments
Nice. Some 15 year old kid tells you that he wrote some perl scripts where he included a lot of system() functions, so it obviously means that freetards think CLI is API.
It goes far beyond some 15 year old doing it; Plenty of applications use it or suggest using it to automate their tools.
Want to encode something using FFMPEG? Just wrap the CLI! All you need to do is continuously scrape stdio to determine if the process succeeded or not! So handy!
It’s a mindset caught somewhere between laziness and ignorance. Laziness for those involved who know how to make an API but don’t, and ignorance for those who think the CLI is as low level access as you can get.
Nice. Some 15 year old kid tells you that he wrote some perl scripts where he included a lot of system() functions, so it obviously means that freetards think CLI is API.
Why, have you not seen a GUI app piping output from a CLI tool to the screen before?
There is a difference. Those GUI apps that you are talking are actually meant to be CLI apps, with just a GUI wrapper around them. And guess what, they work, and reinventing of the wheel, ie well tested commands, is avoided.
“Want to encode something using FFMPEG? Just wrap the CLI! All you need to do is continuously scrape stdio to determine if the process succeeded or not! So handy!”
Don’t remind me of how many linux tools are just wrappers for CLI apps. Is it so hard for these guys to take teh open source of the CLI app and make a brand new GUI-based app? (answer: yes, because they are lazy and code using exlclusively long php codez)
The instanity hits record high when the GUI based tool/wrapper/frontend hides all the messages the CLI app beneath spews out, in an effort to be “user friendly”.
Nothing compares to the joy of File Roller not decompressing your zips, and not putting out any kind of useful error message whatsoever telling what went wrong, and then having to click on “show command line output” to get some glimpse on what was going on.
WinRaR on the other hand, actually shows you error messages that are understandable!
I don’t know about you, but Windows is just to dumbed down for my l33t c0mputing skilzz
“And guess what, they work, and reinventing of the wheel”
That really goes and shows how much you know about implementing an application properly, doesn’t it?
Seriously, why pass properly boxed messages to your front-end when you can give it random bytes that look all the same to it to sort out, preferably with flaky regex acrobatics if not, say, strtok()?
“There is a difference. Those GUI apps that you are talking are actually meant to be CLI apps, with just a GUI wrapper around them.”
That’s the whole point. There should be no need to wrap the CLI with a GUI. Both the CLI version and the GUI version should be able to talk directly to the API.
By making an app CLI-only, you’ve essentially hard coded a single UI into the app. Meanwhile, any application or system that supplies an API can have any interface you want bolted on to it without needing to tediously wrap it.
Think of accessibility interfaces for the blind or deaf. Think about voice control, etc. all of these would need to be wrapped from scratch, while anything consuming the API will just introspect it and generate the interface out of it.
For example:
http://blog.fogcreek.com/cheeky-python-a-redis-cli/
In this blog entry, the author creates a Redis client on the CLI using Python by reflecting the Redis API. The result?
“A full-featured, robust, well-documented Redis CLI in about 60 lines of code. For comparison, the C version is over 500 lines of code, and has no help documentation or code completion.”
Adam Queen said that you only need to implement a file I/O and CLI and Linux allow you everything!
Can your 'API’ do that as well?
Also, remember that the API can change every second and the CLI output is unlikely to change suddenly. ( UnstableAPI, StableCLIOutput )
I think the dominance of CLI scraping over an 'API’ is obvious.
Well obviously a stable API is helpful, but the reason the CLI can usually keep up with API changes is because it can essentially reflect the features of the API. However, this can be accomplished with a framework or some other “stabilizer” that doesn’t require the use of strings to communicate between components.
Which is done in Windows by native API / Windows API separation.
Anyway, CLI scrapping is plain retarded, obviously. Still, if you script using bash, many applications (ie curl or mysql) can’t be done better because you simply have no API. You can’t send abitrary HTTP request in the order you need it, because there’s a layer between you and the API.
MySQL also loves mongling them script files. How do I get the output of a MySQL query with bash again? Oh wait.
Windows had the same issue in the CLI environment ( wmic for instance ) but it was never to tragic because you could evade the CLI and just use the GUI or VBScript.
Ironically, Exchange 2010 does the same. The management console is a GUI for a CLI ( PowerShell ) environment. ( only the commands are not sent per CLI window, but rather per PowerShell SDK, so it equals an API ) Still there’s the major difference that PowerShell is OO’d and works way more like Python than bash. You can query objects using verbs and as of such have an API. That’s also fine then.
But pure text is really 1980s. I like how tzselect finishes its execution with this line:
“Here is that TZ value again, this time on standard output so that you
“
can use the /usr/bin/tzselect command in shell scripts:
When I first read this I thought it was a joke, but no.
Anyway, CLI scrapping is plain retarded, obviously. Still, if you script using bash, many applications (ie curl or mysql) can’t be done better because you simply have no API. You can’t send abitrary HTTP request in the order you need it, because there’s a layer between you and the API.
Why would you use curl when you could just use the native sockets or http request clients that any reasonable programming language has?
Likewise, you can connect directly to mysql, or any database for that matter, without using a command line. It’s not like I have to use the mysql shell to query a database.
Don’t know if you are aware of Compiz Configurations Settings. I am pretty sure that it is a GUI wrapped around a CLI. But, it has an elegant interface, it is very flexible, and it works.
The question is why? Why don’t they just build an API so you don’t need to wrap a CLI.
Did you even look at the link I sent you? The C version of the Redis wrapper is huge because they have to manually wrap each piece of functionality. The Python version is tiny because they simply reflected the Redis API and let it automatically generate a CLI based on that. It would equally trivial to have a GUI generated from the same introspection.
Just read your post replying to me.
“Why would you use curl when you could just use the native sockets or http request clients that any reasonable programming language has?”
What I meant was, it can’t be done better in text-oriented shells, because you somewhat have to wrap the API (sockets/http requests) to provide bash accessibility.
“It’s not like I have to use the mysql shell to query a database.”
No, and it’s pretty unflexible, also. MySQL and HTTP are actually pretty good examples where you’d have an API, which you only try to make accessible from bash. Still, it’s pretty useless, because anything exceeding a pure filedownload or as for mysql, a pure file dump/import, becomes hell.
The CLI app is in your way to the API then.
“Don’t know if you are aware of Compiz Configurations Settings. I am pretty sure that it is a GUI wrapped around a CLI. But, it has an elegant interface, it is very flexible, and it works.”
Which would make one example of how it should be. Still there are dozens of examples doing otherwise. I don’t think what was mean here that all *nix GUI apps do this, but certainly a lot do.
I don’t see where Compiz comes into it. No matter how spiffy the interface is, and how neatly spliced everything is, and how wonderfully the configuration works, the fact remains that it Lacks An API.
With a (stable) API, it could be all of these things with far less effort and, I would suggest, it would be easier to maintain and debug and test (which hitherto has not been part of the argument).
What does it gain from crippling itself through working on a CLI basis?
This is like saying you should recite Homer by heart, rather than read it from a book. Sure, it’s possible. Sure, it’s an amazing feat. But it’s also a total waste of time, and error-prone, to boot.
“CALLING AN API!”
I don’t you actually know what an API is
http://www.computerworld.com/s/article/43487/Application_Programming_Interface
“You often have to rely on others to perform functions that you may not be able or permitted to do by yourself, such as opening a bank safety deposit box. Similarly, virtually all software has to request other software to do some things for it.
To accomplish this, the asking program uses a set of standardized requests, called application programming interfaces (API), that have been defined for the program being called upon.”
The argc,argv parameters to main are the closet possible thing to a standardized API. This is exactly what Bash uses to wire processes together.
I’d also like to mention that Plan 9 (and to a lesser extent Linux and Mac OS X) implement many kernel APIs through the file system. Which is of course an alien concept to most Winbreds, who assume API means “flat file full of C functions” or something silly like that.
Ah… the second reference to Plan 9 I’ve seen in the last few minutes. Glad to know you are afraid to use your name at LHB and have also resorted to Anonymous.
“The argc,argv parameters to main are the closet possible thing to a standardized API. This is exactly what Bash uses to wire processes together.”
I, for one, am amazed by the fact that Adam is unashamed to tell everyone his inability to understand the difference between command-line arguments and data.
Right, command line arguments can’t hold data? FFS man?
So tell me JoeMonco, oh master or arbitrary assigning meaning to words, what is your definition of “data”?
“Right, command line arguments can’t hold data?”
Pfft… Sure, why not?
Honestly, even the most abject of retards wouldn’t confuse the knobs on a washing machine with the laundry.
tsk I’ll let you in about a secret, fellows – just don’t tell Adam about it:
http://www.makelinux.net/make3/make3-CHP-5-SECT-6
You must be signed in to leave comments.