Thread: why does this crash?

Fair enough, let's leave the actual applications out of this
Command line may be faster, but the GUI certainly isn't slow either...

How about... you have a folder of image files named year-month-day.jpg (2008-05-22.jpg) that is a snapshot of your aquarium on that day.
Then you realized that every year in May, all fishes are sleeping, and there is no point keeping those snapshots, so you want to delete all the files in May. How would you do that?
I would do

Code:

rm *-05-*

Sure, but it took time to develop the rm command when it first was created.

Yes, and it was >20 years ago, and GUI programs haven't caught up to that kind of flexibility yet.

They're all lazy bastards and don't realize the the gain of doing this :|

That is a very noble undertaking. Very courageous of you, Elysia. =)

Pretty solution, though? Hardly. I think not.

Of course there is a limit to how complex a script gets. For anything more complicated, we need C++, too. On the other hand, what phantomotap described is certainly doable in CLI, can you say the same for GUI?

what if you wanted to display the error in german and not english, which the app was written in?

CLI is not God, there is a limit to what it can do, too =).

btw, bed time for me =) I will come back tmr. In case you are wondering, I am a high school kid and need to go to school at 8 everyday =).

Of course there is a limit to how complex a script gets.

No, believe me, there really isn't. I have a good variant of a Bash installed with a supporting cast of about 300 CLI tools. I can redirect input and output to arbitrary named pipes. I can script keyboard and mouse input for a GUI. I can read arbitrary pixels and examine it for any text. I can even script in an interpreted form of C++ if I want.

Oh, and Elysia, as you try to figure out how a GUI should best emulate the abilities of a CLI tool, consider this: even if you manage a GUI that isn't bloated from the attempt at visually associating all the available options of the CLI tool if you haven't completely emulated the CLI interface I lose flexibility precisely because I can no longer use the tool in scripts.

Soma

There are solutions to that too... DLL interfaces or using compatible apps to create scripts.

O_o

If the tool wasn't scriptable, how would a tool to script the other tool exist? (The existence of tools to create a script doesn't alleviate the burden of making the GUI scriptable.)

No. A shared library is not a solution. A shared library doesn't let me script behavior by virtue of being a shared library. A shared library is simply a way to store an implementation. The implementation must still exist, and if the interface doesn't support the usual scripting methods then it isn't as flexible as the CLI tool might be.

Or how about just a CLI wrapper tool for the DLL interfaces?

^_^

That would allow the scripting... and I love that you said that; especially after these gems:

They are good for simple nothings; nothing more.

CLI intefaces are poor, poor, poor, poor. DLL interfaces are far more flexible.

Soma

But say the script is in XX format, then a function within a library could allow to "execute" that script, see? Or a program, or whatever. So long as it works.

Not quite; by providing only a function that executes a script in scripting language XX you burden me with scripting language XX. If I don't know XX your shared library is useless.

Again, the beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together. I can use literally hundreds of different languages as glue; regardless of language I bring my knowledge of the tool itself to the table.

For comparison, my choice of languages is limited with a tool only provided as a shared library. If the shared library is written in C++ with C++ as the interface language, and this is a C++ forum, my choice is extremely limited. I have one option: use the exact compiler version as the distributer. (Before you think to deny this, as I'm sure you want to, research what happened when G++ 3.2 was first released into the wild.)

t's not by any means the real way to do it - just as a means to make those script makers happy.
Use it as your own discretion... you're going to miss out on a lot.

It isn't the way to write a user experience application like a browser. It is the correct approach for user or administrator tools. If a tool can't be scripted with what the user knows its useless. An administrator, even in the Windows world, will not use a tool if he knows that he has to actually be present at the computer to use a GUI every single time the tool is needed.

We like to script, so we don't have to do repetitive tasks. Computers are alarmingly good at repetitive so give me an interface that lets me make use of this ability.

Soma

No, believe me, there really isn't. I have a good variant of a Bash installed with a supporting cast of about 300 CLI tools. I can redirect input and output to arbitrary named pipes. I can script keyboard and mouse input for a GUI. I can read arbitrary pixels and examine it for any text. I can even script in an interpreted form of C++ if I want.

Sorry for my ignorance. Linux newbie here =) (~3 years).