>Hit F7 to pull up a list in an overdrawn 'window' to chose from the last 7 or so commands or hit up, down, left or right keys
>The the arrows only give you a history of 7 too?
No. F7 puts up a text box of the last several commands, numbered 0 to 10, which you can select. I didn't know about F7. The command history, accessed by arrows, defaults to 200 command lines, but you can set it to 5000 at least, if you like. Function keys F1 through F9 all do something useful. I knew about F3 from DOS.
>2)TAB - complete
>Which is very annoying because of the fact that you have to keep hitting tab to cycle through the options
What does bash do; read thoughts so you don't have to press any key? But seriously, if bash does it nicer, I missed it.
>3. Write a script that will do a backup of your home folder into a compressed archive
> that stores it on a local FTP server.
>All these things are possible, but they aren't easy in Windows CLI. ..
I don't get why this should be harder in Windows, if you have command line versions of the relavent utilities. Write a batch file. The are CL zip utilities. XP has some command line ftp utility.
Command line ftp doc
"Ftp
Transfers files to and from a computer running a File Transfer Protocol (FTP) server service such as Internet Information Services. Ftp can be used interactively or in batch mode by processing ASCII text files.
"
Command-line reference A-Z
>But lets be frank. Command line processors are relics. They are crap. Their only rationale is
> their ease of implementation.
>You ever try to write one? Writing a decent one isn't easy.... I would think writing a
>simple GUI environment (given a framework that lets you create buttons/etc...
>like in VB or Java + SWT) wouldn't take as long.
That's because Windows is already written. Now if you had to write Windows first ...
I state the obvious and I get an argument. Why? The fact remains: A CLI's only rationale is the ease of implementation. You know it. I know it. The good GUIs for linux took years to write, and they are not complete, and that's with X already there to use. This, despite the fact that a GUI's only difference is the presentation to the user. A lot of the apps are "frontends" to a command line version, I understand. However, the main aspect of "ease of implementation" I was referring to is compactness and device independence. A lot less to go wrong. That's why the XP "recovery console" is not a recovery GUI.
I know its hard to write ANY program, because I am a very, very amateur programmer. I never write an interface. I do:
cout << " this is it. x =" << x << "\n";
or I just examine the variable in the Visual Studio debugger. If I need to keep the output, I run the program at a command prompt and redirect the output to a file. I do it that way not because it the best way. I'd like to have it in pretty, mathematically correct symbolic typography. That would be hard. I do it the crappy way because its easy.
>You're saying the commandline is good now?
yourself. Command line shells stink on ice. There is probably nothing that couldn't be accomplished easier and the function presented more clearly with a more complex interface. I always have multiple versions of Windows on my HD for cases where I would have to resort to a command line (like recovery console) for things the main OS won't allow you to do to it while it is running. I don't have a phobia toward using a CL interface if that's all there is. It just sucks toenails. I was using CP/M on an S100 Z80, and a Heathkit CRT terminal for many years before the IBM PC showed up. CP/M was totally CLI. I had a "music" board that basically output programmable waveforms, and I wrote a progam in 8080 assembly language to make it useful. The assembler was a command line assembler, of course. Even back then assemblers had 30 command line switches. My program took musical notation that I read from sheet music and I typed in a text format of my own creation into a text editor, and translated that to a compiled file. It had multiple defined instuments and multiple notes per instrument, variable level per note, etc. Then the program took the compiled form and transformed it into waves that were assemble into notes, that were assembled into songs and fed to the music board. It was a command line program, of course. You can imagine how bad that sucked: typing in musical notation as text. It worked, but don't tell me it was good. Now, admittedly even at the time I used a full screen editor (as they were called then), so 99% of the work was not at a CL. Full screen editors were kind of new and expensive. I got the first cheap one there was, not WordStar. The usual editor was a line editor. That's right: you entered a line at time, and revised the text painstakingly by giving commands to access a given line, and giving commands to alter the line a certain way. The way you saw what it might look like was to give a command to type say 16 lines, and the 16 lines would scroll. No cursor keys, no page keys, no scroll bars and of course no mouse because terminals didn't have one. You namby-pamby pampered linux cyberpunks have no real idea of what a CL is unless you use a line oriented editor, like I did for quite a while. DO NOT PREACH TO ME ABOUT HOW BEAUTIFUL AND PRECIOUS A CL IS! Back then the cyberpunks all insisted that a line editor was better than a full screen editor. And you are still at it.
>MS's commandline is well-thought-out? Try "netstat -?". Then try "dir -?". ...
CMDs built in commands are comparitively well thought out as these thing go. This is starting from a statistical norm that is rotten. Most things in general start out straightforward, then new things are added whidh can't be made to fit quite right, and finally are a hodge podge of ad hoc incomprehensibility. The NT/XP utilitiies (external commands) look like MS is using unix style switches (to be POSIX compatible) for anything beyond the old DOS commands, while the old DOS commands keep the old style for compatibility. netstat /? does work though. In fact all the netstat switches seem to work with either a - or /. Maybe unix utilities prodigious array of switches have this origin: perhaps some are due to a later revision or reorganization, while the older set are kept for compatibility with old scripts. Or maybe liinux afficiandos all have super-sized brains for which endless profusion is no obstacle. Linux command lines are compact programs in themselves.
>source run_spice.csh -log foo.txt && sort -n +18 foo.txt |head -n 5
Ok, so maybe it took me half an hour to figure out how to do that the first time.
>But once I do it the first time, I can just do "!sou" to run it again in the
> same shell. If that was a GUI, you'd be clicking... and clicking... and clicking.
No reason it could not be simpler to work out this command with a better interface. It is a kind of short program, which is error prone for most normal people. IAC, it would just be a so-called macro you run in a GUI.
>The the arrows only give you a history of 7 too?
No. F7 puts up a text box of the last several commands, numbered 0 to 10, which you can select. I didn't know about F7. The command history, accessed by arrows, defaults to 200 command lines, but you can set it to 5000 at least, if you like. Function keys F1 through F9 all do something useful. I knew about F3 from DOS.
>2)TAB - complete
>Which is very annoying because of the fact that you have to keep hitting tab to cycle through the options
What does bash do; read thoughts so you don't have to press any key? But seriously, if bash does it nicer, I missed it.
>3. Write a script that will do a backup of your home folder into a compressed archive
> that stores it on a local FTP server.
>All these things are possible, but they aren't easy in Windows CLI. ..
I don't get why this should be harder in Windows, if you have command line versions of the relavent utilities. Write a batch file. The are CL zip utilities. XP has some command line ftp utility.
Command line ftp doc
"Ftp
Transfers files to and from a computer running a File Transfer Protocol (FTP) server service such as Internet Information Services. Ftp can be used interactively or in batch mode by processing ASCII text files.
"
Command-line reference A-Z
>But lets be frank. Command line processors are relics. They are crap. Their only rationale is
> their ease of implementation.
>You ever try to write one? Writing a decent one isn't easy.... I would think writing a
>simple GUI environment (given a framework that lets you create buttons/etc...
>like in VB or Java + SWT) wouldn't take as long.
That's because Windows is already written. Now if you had to write Windows first ...
I state the obvious and I get an argument. Why? The fact remains: A CLI's only rationale is the ease of implementation. You know it. I know it. The good GUIs for linux took years to write, and they are not complete, and that's with X already there to use. This, despite the fact that a GUI's only difference is the presentation to the user. A lot of the apps are "frontends" to a command line version, I understand. However, the main aspect of "ease of implementation" I was referring to is compactness and device independence. A lot less to go wrong. That's why the XP "recovery console" is not a recovery GUI.
I know its hard to write ANY program, because I am a very, very amateur programmer. I never write an interface. I do:
cout << " this is it. x =" << x << "\n";
or I just examine the variable in the Visual Studio debugger. If I need to keep the output, I run the program at a command prompt and redirect the output to a file. I do it that way not because it the best way. I'd like to have it in pretty, mathematically correct symbolic typography. That would be hard. I do it the crappy way because its easy.
>You're saying the commandline is good now?
>MS's commandline is well-thought-out? Try "netstat -?". Then try "dir -?". ...
CMDs built in commands are comparitively well thought out as these thing go. This is starting from a statistical norm that is rotten. Most things in general start out straightforward, then new things are added whidh can't be made to fit quite right, and finally are a hodge podge of ad hoc incomprehensibility. The NT/XP utilitiies (external commands) look like MS is using unix style switches (to be POSIX compatible) for anything beyond the old DOS commands, while the old DOS commands keep the old style for compatibility. netstat /? does work though. In fact all the netstat switches seem to work with either a - or /. Maybe unix utilities prodigious array of switches have this origin: perhaps some are due to a later revision or reorganization, while the older set are kept for compatibility with old scripts. Or maybe liinux afficiandos all have super-sized brains for which endless profusion is no obstacle. Linux command lines are compact programs in themselves.
>source run_spice.csh -log foo.txt && sort -n +18 foo.txt |head -n 5
Ok, so maybe it took me half an hour to figure out how to do that the first time.
>But once I do it the first time, I can just do "!sou" to run it again in the
> same shell. If that was a GUI, you'd be clicking... and clicking... and clicking.
No reason it could not be simpler to work out this command with a better interface. It is a kind of short program, which is error prone for most normal people. IAC, it would just be a so-called macro you run in a GUI.
That's kind of neat. Didn't know that. I used to know what f3 did, but I stopped caring.
What's obvious? You stated something that people disagree with. Sounds like it isn't so obvious. Maybe the world is black and white to you, but some of us believe in opinions and differences between people. You like GUIs. Great. Use them. I like a command line. I'll continue using it where appropriate. I don't see a reason for a debate, but I also don't see the point of someone coming around yelling and screaming about how my prefered system is crap because it blah blah blah.
No no no no no no no no no no no no. Definitely not. I don't think so. Bah humbug.
The Unix philosophy is the perfect reason for the command line interface. A gui just can't really handle the Unix philosophy in the same way.
Opinions are not known, they're believed.
Ok. CP/M. Don't care. Opinions opinions opinions. Subjectivity is a grand and wonderful thing. Objectivity is evil when applied to subjective things.
My <insert name of something I use but you don't here> is better than your <similar something that you use but I don't>!
look the way I see it the differences between a bash or another unix shell vs the windows CLI come from the fundamental differences in design concepts.
In windows a CLI is a tack-on. It's designed to do stuff that you just can't do thru a gui. Whatever MS thought was important, they made it easy. Anything else your kinda on your own. For example MS didn't think that it was important that you might want to write a script to make a shortcut on your desktop. Try to do that, it's possible.
The Bash shell on the other hand is something that has evolved over the years as a complete user interface. Everything that can be done with a OS anywere can be done, one way or another, thru the shell interface. So it has to be flexible as possible. Anything truly flexible is going to be complicated, irregardless of weither it's a command line or a GUI.
Anyways, if you don't like command lines, tough luck. They aren't going anywere, it's impossible for a 2d gui to ever come close to the functionality/flexibility/usefullness of a good old-fasioned command line. Bash is definately not the pinnacle of computer user interfaces, but people are working on evolving and replacing that with new shells.
edit: For example this little ftsh
I think that maybe with completely immersed 3-d enviroment you could get rid of the command line, but even that maybe doubtful.
In windows a CLI is a tack-on. It's designed to do stuff that you just can't do thru a gui. Whatever MS thought was important, they made it easy. Anything else your kinda on your own. For example MS didn't think that it was important that you might want to write a script to make a shortcut on your desktop. Try to do that, it's possible.
The Bash shell on the other hand is something that has evolved over the years as a complete user interface. Everything that can be done with a OS anywere can be done, one way or another, thru the shell interface. So it has to be flexible as possible. Anything truly flexible is going to be complicated, irregardless of weither it's a command line or a GUI.
Anyways, if you don't like command lines, tough luck. They aren't going anywere, it's impossible for a 2d gui to ever come close to the functionality/flexibility/usefullness of a good old-fasioned command line. Bash is definately not the pinnacle of computer user interfaces, but people are working on evolving and replacing that with new shells.
edit: For example this little ftsh
I think that maybe with completely immersed 3-d enviroment you could get rid of the command line, but even that maybe doubtful.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
I didn't figure it was only 7, but it's still virtually useless since it loses the history when you quit that cmd instance.
It completes up until it runs out of unique names and then you can hit tab twice to see what's left. Say you have a directory with file1, file2 and file3 in it, if you type 'blah f<tab>' it'll type file for you and beep because it doesn't know if you mean 1, 2 or 3.
No sh!t, but MS doesn't give you CLI versions of a lot of things. And tell me how you would check the date on a file in a batch file? Because if you didn't want to backup everything every time you would probably want to only backup files that have changed since the last run.
You don't have a phobia but you're willing to reboot into another instance of the same version of OS just to avoid using it?
Hardly. The inconsistent use of % signs for variable access is the worst, sometimes you need 2 of them sometimes only 1, why?
Most UIs are not well thought out and most programs don't support macros themselves so you'd need a 3rd party program and I really wouldn't trust a 3rd party program that's supposed to click buttons, menus, etc for you.
If you want to see a good attempt at creating scripting for a gui interface. Check out Apple's Applescript stuff.
It's a nice attempt, but it's not consistant and there is NO documentation, except for a basic help and some simple examples. Also it's very inconsistant, there have been many different versions, and often commands from older versions are still present. Sometimes they do the same thing they did before, sometimes they do something different. Sometimes they fail miserably everytime you try to use them and have been replaced by a differently worded command. It's pretty irritating to try to learn from scratch.
You realy need to buy a seperate book to use it. Also Apple has a seperate app you have to buy that will help you make good scripts. But the functionality is built into every Mac OS.
It's funny because it tries to use natural langauge. At first it seems easier then something like bash or any other scripting language, but you soon realise that it's not easier. You just do a lot more typing.
However for all it's faults it is actually quite usefull. It's the best scripting setup for any GUI. Some apps like Quicktime actually support your recording your actions. You can move, start movies, stop movies, resize it, and then it records all this and you can replay it, just like you did it the first time. Doesn't work with most apps though.
What it is realy usefull for is openning up apps, installing stuff, or doing automated stuff like mounting a share (the proper way, using unix scripts to do it low-level will usually end up locking up finder (maybe they have it fixed)).
It's interesting approach
It's a nice attempt, but it's not consistant and there is NO documentation, except for a basic help and some simple examples. Also it's very inconsistant, there have been many different versions, and often commands from older versions are still present. Sometimes they do the same thing they did before, sometimes they do something different. Sometimes they fail miserably everytime you try to use them and have been replaced by a differently worded command. It's pretty irritating to try to learn from scratch.
You realy need to buy a seperate book to use it. Also Apple has a seperate app you have to buy that will help you make good scripts. But the functionality is built into every Mac OS.
It's funny because it tries to use natural langauge. At first it seems easier then something like bash or any other scripting language, but you soon realise that it's not easier. You just do a lot more typing.
However for all it's faults it is actually quite usefull. It's the best scripting setup for any GUI. Some apps like Quicktime actually support your recording your actions. You can move, start movies, stop movies, resize it, and then it records all this and you can replay it, just like you did it the first time. Doesn't work with most apps though.
What it is realy usefull for is openning up apps, installing stuff, or doing automated stuff like mounting a share (the proper way, using unix scripts to do it low-level will usually end up locking up finder (maybe they have it fixed)).
It's interesting approach
http://www.linuxdevcenter.com/pub/a/linux/2001/11/15/learnunixos.html
a oreily article... they sell unix books, but nevertheless this is a decent explanation of CL vs windows.
a oreily article... they sell unix books, but nevertheless this is a decent explanation of CL vs windows.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter