Oh, I’ve seen that before. Try to watch the video without laughing at the guy who recorded it. I for one can’t.

Yeah you go ahead and use the unintuitive and slow online ordering system.

This is just one example of why GNU/Linux is awesome.

And those flags are intuitive, right Adam? I doubt you actually use Linux, you’re probably some troll account cooked up by DrLoser or something to further discredit the freetards.

Adam, let’s see you order a pizza using the CLI without the manual.

So what. You only have to read it once. You can alias your fav pizzas to things like “gimme_a_mushroom_pizza_plz” or something. I’m sure some of you didn’t even know that was a possibility.

Or, you can buy a pizza from Microsoft Chefs for a few dollars on your credit card.

That’s the inferiority of GNU/Linux. It needs improvement.

Yeah you go ahead and use the unintuitive and slow online ordering system.

This is just one example of why GNU/Linux is awesome

Exactly. What if you order a pizza or two everyday? What if you want different configurations for your pizza for different days of the week, or different times of the day? Try doing that with an online form.

Fail site can’t process HTML tags, and the “downvote” leads me to the image of the arrows.

My bad. I was using the NoScript extension.

Adam, no I only find it amusing how one would even think of writing such an app.

btw, the guy’s site to download the script seems broken.
I can’t see thus how he does it, but I suppose some nice curl script or such.

Anyway, PowerShell does have HTTP access classes, too. You could port it thus. Could if you really believe you need a CLI pizza ordering application. In fact, you could even use DPAPI to store the creds in encrypted form. Again, if you’re very bored and hobbyless.

“Notice that quantity is it’s own flag, meaning that no matter how many pizzas you order, they all must have the same toppings.”

LMAO! That’s the Linux way babe!.

You can have as many pizzas you want as long as they all have a piece of turd instead of sause* and melted condoms instead of cheese**

• Xorg

• PulseAudio

http://www.youtube.com/watch?v=x7pPajOvQGo#t=1m21s

LOL, notice something? ( tip: start button ).

Rofl, he’s using a terminal emulator on Windows as well as I can see some Xorg running on Windows there.

@Adam, except that every online pizza ordering form keeps a history of what you ordered so you can not recall old orders but modify them as well.

Wow TM Repo man, so you went to “every online pizza ordering system” and confirmed that statement. I commend you.

Now that’s having nothing better to do with you time…

Dominos, the one, and only, supplier that the Pizza Party app does have order saving and recall. The difference is, I don’t have to remember to make an alias, it just keeps a history for me.

I encourage you to move the goal posts and claim that this is no big deal though, since it’s just ordering pizzas. Well, this is indicative of the FOSS community in general; Making something cumbersome then trying to convince everyone that they’re wrong for wanting it to be easier.

Does Dominos’s website support cronjobs?

That’s always my biggest issue, having pizzas delivered on a timer. If your life requires scheduled pizza delivery, you’re pretty pathetic.

Put it this way, if you think the CLI is better, then why not just write out the JSON string to send to their rest API. I can do it, so why can’t you?

That’s what I am trying to get at. The CLI is a perfectly useful programmatic interface.

No it isn’t! The CLI is a HUMAN interface. It’s just that when the invented it, the computers weren’t capable of displaying anything else.

Hell, the original CLI was a dot matrix printer. You think that they were feeding that dot matrix output back into the computer? NO! It was being read by the humans running the computer.

You are right, Bash scripts don’t exist. /s

It’s a dumb myth that Bash is the same as the shell UNIX had in the 70s. It’s not even remotely compatable to csh which would be a modern shell in comparison to the old UNIX shells.

These days shells are full programming languages in their own right. You got complex string manipulations, collections including lists and dictionaries, globbing, etc. build all right into the shell. And in fact it’s quite easy enough to call into Perl or Python or TCL from a Bash script to do more complex processing if needed.

I never said bash didn’t exist, what I’m saying is the CLI is meant as a human interface.

Scraping command output is the most inefficient way of automating a task when you consider the much richer and more direct access other languages have to the operating system’s functionality.

Scraping and parsing strings is as hackish as scraping html pages rather than using a RESTful API. Scraping is analogous to doing those dot matrix printouts only to retype (parse) them back into the computer. Scraping is like building a machine to type on a keyboard when using a direct connection over a port would be faster and less prone to error.

