Thread: why does this crash?

And yet, will Linux still retort to their mostly command-line approach, I wonder?

I invite you to learn and use Linux / any kind of UNIX for at least half a year, and you will see why people like me prefer the commandline for many things over GUIs.

One of the main reasons that I use Linux is because it has a vastly more powerful command line compared to Windows. I use the command line quite a bit. For example, nowadays I almost never use a GUI program to do file management (moving, copying etc). It is not because a good one is not available (there is Nautilus), but it is just a lot more efficient to do it on the command line. It does take longer to learn, but I spend many hours in front of the computer everyday, and the timesaving greatly outweighs the time needed to learn. Of course, there is little point in learning the command line if you only use the computer once per month... but I suspect that is not the case.

Actually, I just thought up a crude example -
Suppose you have 1000 programs/commands installed/available. On the command line, one would need to memorize the 1000 commands, but in actual use, it's just typing one command ( an O(1) operation ).

In GUI, however, the 1000 programs would have to be organized in nested menus (a list of 1000 programs to choose from doesn't sound too inviting). That makes choosing a program an O(logn) operation.

Another example -
When I have a naked C++ file to compile and see the output (downloaded from a forum for example), I certainly find it easier to do

Code:

g++ file.cpp

than whatever you need to do using an IDE (create a project, add the file, etc).

While the original thing I was aiming for was that the IDE will set the default options for you and pass them to the compiler wheras with the command-line compiler, you have to set those manually because those options will default to OFF or whatever if you don't specify them.

Not true... command line programs have sensible defaults, too.

Of course, there are things that is better done with a GUI (eg, I wouldn't want to do image editing on the command line), but there are also many things better/more efficiently done on the command line.

Originally Posted by cyberfish

I invite you to learn and use Linux / any kind of UNIX for at least half a year, and you will see why people like me prefer the commandline for many things over GUIs.

I'd go mad. I hate command lines.
They are good for simple nothings; nothing more.

One of the main reasons that I use Linux is because it has a vastly more powerful command line compared to Windows. I use the command line quite a bit. For example, nowadays I almost never use a GUI program to do file management (moving, copying etc). It is not because a good one is not available (there is Nautilus), but it is just a lot more efficient to do it on the command line. It does take longer to learn, but I spend many hours in front of the computer everyday, and the timesaving greatly outweighs the time needed to learn. Of course, there is little point in learning the command line if you only use the computer once per month... but I suspect that is not the case.

And how long does it takes to specify the full path to something instead of just selecting the files to move instead and dragging them? The latter sounds faster.
No thanks. There's a reason why there are GUIs around and DOS evolved from command lines.

Actually, I just thought up a crude example -
Suppose you have 1000 programs/commands installed/available. On the command line, one would need to memorize the 1000 commands, but in actual use, it's just typing one command ( an O(1) operation ).

In GUI, however, the 1000 programs would have to be organized in nested menus (a list of 1000 programs to choose from doesn't sound too inviting). That makes choosing a program an O(logn) operation.

Or you could assign shortcuts or make a small program that launches said program or script if you type a small "command" or text. I did one such thing long ago for someone. Intuitive and far easier than command line.
You could argue that it is semi-command line since you have to type the program name, and sure, that may be the case, but I won't have to remember all thousand arguments to the program.

Another example -
When I have a naked C++ file to compile and see the output (downloaded from a forum for example), I certainly find it easier to do

Code:

g++ file.cpp

than whatever you need to do using an IDE (create a project, add the file, etc).

Which means the compiler might be misconfigured unless you punch in the correct arguments (and some compilers requires you to type more than just no command lines).
And I could just re-use a project I already have for such purposes.
A GUI can organize the output and sort them, the output from the command line can't.

Not true... command line programs have sensible defaults, too.

Yes, but not all. Microsoft's C++ compiler requires a load of arguments to compile correctly; otherwise it will not generate any good code, or no code at all.

They are good for simple nothings; nothing more.

O_o

My personal server uses a script calling CLI tools to support transparent differencing of massive storage. It is capable of watching any file whether it be local, on the network, or only available on the internet. (libcurl jigdo libtorrent) If a file is updated a difference is performed. (diff diff3 bindiff pdiff) If the file is from a watched source repository the file is pushed to my SVN. (subversion) If a file is part of a package the new file is added to a 7z container. (7zip) The latest version of any file/package/tracker is sent to the NAS and all network links are updated. (ftp libcurl) The difference is pushed to the update stack. The update catalog is itself updated so the old version of the file/package/tracker can be restored. Every day the update set is written to a new session on a DVDROM. (cdrtools) If the update catalog has reached the limit of the DVDROM an email is fired to one of my accounts and as part of packaging an image is generated listing any updates marked as major and the time spanned by the updates. (libmail imagemagick) If a file is an executable distribution/installer it is checked against my list; if the watched target is on my list the file is exploded and customized; if this executable distribution/installer is marked as major or more than two updates have been found a fresh master installer image is produced and an email is fired to one of my accounts. (my own stuff) If the second drive is free and contains a DVDR the image will be burned. At any time anyone with an account can login and request my server burn a fresh release DVD of anything with distribution rights on the server--including a few *nix releases.

If I need to know if some source I've written is sound I can fire off a different service that compiles and runs the relevant test suite on about thirty different devices. (GCC and several emulators)

Alternatively, if I've recently purchased a DVD or two, like say a season of anime, I can use the drive farm to transcode six discs at the same time into files and formats suitable for play/streaming to PS3/XBox 360 and PSP. Once this is successful the files are copied to the relevant network directories and the streaming server software is rebooted. (mplayer mencoder fuppes and some of my own stuff)

The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.

Soma

Originally Posted by phantomotap

The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.

IMO, they should be implemented as DLLs/other techniques instead. CLI is not meant to be called from another program, because frankly, capturing and analyzing the output and determining if something went wrong is a pain. Plus there's no way good communication between the tools can be made.
CLI just sucks in this regard, so they should not be used as external components. They can work as external applications, for use with things, but not within a programmatic environment. We don't live in 1980 anymore. Welcome to today's far better interfaces than CLI.

Originally Posted by cyberfish

That is what I thought when I first tried Linux. Not anymore.
It is easy for a Windows person to underestimate the command line, as Windows doesn't come with even a half decent one.

I never use any command line tool aside from those for which there are not GUI equalient (often chkdsk, ipconfig). Last I tried Linux I just got annoyed and irritated, and I think I have expressed that frustration several times on the forums already.

You need to configure a GUI compiler, too. No compiler is that smart, yet. However, gcc defaults are quite okay. I just tried compiling my ~4000 lines chess engine using a simple "g++ main.cpp", and it worked. All the flags (arguments) I use are for optimization purposes.

Yes, and that is an example of a poorly designed program. Or perhaps Microsoft only intended it to be called by the GUI, not a human. Unlike GCC.

Well, what can I say? Perhaps Microsoft thought no one would bother calling it from the command line and did the right thing by making it callable from GUI only

I can, in 5 seconds time, type a command to delete all files in the current working directory, that begins with an "a" and ends in "z". Try that on a GUI.

That one is a piece of cake. I could write a very, very simple GUI to do that in a short time.
At the same time as you're promoting command line, you seem to have underestimated GUIs.

A while ago I wrote a simple script that goes to the National Geographic website, parse the html (a simple thing on the command line), download the picture of the day, crop out the logo, scale it to the size of my desktop, and set it as my wallpaper, once a day. Try that on a GUI =). If you would rather use C++ for that... be my guest, but you will need to link to an image editing library, and a http library, and whatever API you need to set the wallpaper. I wouldn't be able to do it in < 500 lines at least.

The problem is the lack of good GUIs for some tools, especially for scripted actions such as this.
Can it be done? Certainly. Just as as easy as if it were CLI - I can already picture a prototype of such a GUI in mind, and how to go about doing it.

Originally Posted by cyberfish

Many of them have DLL versions, for linking with compiled programs.

Then they aren't CLI anymore - they are real interfaces, and everything is alright.

Originally Posted by phantomotap

With this in mind, I guarantee you that any traditional *nix user could script at least the curl/imagemagick/cdrtools portion of my file master scripts before you could get off the ground with C++ by using the relevant library code.

More linux talk! I don't even know what they heck x/y/z is :|
Linux is not for me >_< Everything needs to be written at least once, you know...

Originally Posted by cyberfish

How short is that? As short as

Code:

rm a*z

? That's 6 characters including the space. My 5 seconds estimation is based on my typing speed of 6/5 letters per second =).

Does that include the time it took to write the CLI app itself? If not, then it isn't a fair comparison, you know?

The thing is, AFAIK, no one has attempted it (in a big enough project), except Apple's Automator. Not quite as useful as CLI scripting, though (but I have not used it much, so might be wrong). As soon as they put it into a GUI, it loses 90% of its flexibility.

True to the first and no to the second, is what I'd like to say. If done properly, it doesn't lose flexibility.
Even so, the program could generate a script, which you could script yourself if you wanted. That would please both crowds, and loose no flexibility.

People can and do argue that their CLI interfaces are as good as their DLL interfaces.

I strongly disagree here.
What if the tools need to communicate?
Say, an application feeds raw frames from a video to a CLI tool via stdin. If the CLI tools receives a corrupt frame, should it terminate after having done 99% or maybe tell the provider: this is corrupt, can you provide a non-corrupt frame or do you want me to skip it, instead of just terminating, or if other non-expected event occur.
Perhaps you want the user to be able to select if they want to continue or not, despite that it might be corrupt? How do you go about doing that with a CLI tool, on a frame-by-frame basis?

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

Originally Posted by cyberfish

No, but when you say you move file by dragging and dropping, did you include the time it took to write Explorer? =)

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

I wasn't using a specialized program for this task either. "rm" is the standard command for removing files.

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

Theoretically perhaps, but nothing like that exists yet, and I wonder why.

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

That is essentially what Automator does. The difficulty is in communicating to the GUI what you want the script to do, not actually generating the script.

I don't think it would be that difficult, no...

True. Command line programs typically only communicate failure by return code (the "int" in "int main()"). Then, of course, the calling program can lookup what the return code means, just like how people do it with dlls. Normal input/output is done through the pipes (stdin stdout). There is stderr for error logging/reporting actually. What you just said can certainly be done in command line.

Pretty solution, though? Hardly. I think not.

By prompting the user, just like how you would do it in C++.

But then again, that's not what a tool should do. That reduces flexibility by a lot (what if you wanted to display the error in german and not english, which the app was written in?).
I think that just defies the purpose of such a tool.

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

You seem to be hung up on the concept of reuse. The time to develop rm is irrelevant, because it's amortized by the incredible flexibility the combination of rm and shell commands give you.
The time to develop a GUI for removing files is not mitigated unless it gives you very smart way of selecting files according to specific criteria. And in all likelihood, this criteria engine will use some glob or regular expression as the input, thus emulating the command line.

You keep harping about what the command line can't do or can't do properly, or even what it shouldn't do, when you have almost no experience with it. You're not making arguments. You're merely demonstrating ignorance.