|
WREY wrote:
DO IT!!!!! PUT YOUR WORK WHERE YOUR MOUTH IS!!!!!
If you can't, then just shut up, OR go learn how to program using GUI.
Hey, take it easy fellow. A console application is just a tool, like a GUI one. They try to solve different problems. This one was made to be used on extreme situations when poping fancy UIs could take forever, just like Kill.exe from the Resource Kit. I think we can see MS as the most successful GUI applications writer. And why do some of their applications are command line tools and do not have an UI? Why did they put on Windows XP several new console applications? Because they don't know how to do a UI? Because MS is lazy?
My latest articles:
XOR tricks for RAID data protection
Win32 process suspend/resume tool
|
|
|
|
|
The time it'd take me to write a Console application, I can spend less time using AppWizard and write a quick Windows GUI one, and have all the benefits of GUI provided for me, particularly if I might want to expand on its usefullness later.
Still there are times, (even) when I'm putting together a quick GUI program, that I know it's going to be a "throw away" sample. It'll serve its purpose and then put aside. On the rare occasions when I do write a Console application, it won't be for anything of significant benefit, it won't be for anything that I'll keep around, and it certainly won't be for anything that I'll share with the rest of the world.
Yes, much of the credit goes to MS for bringing out GUI and popularizing it, but they do not necessarily legitimize behaviors and trends. And yes, while I will make the distinction between MS (the company) and MS (its technical employees), I will say there are some who works there that are plain lazy and DUMB!!!! So I'm not going to say because MS does something, that MS is lazy, or not lazy. A distinction has to be made if you're going to use the company in that context.
William
|
|
|
|
|
Well, for each task there is the appropriate tool.
If you want to find out whether a specific computer is reachable inside the network, what do you do? Open the Explorer, go to My Network Places, and look for the computer?
I open the command line and type
ping <computername>
How do you determine the IP of your computer? Do you open the Network Connections folder, and open the Properties dialog for the specific connection?
I open the command line and type
ipconfig
Our product is composed of more than 100 projects, so we cannot create one big .dsw to compile it. Therefore we have a bunch batch files for compiling. It's pretty easy.
As you may see, there are several tasks where I really prefer the command line.
Regards
Thomas
Sonork id: 100.10453 Thömmi
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Don't put your mind and waste your time with a ignorant/stubborn newbie (William) who cant't appreciate your work. If he can't understand, or at least accept the command prompt functionality, and the fact your code does not have GUI just because it quicly ilustrates/implements a programming technique and for that does not neeed have a GUI, he sure can't understand what your code is about anyway. He needs to address his social skill too beside programing skills..
|
|
|
|
|
William,
Chill. I'm not a GUI basher. I'm not sure where you got that impression from my post. I love GUIs as much as the next guy, in fact I've been writing apps with full-blown GUIs since the days of Windows 3.1 (so I know how to write them, thank you very much). Given the choice between using a GUI app and a command-line one, 99.9% of the time I'll choose the GUI app. Duh, you'll get no argument from me. As a matter of fact a few years ago I wrote an MFC-like library for DOS so I could write apps using CDialog, CButton, CListbox etc classes in old DOS text mode. You think I'm a "GUI basher" if I went through the hassle of writing such a library?
What I was pointing out (and you keep refusing to acknowledge) is that even in this day and age, command-line utilities still have their uses. I *never* said anywhere in my post (nor implied) that "GUI-based apps suck" and command-line apps are preferable (or "superior" as you put it). Gosh, reading your message, you'd swear I posted some holier-than-thou message. I didn't.
And, frankly, I don't know how you got onto this rant about GUIs and web sites and me being hypocritical. I'd say you just sound like a frustrated AOL newbie who can't figure out command-line utilities, but then you claim to have written your share of them. Fair enough, I'll give you the benefit of doubt. But I have a hard time believing, if you've really written a significant number of programs as you claim, that you can't recognize that sometimes having any GUI at all *doesn't even make sense*. For starters, and for your own edification, check some of the utilities in the various Windows resource kits.
|
|
|
|
|
Like you said, "I'll give you the benefit of doubt," I too, will give you the benefit of the doubt regarding some of your notions about me.
As a parting statement, let me focus in a bit more on "command line prompt" applications. What they do, or what benefits they serve, is not salient to my point. What is salient, is how they get activated, and the subsequent ways in which the users have to interface with them.
Do you remember when you were just learning how to program, Console applications were what you were using to understand how to do things, along with the syntax of the language? Invariably, at some point you had to write a little program that would display a menu with various choices and the subsequent processing that had to be done based on what choice was made. They were starting points and stuff of "yester-years."
However, as you became more confident, knowledgeable and proficient in your skills, Console applications no longer remained the mainstay of your efforts (at least, speaking for myself), and even when working with Windows applications, MS has provided a GUI for developers to used in the creating and testing of their programs.
Some of that technology can be emulated for your own personal use. For example, the "Open" icon on the toolbar (which is a GUI) gives you a window (another GUI) with a tree structure from which you can point and click to the drive, directory and subdirectory (all GUI's) for a file you need. Contrast that to a Console application where you'd have to type in all the information about the drive, directory (etc.) of the file you need, along with the real possibility of mistyping and committing numerous errors. Which way is preferable? (For me who likes to give discriptive names to my directories and files [etc.], typing all those information for a Console application doesn't make it difficult for me to choose which is preferable.)
That's just an example. IOW, if it MUST be a Console application it could still be activated within a GUI setting.
FWIW, I have NEVER been a subscriber to AOL.
William
|
|
|
|
|
William,
I'm glad you're presenting your argument in a much more rational and level-headed manner than your previous post. Let me go over this one. I promise no hostility, and no AOL name-calling. 
> Do you remember when you were just learning how to program, Console
> applications were what you were using to understand how to do things, along
> with the syntax of the language? Invariably, at some point you had to write
> a little program that would display a menu with various choices and the
> subsequent processing that had to be done based on what choice was made.
> They were starting points and stuff of "yester-years."
Ok, now I see where you're coming from. You're discussing the old text-mode DOS applications where each programmer had to design his own (and rather inconsistent) interface. Text menus and text navigation...yuck! I'm *totally* with you on this one. Anyone still intentionally designing his own little text mode menus-based apps in this day and age should *not* even be in this business--or at least should not be writing applications professionally.
When I talk about "command-line utilities" that still have some use today, what I have in mind is utilities that you launch with a command, might pass a few parameters to, and then it does its job and shuts down--the sort of utility that has no need for user interaction once it's launched.
An example of this would be XP's defrag.exe, versus the graphical defragger (dfrg.msc). The GUI one is a lot more user-friendly than defrag.exe, hell it's cool to watch. The "problem" with the GUI version is that it needs user interaction to defrag multiple drives. I just want to tell it to "defrag all my drives". I can't do that and then walk away for an hour, 'cuz you can only select one drive at a time, and it'll sit there and wait after it's done. So I have to stay in front of the system and sit on my hands until it's done, and then manually restart the same process for each and every drive and partition (I have lots).
On the other hand I can write the following batch file, start it and walk away:
DEFRAGALL.BAT
DEFRAG C:
DEFRAG D:
DEFRAG E:
DEFRAG F:
(...)
DEFRAG Z:
*That* is the value of command-line utilities--there's no easy way to do the same thing with the GUI version of the defragger. I've seen lots of threads in various boards from people attempting to do things such as automate the GUI version using WSH, Sleep() and SendKeys(). Talk about fugly. I'm glad MS added the command-line version in XP (I don't believe it existed on Win2K).
I think we're in definite agreement on this point: if an app needs to interact with the user after it's launched, in any way, shape or form, it really, really should have a full-blown GUI. What I wasn't agreeing with was your unilateral claim that "command-line programs have no place today". I think the distinction is in our definition of "command-line program"...you're including the old, interactive, text-mode, menu-based programs of yester-year (I *most definitely* agree they should die a horrible death). In my mind, a "command-line program" that still has some use today is the typical one-purpose, "launch and forget" utility such as defrag.exe. Nobody wants an Excel in text mode. <shivers>
Back to the article at hand--this process suspend/resume tool--would it benefit from a GUI? Yeah, why not? But does being command line-based make it useless? I say it doesn't. I could picture a process pegging a CPU at 100% utilization and wanting to suspend it ASAP--without having to sit through the system loading all the GUI overhead (the MFC DLLs are significant or, God forbid, the VB runtime and custom controls), especially when resources are already being severely taxed. I've sit through attempts to load Task Manager (easily taking 2, 3 minutes) just to kill the offending process. If I can instead launch CMD.EXE and use some command-line utility (I forget its name, it's in the resource kit) to kill the process in 10 seconds, then my blood pressure stays that much lower...
|
|
|
|
|
I'm glad to see that you are more rational and level headed yourself, in the expositions of your views, also. No, it's not an echo you're hearing, it's a reflection of things you earlier said which could have been self-applicable.
Your example of the GUI defragger versus the command-line sample is not a very good example, for the simple reason, what you have outlined as the shortcomings of the GUI sample is NOT a GUI limitation. It's the shortcoming and limitation of the person who designed and (perhaps who also) programmed the application. He/she should have made allowances for the very same things you found restrictive in the GUI version (which you were forced to accept), that caused you to resort to an alternative which command-line prompt readily and easily offered.
Programming is programming, and whatever you can achieve with a "quick and dirty" command-line prompt application, I can do just as well (and BETTER) with a GUI version.
A GUI program need not have all the bells and whistles that a great many people normally associate it with. It is an INTERFACE between the user and the computer that's supposed to make the user's work, easier and more friendly to accomplish. It's an INTERFACE!!!! What happens after the user clicks on a certain button, or make a certain menu selection, is the domain and responsibility of the programmer, and if he/she (the programmer) lacks being thorough and comprehensive in their knowledge and proficiency, the functions of the application will duly reflect those limitations (which is what the defragger example you gave obviously exemplifies).
As far as having the flexibility to enter specialized commands that "command line prompt" applications allow you to do, those very same specialized commands can be part of a menu that in a GUI setting, will simply require you to click on that selection ("click on" versus "typing in"). And whatever additional parameters you need to enter in a "command line prompt" application, GUI applications allow you to have submenus for those very same sort of things. There is NOTHING you can accomplish in a "comman line prompt" application, that I cannot do BETTER in a GUI version (and more!!!).
Still, to be fair about such practices of restrictions and limitations, some companies purposely sanction the exclusion of features they know users will most likely wish were included. However, that is a marketing strategy, because they (the companies) know, and will announce that a later version of the product will be coming out with those exact features and more!!! But that's another story!
William
|
|
|
|
|
I'll grant you that any application can be designed in any number of different ways, and some tasks could be automated easily if the application was designed with those tasks in mind to begin with (our defrag discussion). Some command-line versions of some programs are just as poorly designed and have limitations the programmer didn't think of as well, I have never made a *general statement* claiming that command-line utilities are better than GUI-based ones.
As far as *interfaces* go... Some tasks don't need one at all. I have a few batch files and .vbs scripts, for example, to clean up files in specific directories and perform some other routine maintenance that I run periodically (move files, zip up folders, etc). Do I *need* a GUI to do some batch processing? No. A GUI, in this case, is not required nor does it provide any benefit. Sometimes I just want a shortcut on my desktop I can click and let the system perform those tasks.
The alternative is to start Explorer and manually select a bunch of different files and directories and delete them one by one, move some files on a server, zip up others with WinZip (endless clicks, here we come), etc. I have a batch file that can do it just the same with a single click. Sure, the command-line version of pkzip is a *total bitch* to figure out at first, but once I got it figured out I can write my complex backup scheme *once* in a batch file and forget about it. I can't tell WinZip to compress a bunch of different folders on different drives automatically in a single click. I'd have to go through a complex sequence of navigation and clicks every time I wanted to perform my backup.
I won't buy a counter-argument claiming that "it's a limitation the designers of Explorer or WinZip have left in". Explorer and WinZip are both fine as they are, they don't *need* to be modified to satisfy my every whim. I don't need a GUI to automate the deletion of *.obj (and others) in C:\SOURCE and then zip up the remaining files and then move the zipped files to a server and what-not. It's a matter of using the tools at your disposal. Sure you could design the most awesome GUI-based app to delete files and compress and back up specific directories. If I had all the time in the world, sure, anyone could wrap a GUI around any task. But I don't, and my archaic command-line utilities and batch files *do the job*, and they didn't require me to write my own Explorer or WinZip because the original apps had "limitations". When it comes to *automating* such a sequence of actions, command-line utilities and batch files work great together. Writing an all-in-one GUI tool to do all this with a single click isn't worth my time.
It's *extremely* difficult to automate something with a GUI-based app, because you cannot predict *everything* the user will attempt to do and thus include all the functionality you need. Using a bunch of existing, simple command-line utilities sewn together with batch files might work better in this context.
> There is NOTHING you can accomplish in a "comman line prompt" application,
> that I cannot do BETTER in a GUI version (and more!!!).
...but again, sometimes it's not worth your time, and the quick-and-dirty solutions using command-line utilities will do just fine.
|
|
|
|
|
It's obvious you're still in a learning curve.
William
|
|
|
|
|
Hey, in this field, everybody is. Constantly.
Frankly I'm as sick of this thread as you seem to be.
|
|
|
|
|
lmao, i'm inclined to think of william as the aol n00b...
hell, bet he's not ever touched a *nix OS!;P
|
|
|
|
|
I know this thread is long dead, however I feel William is a moron that needs a real world example to demonstrate where the console is an important tool to any power users arsenal, which is what this pausep.exe tool was intended.
One point you still miss with CUI (character user interface) is it can still do things that are FAR simpler that a GUI - namely automating a series of tasks between entirely UNRELATED applications.
My example:
As stated above, I have a number of tasks that I perform sequentially, using UNRELATED GUI applications, that are REPETITIVE.
My task involves Visual Source Safe (VSS), MSSQL Server and our own application written in house as follows :
1. I unattach and ensure my existing MSSQL database has been deleted from the file system
2. I get the latest MSSQL Server database (our application database) from VSS
3. Ensure the database file access permissions are Read / Write
4. Start Microsoft Enterprise Manager, and attach the newly checked out database with the appropriate DB name
5. Run a fix user script, to update the USER object IDs between the database and my instance of MSSQL Server
6. Run a script to install our license codes into our database, so I can run our applications against the new DB.
Given our DB changes quite frequently (as we store form and script BLOBs in the DB), this happens many times a week.
There is NO GUI application that can do these steps for my specific task. Sure I could possibly write an app to utilize send keys, etc, but that seems like a little over kill. In addition, I would be relying on very specific features and layout of the applications GUIs. It would not be an interactive GUI, as I couldn't change how the app worked without modifying the code.
However, with a bash Shell script, I can utilize the console versions of VSS and interactive SQL (console version) to perform all of the above steps.
It has 6 environment variables defined at the beginning, which allow any of our other engineers to use this script in their own environment, allowing them to chage the VSS database, the database name in MSSQL, their VSS user, etc.
It does not need to be interactive.
Regards,
Stuart
_________________
Stuart Carnie
|
|
|
|
|
The fact that William is not even able to run a command line program (which means running a prompt and run the program from there, instead of running the program from the start->run box) shows that he has never used some.
So why does he insists on the fact that command line programs sucks... he has never tried some...
|
|
|
|
|
Case #1:
Many of the server processes are written as console apps, that are run as services in Windows or started as daemons in Unix. They do not have user interfaces and do not need to have. The administration applications for such servers are GUI for easy user interaction
Case #2:
Applications that need to be run at a specific time without user interaction or display of a window. It is a lot easier to do it as a console app.
A GUI is useful and is the best ofr user interaction from a keyboard and mouse. But, that is not always the case.
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Daniel Turini wrote:
I didn't because I thought most VC6.0 users would use the Project Converter Tool[^]
The conversion tool is also a cmdline, which is going to hurt our guest once more
Thanks Daniel for referring to it.
if you start putting in too manay features, it no longer remains useful for beginners
quote in a CP article comment, shiraz baig
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