The analogies are endless for this. The CLI is essentially a “wooden table” solution.

And it still stands that the CLI is about the worst way you could order a pizza. Even phoning one is is more intuitive than this horrible interface that requires a manual to figure out.

Hmmm, did -p order pepperoni or peppers?

“Scraping and parsing strings is as hackish as scraping html pages rather than using a RESTful API.”

Considering PowerShell does have System.Net.HttpWebRequest as well as it can load assemblies such as JSON.Net, you could access RESTful services from Windows CLI.

“And in fact it’s quite easy enough to call into Perl or Python or TCL from a Bash script to do more complex processing if needed.”

Which is terrible glue. Each of these has an entirely different framework which results in a weird mixture between those.
Also, try to do something as simple as to read an XML file in bash – http://stackoverflow.com/questions/893585/how-to-parse-xml-in-bash or http://www.humbug.in/2010/parse-simple-xml-files-using-bash-extract-name-value-pairs-and-attributes/ JUMMY. Or try to call a function withing a shared object file. Or try to encrypt a file using AES.

All the above examples would be easily doable in PowerShell – which was designed from scratch and does not base on the predecessor VBScript. Bash is still building on technology from the ’70s. Using Perl/Python directly does result in a much better solution tbh.

“Hmmm, did -p order pepperoni or peppers?”

PowerShell also solved that issue by a simple trick: You have the full name of a parameter, and can abbreviate it until it’s not anymore uniquely matchable ( because the shell knows the parameters a particular cmdlet has, you can also tab through them ). In this example, -Peppers and -Peppero would be uniquely matched and required for the shell to accept it.

Also, bash has the awesome power that parameters are case sensitive. So you can also confuse -P (pepper) and -p (pepperoni). Obviously.

Still ’70s technology. My favorite example of this is grep by the way: -B for —before-context, -b for —byte-offset, -U for —binary and -u for —unix-byte-offsets, -v for —invert-match, -V for —version while -i is for —ignore-case and -I for —binary-file=without-match . Seriously. -U for binary, because you see, there is a capital U in 'binary’. I’m also wondering how to memorize the difference between -v,-i and -I unless you’re literally stuck to the CLI every day. Also, -f means in a lot of CLI tools —force in others – like grep or PHP – —file=FILE.

Where is the logic in that?

Adam:

FWIW, which ain’t much, you start with sh, which was crap. Funny how even Linux still links sh to the “preferred” shell, which is never sh, isn’t it? Or not.

Then you have bourne, korn and csh, in rough (and I believe) chronological order.

csh is fail.

Let’s ignore things like zcsh, or whatever that abortionate thing based on a curses interface might have been.

We’re left with ksh, which actually is quite portable, and bourne, which isn’t really.

Bash is of course a mildly cleaned up version of the bourne shell, with added goodies like automatic emacs keystroke history (you would not believe how much this makes me happy) and so on.

And even bash is twenty years old now and dead as a vampire in the full moonlight at an open crossroads.

It’s all about OO scripting now. Get over it, little *nix script boy.

“Scraping command output is the most inefficient way of automating a task when you consider the much richer and more direct access other languages have to the operating system’s functionality.”

It’s all about the right tool for the job. For wiring alien processes together, you will never beat a language like Bash or zsh. That’s what they were BUILT for. No ceremonial bullsh!t, no OO and weird boilerplate code (yes even Python has a lot of boilerplate for doing something as simple as launching a process).

@Adam, so how about PowerShell, where is the boilerplate code to start a process? Not seeing it.

“how about PowerShell”

No. Next?

“It’s all about the right tool for the job. For wiring alien processes together, you will never beat a language like Bash or zsh.”

No, a proper API is! Sure, not every application has an API, but then again, not every application has CLI support. How do you think the CLI talks to those silent background processes? That’s right, an API!

What’s pathetic is all these tools are on the SAME MACHINE and they still must talk to each other through a dialog made up of text parsing! This is acceptable when you’re dealing with heterogeneous systems across the web, but NOT when you’re dealing with the local system!

“What’s pathetic is all these tools are on the SAME MACHINE and they still must talk to each other through a dialog made up of text parsing! This is acceptable when you’re dealing with heterogeneous systems across the web, but NOT when you’re dealing with the local system!”

Do you have any reason technical reason as to why talking through text parsing is “not acceptable”? Or, is it because you think OOP is cooler?

I didn’t say anything about OOP. I just mean that sending “1, 2, 3” around instead of an actual list is ridiculous. The overhead is enormous and the process is incredibly prone to error. Worse still, there’s no agreed on format so each command and utility spits out wildly different formatting meaning you can’t even make a general parser or tokenizer.

Imagine if I needed to pass the number 10 to a function in my application. It would make sense to send it AS THE NUMBER! Not convert it to a string, then pass it, only to have the function convert it from a string to an int again. What if the string parser assumed that because it’s 10, that it’s a short binary string instead of an int (some javascript implementations actually do this)? It’s like playing the telephone game, each time you make a conversion there’s a possibility of something being lost or corrupted.

“No. Next?”

So why not? Not open?

http://blogs.msdn.com/b/powershell/archive/2011/04/16/powershell-language-now-licensed-under-the-community-promise.aspx

OH WAIT, it is an open specification!

Uhm, technical arguments on your side then?

“Do you have any reason technical reason as to why talking through text parsing is “not acceptable”? Or, is it because you think OOP is cooler?”

Yes, it is indeed. Sed’ing through and output is 70s technology.
The power lies within supporting both, OOP and text output.

Example: You want to search a file and want to add up the filesizes of the directory the files lies in.

Here’s how to do that in PowerShell:

gci ( gci -r -i side.vmt ).Directory | Measure-Object -Sum -Property Length

How do I do that in bash? Get the filename, sed the directory from it, du on the directory. Yummy yum yum.

First checkout PowerShell, then talk.

“No, a proper API is! Sure, not every application has an API, but then again, not every application has CLI support. How do you think the CLI talks to those silent background processes? That’s right, an API!”

In Linux virtually everything worth automating has a CLI interface. Actually many apps are simply wrappers around the CLI interface. Arguable, entire parts of Linux’s API (sysfs) are intentionally written to be easy to use from a CLI. Linux takes a lot of inspiration from Plan9 and UNIX in this manner.

Actually many apps are simply wrappers around the CLI interface.

lol, thats absolutely true, and thats also the reason why linux apps are so crappy.

No.

Put it this way Adam, automating via the CLI is equivalent to automating using something like MacroToolworks that actually performs mouse clicks and keyboard strokes on a Windows GUI. Sure, it works, but it’s a hack; The worst way to go about automating something.

It’s slow and prone to error.

I translate:

“In Linux virtually everything worth automating has a CLI interface.”

In Linux we only offer a CLI interface, GUI is for Mac users.

“Actually many apps are simply wrappers around the CLI interface.”

We do have a GUI for certain parts but intentionally made crappy so you have to use the CLI.

“Arguable, entire parts of Linux’s API (sysfs) are intentionally written to be easy to use from a CLI.”

Unlike other systems we have sysfs which is totally awesome and beats WBEM/WMI which is standarized and works over the network, as well as supports structured queries, but you can use it from CLI. Nevermind that you can also do so with WMI on Windows, but we do it better.

“Linux takes a lot of inspiration from Plan9 and UNIX in this manner.”

Linux tries to clone UNIX but in the end, no – not even commercial ones – distro has ever achieved SUSv3 compliance, unlike OSX.

That’s why we say we take inspiration from – LOL! – Plan9.

Of course there might be PowerShell on Windows, but I am simply going to ignore that and make ridiculuous claims on how cmd on Windows is totally bricks compared against bash.

“Put it this way Adam, automating via the CLI is equivalent to automating using something like MacroToolworks that actually performs mouse clicks and keyboard strokes on a Windows GUI. Sure, it works, but it’s a hack; The worst way to go about automating something.”

Yeah I know. Personally I think everyone should replace their shell scripts with Python and Django.

personally everyone shoiuld find a freetard who promotes CLI use over sane GUI use and condemn them to using nothing but an Apple ][ for the rest of their natural lives.

Obvious trolling, but, as always we feed the trolls, so here goes…

Django is a web framework, it has nothing to do with OS automation. If people actually DID write their shell scripts in Python they’d be a LOT easier to read, be portable across multiple platforms and unit testable.

Funnily enough, I did precisely that (in a Microsoft environment, yet).

I couldn’t be bothered to document the end user interface for selecting a particular set of statistical constraints (given a choice of ten per country, and five or six countries), so I wrote the whole thing up in Django and Python. Took me about a day or so. It would have taken just as long in bash (on cygwin).

The interesting thing is that I came back to it two weeks later and could still understand how the interface worked. I guarantee you that, if I’d been a clueless n00b like King, I’d have totally forgotten and had to hack the thing up again from scratch.

Python and Django ftw!

“If people actually DID write their shell scripts in Python they’d be a LOT easier to read [for me]”

Fixed. Nothing everyone cares to learn Python. The shell works just fine for automation. End of story.

Nothing = not

They’re easier to read because you don’t have cryptic one letter flags all over the place, not because of syntax.

Can you explain to me how I can use bash to automate Photoshop? Oh, that’s right, it has an API, an actual APPLICATION PROGRAMMING INTERFACE, not a command line interface!

“Can you explain to me how I can use bash to automate Photoshop?”

You use GIMP, obviously. Hope it helps.

“Oh, that’s right, it has an API, an actual APPLICATION PROGRAMMING INTERFACE, not a command line interface!”

Right, bash does fall flat there. Calling native functions is simply impossible.

PowerShell? Not so much ( ie. http://pastebin.com/jRQt6Nfk )

But I’m sure bash is still the #1 scripting and CLI language.

“Can you explain to me how I can use bash to automate Photoshop? Oh, that’s right, it has an API, an actual APPLICATION PROGRAMMING INTERFACE, not a command line interface!”

No, it’s about using the write tool for the job. If I want to selectively move files around, I can probably do it with a single line of code in Bash. Or install applications. Bash really shines with anything that involves stringing processes together, not for automating a single process. That’s because Bash (like all shells), running a process is a “command”, and it also supports pipeline the output of one command into the input of another.

You CAN do this in Python, it’s just more code. And at the same time, that’s just another language you have to learn.

It makes sense for someone like you who writes web apps obsessed with Python or PHP (hint: you can write web apps in shell script, but I’d recommend against it). Shell script is very much the language of system administration.

It’s all about using the right tool for the job, as I’m sure you’ve heard before.

To be clear: Running a process is a “command” means running a process is a first-class language construct (there is no “API” for doing it like most languages, in shell it’s a PART of the language).

Aha, and so how is bash the right tool for uh web queries?

Thought we were already past the point that bash does not have REST support? No?

“BASH — it moves files selectively around in one line!”

Yes, well, that’d be the tool for the job alright. Actually, you’ll find that one line has semi-colons in it … which in CS terms means it isn’t a single line.

Now, let’s see what happens when I want to chain two commands together. I have no need to grobble through man pages, because I am l33t (yes, Adam, I’ve been programming shell scripts since before you were sentient. A good half hour or so, I should say). And I’ve got the wonderful *nix pipe!

Xept the output of one command doesn’t match the input of another. That’s all right, I’ve got awk. And errors appear on a different stream — if they appear at all. That’s all right, I’ll just redirect stderr to /dev/null^W^W a temporary file, and when I’m done I’ll fork another process that merges all the temporary error files into one. I think I’ll use sort and cut while I’m at it. Perhaps I can `echo “^G` just to let myself know that there was an error? (This obviously won’t work on all linuxen. It rather depends upon having a functional audio stack.)

I missed out tee, but that’s triffically useful as well.

Or I could just do what ALL NORMAL *NIX PROGRAMMERS DO, and use Python. Or, if you insist, Perl. Or even Ruby.

Nobody uses shell scripts any more, Adam. Not even Linux programmers. Get over it.

This “lack of an API” whereof you speak. That wouldn’t be the backticks, would it? Because they look awfully like an API to me. In fact they look awfully like syntactic sugar (in this case syntactic grit) for system(“my command goes here”).

Not a particularly adept API, I’ll grant you. Not elegant. Not flexible. Not especially amenable to error detection, as with yer actual API.

But still 'n’ all, it’s an API.

If you live in the seventies.

Face it, Adam doesn’t even know what an API actually is. He thinks the only way to create a file is to wrap “touch”.

“Face it, Adam doesn’t even know what an API actually is. He thinks the only way to create a file is to wrap “touch”.”

If it can’t be automatically introspected from Python, it can’t possibly be an API!

Face it, if you need to use a CLI you’ve failed… HORRIBLY!

Except when using the CLI allows me to do productive things that make me money. I know. Impossibility!