Any ideas on this one?
-
@boomzilla said:
Autocompletion is reasonable, although cycling through options rather than showing a list can be annoying.
I get a list if there's more than one available, rather than cycling. http://ozlabs.org/~jk/docs/bash_completion/ would appear to have some hints on what might need changing/creating.
-
@boomzilla said:
But the cut and paste support? How many other apps to you have to right click, select "Select" before you can even select text? That's a UI abomination.
That's backwards compatibility. The command prompt emulates DOS mouse support by default, which makes selecting text impossible until you switch to copy mode. Fixing the UI would break 20 year old software (for example, copy and paste in the old DOS EDIT.EXE wouldn't work any more. Surprisingly, I was able to test this on my workstation at work as EDIT still ships with XP). Since the primary purpose of the command prompt is backwards compatibility, there is no way that this will be changed.
-
@boomzilla said:
But the cut and paste support? How many other apps to you have to right click, select "Select" before you can even select text? That's a UI abomination.
Tell me you know you can easily modify that behavior so that a normal left-click-and-drag selects text (and Enter copies the selected text into the clipboard, and right-click pastes the clipboard contents)
-
@PJH said:
@boomzilla said:
Autocompletion is reasonable, although cycling through options rather than showing a list can be annoying.
I get a list if there's more than one available, rather than cycling. http://ozlabs.org/~jk/docs/bash_completion/ would appear to have some hints on what might need changing/creating.
Yes, that's what happens under bash. I was talking about CMD. Sorry for not being more clear.@SQLDave said:
Tell me you know you can easily modify that behavior so that a normal left-click-and-drag selects text (and Enter copies the selected text into the clipboard, and right-click pastes the clipboard contents)
You know, I did at one point, but had obviously forgotten that. Thanks.
-
@boomzilla said:
@blakeyrat said:
My world is not even of or relating to a church parish!
OK, I give in. At the risk of being trolled:
Sometimes I make jokes.
@boomzilla said:
Moving files around. Looking at logs, searching for things in logs. Restart a service or daemon. Just lots of little tasks that go on all the time.
First of all, saying those tasks go on "all the time" is, well... unusual. I rarely do those things. I move that the vast majority of computer users rarely if ever do those things. But that aside...
Windows' GUI for moving files around is superior to bash in many significant ways. You get that lovely recycle bin, for one. You get document previews. It's much easier to look at a list of files and control-click the ones you want, than to type out each file's name in a CLI. Windows has a GUI for log files, although admittedly it's not very good. It also has a GUI for services, which is not great but definitely sufficient.
"Lots of little tasks that go on all the time" is just more weaseling, so I'm ignoring it.
@boomzilla said:
There's also the advantage that you don't have to go through layers of menus, or open other processes to get to the utility that you want.
You only have to do that once in a GUI. Welcome to the concept of a "shortcut". (Or "alias", as Classic Mac used to call it.)
@boomzilla said:
It's not really that much harder than navigating through several layers of control panel, in any case.
Hah. Right!
@boomzilla said:
OK, we were thinking of different things.
No, we weren't "thinking of different things." You misread me.
@boomzilla said:
Yes, most linux distros are very much GUI oriented. But they're also fully usable from the CLI.
Its not usable for the things 99% of people want to do with their computers from the CLI, no more than Windows or OS X is.
@boomzilla said:
I'm not familiar enough with the remote scripting available through powershell to know how easy that would be on Windows, but it seems like that's the only way to accomplish something like that.
Headless servers in Windows generally run RDC, meaning you can securely remote into them and use GUI or CLI tools as required. You can pull this off in Linux, as well, but it won't have the default security of the Windows solution unless you set it up manually yourself.
@boomzilla said:
As a follow on to that, is it common for cmdlets (or whatever) to prompt for input via a popup box? Like to ask for options or arguments? Because if you're running from explorer, wouldn't that be the only way to get it?
Generally, if it's a script, it doesn't need to ask for options or arguments, or if it does they're fed from the shortcut you used to launch it, or from Scheduled Tasks, or whatever. You can have it prompt with a dialog, but that wouldn't be a very good solution.
@boomzilla said:
I think you're about a minority of one who would say they actually like cmd better than bash.
I don't recall saying that. Can you quote me on it?
Please don't make shit up, then claim I said it. If you're going to reply, reply to what I said, don't reply to the strange whispered words in your insane little head.
@boomzilla said:
It's just amazing how you flaunt your ignorance.
I'm not the one who thinks CMD is how Windows is scripted.
-
blakeyrat, I don't blame you for this, but like 74.1% of the times we disagree is because you seem to assume the computing word revolves around the client side. It's an understandable mistake, though one you make all the time. Reread your past post while thinking about servers, especially ones used by thousands or hundreds of thousands but maintained by a few or even one. GUIs get in the way for these people, and CLI is really the only thing that makes sense. (For a more concrete example, see my previous post.) No, I don't care that for the most part you only care about the client side. For the most part, I only care about the server side. All I'm saying is that your client-side ideals/solutions do not work where the computing power actually lives.
-
@blakeyrat said:
I rarely do those things.
Yes, I think we've all gathered that this is true.
@blakeyrat said:
Windows' GUI for moving files around is superior to bash in many significant ways. You get that lovely recycle bin, for one. You get document previews. It's much easier to look at a list of files and control-click the ones you want, than to type out each file's name in a CLI.
Yes, there are times where those things are convenient in a GUI, if you need that sort of thing. Windows certainly doesn't have a monopoly on that. I don't think anyone has argued that these aren't useful things. But they're not always needed, which is my point. It's amazing that you just can't accept that the picture in your head doesn't apply to everyone.
@blakeyrat said:
@boomzilla said:
There's also the advantage that you don't have to go through layers of menus, or open other processes to get to the utility that you want.
You only have to do that once in a GUI. Welcome to the concept of a "shortcut". (Or "alias", as Classic Mac used to call it.)
Oh, great, now there are a zillion shortcuts. Yes, that cuts through the stuff, but has another downside. Which is worse for a particular user will vary. Obviously, remembering a command to type is worse for you, and that's fine.
@blakeyrat said:
@boomzilla said:
It's not really that much harder than navigating through several layers of control panel, in any case.
Hah. Right!
When you know the sequence to navigate it's easy. Just like it is if you know the command. Are you really that dense? Have you never paid attention when you go into control panel to look for something when you don't know where it is already?
@blakeyrat said:
@boomzilla said:
OK, we were thinking of different things.
No, we weren't "thinking of different things." You misread me.
@boomzilla said:Yes, most linux distros are very much GUI oriented. But they're also fully usable from the CLI.
Its not usable for the things 99% of people want to do with their computers from the CLI, no more than Windows or OS X is.
Who cares about the numbers you pull out of your butt? Yes, most users don't need to see a CLI, although when they ask for help, it's a lot easier to give them a few lines to copy into a script or into a console than a series of menus and / or screen shots. You could replace many many many things in that last sentence of yours, and they would be just as true, and it would still be just as worthless a thing to say.
@blakeyrat said:
Headless servers in Windows generally run RDC, meaning you can securely remote into them and use GUI or CLI tools as required. You can pull this off in Linux, as well, but it won't have the default security of the Windows solution unless you set it up manually yourself.
Yes, I'm aware of RDC. It's not nearly as convenient as ssh, especially over slow connections, for getting simple server type tasks accomplished. And, yes, you can get a remote GUI session on Linux pretty easily. Still, it's a PITA to have to get an RDP session going just to start something up or check in a file on a remote server. That's a personal preference I have after needing to deal with RDP sessions and ssh sessions on a daily basis.
What does "the default security of the Windows solution" mean?
@blakeyrat said:
Generally, if it's a script, it doesn't need to ask for options or arguments, or if it does they're fed from the shortcut you used to launch it, or from Scheduled Tasks, or whatever. You can have it prompt with a dialog, but that wouldn't be a very good solution.
I mean, sure, there are lots of places for straight forward scripts that basically just do the same thing all the time. But there are also lots that you might want to apply to different things, which would require some sort of argument.
@blakeyrat said:
@boomzilla said:
I think you're about a minority of one who would say they actually like cmd better than bash.
I don't recall saying that. Can you quote me on it?
As you say, reading is FUNdamental. It was quoted right above the statement:
@blakeyrat said:However, I think it would be a stretch to claim that CMD is worse than bash.
@blakeyrat said:
Please don't make shit up, then claim I said it. If you're going to reply, reply to what I said, don't reply to the strange whispered words in your insane little head.
There you go...nothing made up. Maybe you didn't mean it. Maybe it was a typo, or " words in your insane little head."@blakeyrat said:
@boomzilla said:
It's just amazing how you flaunt your ignorance.
I'm not the one who thinks CMD is how Windows is scripted.Well, I was asking about how it was done, assuming that PowerShell, MS' shinyest newest scripting system, and then you went on about even older technologies, best known for spreading malware. Did I ever claim to be an expert on Windows scripting? I don't think I ever did.
Please don't make shit up, then claim I said it. If you're going to reply, reply to what I said, don't reply to the strange whispered words in your insane little head.
-
@Xyro said:
blakeyrat, I don't blame you for this, but like 74.1% of the times we disagree is because you seem to assume the computing word revolves around the client side.
It does.
@Xyro said:
Reread your past post while thinking about servers, especially ones used by thousands or hundreds of thousands but maintained by a few or even one. GUIs get in the way for these people, and CLI is really the only thing that makes sense.
No they don't.
And if they did, the solution is building a better GUI, not going back in time.
@Xyro said:
All I'm saying is that your client-side ideals/solutions do not work where the computing power actually lives.
Sure they do. The only real problem is that you lack imagination to see how.
-
@blakeyrat said:
@Xyro said:
blakeyrat, I don't blame you for this, but like 74.1% of the times we disagree is because you seem to assume the computing word revolves around the client side.
It does.
@Xyro said:
Reread your past post while thinking about servers, especially ones used by thousands or hundreds of thousands but maintained by a few or even one. GUIs get in the way for these people, and CLI is really the only thing that makes sense.
No they don't.
And if they did, the solution is building a better GUI, not going back in time.
@Xyro said:
All I'm saying is that your client-side ideals/solutions do not work where the computing power actually lives.
Sure they do. The only real problem is that you lack imagination to see how.
Microsoft itself disagrees with you, Blakey, on the "No they don't". The current generation of server administration, including Exchange, Active Directory, IIS, SQL Server and other services are all adminned using PowerShell and PowerShell plugins. In some cases, there is administrative functionality that cannot be accomplished via a GUI that is done using PowerShell.
-
Wait, does the terminal emulator count as a GUI? Because if so, maybe we're on the same page after all. If not, how would you build a process to automatically create temporary backup directories and move old files into them and zip them up on a daily basis ...using a GUI..? Aside from an AI-backed speech-sensitive LCARS interface, I'm thinking the best a GUI can do is provide pretty pictures around a CLI...
-
@boomzilla said:
But they're not always needed, which is my point.
When is a "save me from my mistakes" feature like the recycle bin not needed? Under what circumstances should deletions due to a typo be impossible to undo? No weasel words, please.
@boomzilla said:
Oh, great, now there are a zillion shortcuts. Yes, that cuts through the stuff, but has another downside. Which is worse for a particular user will vary. Obviously, remembering a command to type is worse for you, and that's fine.
Spatial memory is more powerful than rote memory. This is well-known. Even for the geekiest of geeks.
The problem here is that a lot of GUIs sabotage themselves by, say, re-ordering icons without user interaction, and so that strong spatial memory is mostly wasted. This is unfortunate. But it doesn't make CLIs (in the abstract) superior to GUIs (in the abstract).
@boomzilla said:
Have you never paid attention when you go into control panel to look for something when you don't know where it is already?
You just type in what you want. Want to reverse the left/right mouse buttons? Type in "mouse"... boom. Want to change monitor resolution? Type in "resolution".... boom. Need help finding what option to tweak? There's a full-featured help system to guide you.
How could any CLI interface possibly be more usable than this? I concede that it's possible, but bash is nowhere even remotely close.
@boomzilla said:
Who cares about the numbers you pull out of your butt? Yes, most users don't need to see a CLI, although when they ask for help, it's a lot easier to give them a few lines to copy into a script or into a console than a series of menus and / or screen shots. You could replace many many many things in that last sentence of yours, and they would be just as true, and it would still be just as worthless a thing to say.
The point is that it's fucking stupid to berate someone for using a "GUI-based OS" when you're also using a GUI-based OS. By any reasonable definition of the term "GUI-based".
@boomzilla said:
Yes, I'm aware of RDC. It's not nearly as convenient as ssh,
Bullshit.
@boomzilla said:
especially over slow connections,
Possibly true, but you'd be surprised how little bandwidth RDC requires.
@boomzilla said:
And, yes, you can get a remote GUI session on Linux pretty easily.
But it's not secure by default unless you go out of your way to secure it manually. Why isn't it secure by default? God knows.
@boomzilla said:
Still, it's a PITA to have to get an RDP session going just to start something up or check in a file on a remote server.
If "something" is a service, you can start those up remotely without using RDP. If you're "checking a file" you can map a drive to the server. Those two tasks do not require RDP.
@boomzilla said:
What does "the default security of the Windows solution" mean?
It means RDC sessions are always encypted, by default, without the user having to do something to make it happen. You know, like all network communication between computers should be.
@boomzilla said:
But there are also lots that you might want to apply to different things, which would require some sort of argument.
Your weasel-words piss me off. If you can't provide a SINGLE SPECIFIC EXAMPLE, then you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT.
POP QUIZ TIME: How are these two sentences different?!
@Sentence 1 said:
However, I think it would be a stretch to claim that CMD is worse than bash.
@Sentence 2 said:
I think you're about a minority of one who would say they actually like cmd better than bash.
Put your pencils down, students. The answer is: Sentence 1 doesn't say that the writer of that sentence likes CMD more than bash, and Sentence 2 was written by a complete douchebag who can't read!
@boomzilla said:
Well, I was asking about how it was done, assuming that PowerShell, MS' shinyest newest scripting system, and then you went on about even older technologies, best known for spreading malware. Did I ever claim to be an expert on Windows scripting? I don't think I ever did.
Good, because you have a lot of misconceptions about it.
-
Generally, Unix philosophy is "log in to remote system, and run CLI command there". Windows way is "run a tool on the local machine, that talks to the remote server". Both GUI tools (especially MMC), and CLI tools support (and encourage) remote access.
-
@blakeyrat said:
@boomzilla said:
But they're not always needed, which is my point.
When is a "save me from my mistakes" feature like the recycle bin not needed? Under what circumstances should deletions due to a typo be impossible to undo? No weasel words, please.
In cases like that, it's called backups. Yes, recycle bins are pretty handy. I don't recall saying they weren't. Still, you've brought this up many many times, like deleting things is the only thing anyone ever does. Nevertheless, it's still easier to delete stuff that fits a certain pattern, that can't easily be sorted in a file manager's GUI.
@blakeyrat said:
@boomzilla said:
Oh, great, now there are a zillion shortcuts. Yes, that cuts through the stuff, but has another downside. Which is worse for a particular user will vary. Obviously, remembering a command to type is worse for you, and that's fine.
Spatial memory is more powerful than rote memory. This is well-known. Even for the geekiest of geeks.
Well, typing turns into muscle memory, which isn't rote memory either. I think this is clearly a YMMV. I really hate having to find shortcuts like that, spatially.
@blakeyrat said:
@boomzilla said:
Have you never paid attention when you go into control panel to look for something when you don't know where it is already?
You just type in what you want. Want to reverse the left/right mouse buttons? Type in "mouse"... boom. Want to change monitor resolution? Type in "resolution".... boom. Need help finding what option to tweak? There's a full-featured help system to guide you.
It's true. That is helpful. I haven't used it too much (because my freaking company is still stuck on XP, IE6, which is TRWTF).
@blakeyrat said:
How could any CLI interface possibly be more usable than this? I concede that it's possible, but bash is nowhere even remotely close.
Once you learn, it is indeed faster. At least for many people. Look, I'm not saying that a GUI is worthless, or that one is always better. I don't know why you keep implying this. It's not even pedantic dickweedery. It's just doucebaggery, plain and simple.
@blakeyrat said:
The point is that it's fucking stupid to berate someone for using a "GUI-based OS" when you're also using a GUI-based OS. By any reasonable definition of the term "GUI-based".
"Reasonable," as defined by blakeyrat is anything but. But please, continue to deliberately misunderstand. It's what drives traffic on this site, after all.
@blakeyrat said:
@boomzilla said:
Yes, I'm aware of RDC. It's not nearly as convenient as ssh,
Bullshit.
LOL. Well put. Anther example of air tight blakeylogic.
@blakeyrat said:
@boomzilla said:
especially over slow connections,
Possibly true, but you'd be surprised how little bandwidth RDC requires.
I'm quite familiar with it. But it's still a lot more than a bit of text.
@blakeyrat said:
@boomzilla said:
And, yes, you can get a remote GUI session on Linux pretty easily.
But it's not secure by default unless you go out of your way to secure it manually. Why isn't it secure by default? God knows.
What are you talking about? Are you talking about just forwarding X over the network? If you are, you're the only one. <insert rant about cluelessness>
@blakeyrat said:
@boomzilla said:
Still, it's a PITA to have to get an RDP session going just to start something up or check in a file on a remote server.
If "something" is a service, you can start those up remotely without using RDP. If you're "checking a file" you can map a drive to the server. Those two tasks do not require RDP.
Note: I didn't say "check a file." Yes, it's easy to simply look at files. But try running a simple command on the remote machine. Not to mention, unless you pimp for terminal server licenses, you're limited to 2 remote connections. Something as simple as:
svn ci path/to/my/file@blakeyrat said:
@boomzilla said:
What does "the default security of the Windows solution" mean?
It means RDC sessions are always encypted, by default, without the user having to do something to make it happen. You know, like all network communication between computers should be.
Uh, yeah, like ssh is? Or are you thinking that people are running around using telnet and naked X forwarding all the time?
@blakeyrat said:
@boomzilla said:
But there are also lots that you might want to apply to different things, which would require some sort of argument.
Your weasel-words piss me off. If you can't provide a SINGLE SPECIFIC EXAMPLE, then you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT.
As in, one day I want to apply script foo to the contents of directory bar. The next day I want to apply it to directory baz. It's like you've never called a function with parameters or something. Why is that so difficult to understand?
@blakeyrat said:
POP QUIZ TIME: How are these two sentences different?!
@Sentence 1 said:
However, I think it would be a stretch to claim that CMD is worse than bash.
@Sentence 2 said:
I think you're about a minority of one who would say they actually like cmd better than bash.
Put your pencils down, students. The answer is: Sentence 1 doesn't say that the writer of that sentence likes CMD more than bash, and Sentence 2 was written by a complete douchebag who can't read!
Sorry, likes vs thinks one is better than the other. I suppose you must despise both equally. I'll rephrase, to be more accurate:
I think you're about a minority of one who would say they actually think CMD is better than bash.
@blakeyrat said:@boomzilla said:
Well, I was asking about how it was done, assuming that PowerShell, MS' shinyest newest scripting system, and then you went on about even older technologies, best known for spreading malware. Did I ever claim to be an expert on Windows scripting? I don't think I ever did.
Good, because you have a lot of misconceptions about it.Unfortunately, your BS mill doesn't really help with that.
@blakeyrat said:
@Xyro said:
blakeyrat, I don't blame you for this, but like 74.1% of the times we disagree is because you seem to assume the computing word revolves around the client side.
It does.Except when it doesn't, right? Like how Firefox doesn't use the registry, therefore doesn't play nice with group policy settings, preventing enterprise admins from effectively deploying, right? Or were you making shit up then?
-
@sinistral said:
Microsoft itself disagrees with you, Blakey, on the "No they don't". The current generation of server administration, including Exchange, Active Directory, IIS, SQL Server and other services are all adminned using PowerShell and PowerShell plugins. In some cases, there is administrative functionality that cannot be accomplished via a GUI that is done using PowerShell.
Have you seen how Exchange PowerShell integration works? You do a task in a GUI, it gives you the PowerShell to accomplish the task and you choose to run it now or save it for later. Although you are scripting, you never go to the command line. Save the script in a folder. Double-click on it to run it. Open it in the PowerShell ISE to view/edit it. If it needs parameters, then it will prompt for them when it runs, you don't have to pre-emptively type them on the command line.Scripting and the command line are two worlds that don't necessarily intersect.
-
@boomzilla said:
In cases like that, it's called backups.
So, not being able to UNDO an operation is perfectly acceptable, in fact desirable, because backups always exist 100% of the time on every system forever. Brilliant logic there.
Let's look at a database system. Why shouldn't a CLI have "BEGIN TRANSACTION" and "COMMIT/ROLLBACK" available? That's a pretty good system. Why not? What's the reason that this safety net doesn't exist? (The reason is, of course, that it requires improving bash and bash never changes.)
There's NO REASON for CLIs to be so unforgiving of mistakes, except that CLI developers do not give a shit about their product or their users.
@boomzilla said:
Well, typing turns into muscle memory, which isn't rote memory either. I think this is clearly a YMMV. I really hate having to find shortcuts like that, spatially.
Whether you like it or not is irrelevant. The point is you're better at it.
@boomzilla said:
@blakeyrat said:
@boomzilla said:
Yes, I'm aware of RDC. It's not nearly as convenient as ssh,
Bullshit.
LOL. Well put. Anther example of air tight blakeylogic.
I've had to set up SSH before. I know what a giant pain in the ass it is. We all do. Don't bullshit us.
@boomzilla said:
What are you talking about? Are you talking about just forwarding X over the network? If you are, you're the only one. <insert rant about cluelessness>
Forwarding X, or using VNC. Neither is secure by default. Instead of ranting to me about cluelessness, explain to me why these tools that send important information over a network aren't encrypted by default. What is the reason? Explain.
@boomzilla said:
Sorry, likes vs thinks one is better than the other. I suppose you must despise both equally. I'll rephrase, to be more accurate:
Gasp! You're admitting you didn't read my posting? HELL HAS FROZEN OVER!
@boomzilla said:
Except when it doesn't, right? Like how Firefox doesn't use the registry, therefore doesn't play nice with group policy settings, preventing enterprise admins from effectively deploying, right? Or were you making shit up then?
... what does that have to do with anything?
-
@Jaime said:
Scripting and the command line are two worlds that don't necessarily intersect.
Classic Mac's AppleScript environment was brilliant-- and that OS didn't even have a CLI, or even the concept of one.
-
@blakeyrat said:
@boomzilla said:
In cases like that, it's called backups.
So, not being able to UNDO an operation is perfectly acceptable, in fact desirable, because backups always exist 100% of the time on every system forever. Brilliant logic there.
Let's look at a database system. Why shouldn't a CLI have "BEGIN TRANSACTION" and "COMMIT/ROLLBACK" available? That's a pretty good system. Why not? What's the reason that this safety net doesn't exist? (The reason is, of course, that it requires improving bash and bash never changes.)
There's NO REASON for CLIs to be so unforgiving of mistakes, except that CLI developers do not give a shit about their product or their users.
OMFG...give it a rest. I guess no one cares enough to do that. Except people like you who don't even use a CLI. Since the CLI developers are likely some of the main users of said CLI, if it were a real issue, it would probably be an itch that someone would scratch.
Anyways, I can't even remember the last time I needed to use a recycle bin. Do you use it a lot? Maybe you should slow down. You might not even notice that you made a mistake sometimes.
@blakeyrat said:
@boomzilla said:
Well, typing turns into muscle memory, which isn't rote memory either. I think this is clearly a YMMV. I really hate having to find shortcuts like that, spatially.
Whether you like it or not is irrelevant. The point is you're better at it.I guess the words "muscle" and "rote" look too similar for you to tell apart. It's a common problem among illiterates.
@blakeyrat said:
I've had to set up SSH before. I know what a giant pain in the ass it is. We all do. Don't bullshit us.
What's the pain? I have no idea what you're talking about. If you mean, install an ssh server on Windows, then maybe. I've only played with that a little. But even using ssh from Windows is pretty simple.
@blakeyrat said:
@boomzilla said:
What are you talking about? Are you talking about just forwarding X over the network? If you are, you're the only one. <insert rant about cluelessness>
Forwarding X, or using VNC. Neither is secure by default. Instead of ranting to me about cluelessness, explain to me why these tools that send important information over a network aren't encrypted by default. What is the reason? Explain.
Well, X isn't just used over a network. Why encrypt your own machine talking to itself? I rarely use vnc. You can easily forward an X session over ssh using:
ssh -Y. Though it's not great unless you're on the same LAN. For true remote stuff, I use nomachine, which runs shh and compresses the X session to improve network performance. You can, of course, run VNC over shh, too. I guess if you're really determined to do insecure stuff, there's no one stopping you. Just like no one is stopping you from...scripting with CMD.@blakeyrat said:
@boomzilla said:
Sorry, likes vs thinks one is better than the other. I suppose you must despise both equally. I'll rephrase, to be more accurate:
Gasp! You're admitting you didn't read my posting? HELL HAS FROZEN OVER!
Huh? I said I phrased something poorly. Why do you think I don't read your posts? Maybe because you don't even know what you're posting?
@blakeyrat said:
@boomzilla said:
Except when it doesn't, right? Like how Firefox doesn't use the registry, therefore doesn't play nice with group policy settings, preventing enterprise admins from effectively deploying, right? Or were you making shit up then?
... what does that have to do with anything?
Shit. I knew I'd have to explain your own logic to you. Nice job in removing context. Now, for a trip down recent memory lane:@blakeyrat said:
@Xyro said:
blakeyrat, I don't blame you for this, but like 74.1% of the times we disagree is because you seem to assume the computing word revolves around the client side.
It does.Now, back to this rant. The "client side" doesn't care about Group Policy. They just want their web browser. So, here you are making an argument about why some administrator stuff is important. For most people, that would be enough to spell it out. Since I'm responding to you, however, I know that you need your hand held a little bit more to follow the logic. You claim that it's all about the client side. But you also say that some non-client side stuff is important. Those are mutually exclusive.
Now, you can move the goal posts and explain why you didn't really mean what you wrote in one of those instances.
-
@boomzilla said:
Anyways, I can't even remember the last time I needed to use a recycle bin. Do you use it a lot? Maybe you should slow down. You might not even notice that you made a mistake sometimes.
I don't use my car's airbag very often, but I'm glad it's there.
Since you can't give me a reason why my idea of being able to undo bash commands is a bad idea, I'm going to assume you have no reasons and are an idiot and that I'm smarter than everybody in the entire Linux community put together. Woot.
@boomzilla said:
I guess the words "muscle" and "rote" look too similar for you to tell apart. It's a common problem among illiterates.
No; it's more that the distinction is irrelevant because spatial memory is stronger than either. Plus countering the common claim among idiots that "I like it" == "it's more efficient".
@boomzilla said:
Well, X isn't just used over a network. Why encrypt your own machine talking to itself?
Two response:
1) Why not?
2) Gee, I wonder if the brilliant super-genius developers in charge of X could make it maybe be able to tell the difference between a computer talking to itself and talking over the network and (this is the really slick part) use optimal settings for each situation?@boomzilla said:
You can easily forward an X session over ssh using:
ssh -Y. Though it's not great unless you're on the same LAN. For true remote stuff, I use nomachine, which runs shh and compresses the X session to improve network performance. You can, of course, run VNC over shh, too. I guess if you're really determined to do insecure stuff, there's no one stopping you.But insecure stuff is the default!! This is exactly my complaint. Secure should be the default.
@boomzilla said:
Now, back to this rant. The "client side" doesn't care about Group Policy. They just want their web browser. So, here you are making an argument about why some administrator stuff is important. For most people, that would be enough to spell it out. Since I'm responding to you, however, I know that you need your hand held a little bit more to follow the logic. You claim that it's all about the client side. But you also say that some non-client side stuff is important. Those are mutually exclusive.
How are they mutually-exclusive?
-
@blakeyrat said:
Since you can't give me a reason why my idea of being able to undo bash commands is a bad idea, I'm going to assume you have no reasons and are an idiot and that I'm smarter than everybody in the entire Linux community put together. Woot.
Did Linus kill your dog? Or just eat your brain. Did you remove the shift key from your keyboard to prevent explorer from not sending things to the recycle bin?
@blakeyrat said:
@boomzilla said:
I guess the words "muscle" and "rote" look too similar for you to tell apart. It's a common problem among illiterates.
No; it's more that the distinction is irrelevant because spatial memory is stronger than either. Plus countering the common claim among idiots that "I like it" == "it's more efficient".
Do you have any sort of a reference for that? The best I've done is to find stuff similar to your original claim of spatial vs rote, with which I agree. But these sorts of places assume either spatial or rote, and in that simplified taxonomy, I'd think that muscle memory is probably spatial. Either way, they certainly seem related. I guess it doesn't matter enough anyways, since GUI designers are always sabotaging that by reorganizing, huh?
@blakeyrat said:
@boomzilla said:
Well, X isn't just used over a network. Why encrypt your own machine talking to itself?
Two response:
1) Why not?
2) Gee, I wonder if the brilliant super-genius developers in charge of X could make it maybe be able to tell the difference between a computer talking to itself and talking over the network and (this is the really slick part) use optimal settings for each situation?#1 is just retarded. As a fan of Raymond Chen, you'll be familiar with a new feature starting with negative 100 points in favor. #2 kinda dies by the same logic. Supporting that train of thought, why not leave encryption to the experts? All we need is more people rolling their own encryption, right?
@blakeyrat said:
@boomzilla said:
You can easily forward an X session over ssh using:
ssh -Y. Though it's not great unless you're on the same LAN. For true remote stuff, I use nomachine, which runs shh and compresses the X session to improve network performance. You can, of course, run VNC over shh, too. I guess if you're really determined to do insecure stuff, there's no one stopping you.But insecure stuff is the default!! This is exactly my complaint. Secure should be the default.
The default? No, it's just another option. That's like saying that telnet is the default. Well, maybe that applies to VNC. But VNC is by far not the "default" for anything. Like I said, it's super easy to use an encrypted connection, and possible to not use one. There are probably some backwards compatibility reasons to allow unencrypted sessions.
@blakeyrat said:
@boomzilla said:
Now, back to this rant. The "client side" doesn't care about Group Policy. They just want their web browser. So, here you are making an argument about why some administrator stuff is important. For most people, that would be enough to spell it out. Since I'm responding to you, however, I know that you need your hand held a little bit more to follow the logic. You claim that it's all about the client side. But you also say that some non-client side stuff is important. Those are mutually exclusive.
How are they mutually-exclusive?
Let us examine two analogous statements:
- Everything revolves around A.
- This aspect of Not-A is really important, and you're really stupid to not do it.
-
@boomzilla said:
Did Linus kill your dog? Or just eat your brain. Did you remove the shift key from your keyboard to prevent explorer from not sending things to the recycle bin?
I still haven't heard an explanation of why my proposed "transaction" system for bash is a bad idea. Hard to implement, probably. But bad idea? Illuminate me.
-
@blakeyrat said:
Since you can't give me a reason why my idea of being able to undo bash commands is a bad idea, I'm going to assume you have no reasons and are an idiot and that I'm smarter than everybody in the entire Linux community put together. Woot.
So, in any event, there is at least one implementation. A couple of minutes of looking turned up trash-cli, "Command line interface to the freedesktop.org trashcan.". So, ta da!
-
@blakeyrat said:
I still haven't heard an explanation of why my proposed "transaction" system for bash is a bad idea. Hard to implement, probably. But bad idea? Illuminate me.
Maybe ZFS would fit the bill?
-
@boomzilla said:
@blakeyrat said:
ZFS is copy-on-write, but it doesn't keep track of all of the old blocks, so it would be hard to build a general purpose recycle bin on top of it. Novell's NWFS file system recycled free space based on file deletion time stamp, keeping the entire "empty" area of a volume full of old versions of files. It worked so well that people would delete some of their own files to sneak under a disk quota, knowing they could recover the deleted files reliably. It's funny that a problem that was solved very well in 1985 is still on our radar.I still haven't heard an explanation of why my proposed "transaction" system for bash is a bad idea. Hard to implement, probably. But bad idea? Illuminate me.
Maybe ZFS would fit the bill?
-
@Jaime said:
ZFS is copy-on-write, but it doesn't keep track of all of the old blocks, so it would be hard to build a general purpose recycle bin on top of it.
I don't know much about ZFS, but the block right after the one I linked says:
@wiki said:
Whether you'd want to do that with ZFS, I don't know, but it seems like all the old data is there to me.
Snapshots and clonesAn advantage of copy-on-write is that when ZFS writes new data, the blocks containing the old data can be retained, allowing a snapshot version of the file system to be maintained. ZFS snapshots are created very quickly, since all the data composing the snapshot is already stored; they are also space efficient, since any unchanged data is shared among the file system and its snapshots. Writeable snapshots ("clones") can also be created, resulting in two independent file systems that share a set of blocks. As changes are made to any of the clone file systems, new data blocks are created to reflect those changes, but any unchanged blocks continue to be shared, no matter how many clones exist. This is an implementation of the Copy-on-write principle.
-
@boomzilla said:
@Jaime said:
You have to create a snapshot manually before the problem occurs. That's not very useful as a general purpose recycle bin.ZFS is copy-on-write, but it doesn't keep track of all of the old blocks, so it would be hard to build a general purpose recycle bin on top of it.
I don't know much about ZFS, but the block right after the one I linked says:
@wiki said:
Whether you'd want to do that with ZFS, I don't know, but it seems like all the old data is there to me.
Snapshots and clonesAn advantage of copy-on-write is that when ZFS writes new data, the blocks containing the old data can be retained, allowing a snapshot version of the file system to be maintained. ZFS snapshots are created very quickly, since all the data composing the snapshot is already stored; they are also space efficient, since any unchanged data is shared among the file system and its snapshots. Writeable snapshots ("clones") can also be created, resulting in two independent file systems that share a set of blocks. As changes are made to any of the clone file systems, new data blocks are created to reflect those changes, but any unchanged blocks continue to be shared, no matter how many clones exist. This is an implementation of the Copy-on-write principle.
-
@Jaime said:
You have to create a snapshot manually before the problem occurs. That's not very useful as a general purpose recycle bin.
Well, that would fit well within blakey's transactional model, which was the context in which I brought up ZFS.
-
@boomzilla said:
@Jaime said:
If that's what you meant, then why did you have to dig up ZFS as an example? Good old ext3 and NTFS are journalled file systems that would meet blakey's criteria.You have to create a snapshot manually before the problem occurs. That's not very useful as a general purpose recycle bin.
Well, that would fit well within blakey's transactional model, which was the context in which I brought up ZFS.
-
@Jaime said:
@boomzilla said:
@Jaime said:
If that's what you meant, then why did you have to dig up ZFS as an example? Good old ext3 and NTFS are journalled file systems that would meet blakey's criteria.You have to create a snapshot manually before the problem occurs. That's not very useful as a general purpose recycle bin.
Well, that would fit well within blakey's transactional model, which was the context in which I brought up ZFS.Would it? I'm only as smart here as my last google search. IANAFSE. I just remembered reading about some of the stuff ZFS did, which seemed a bit more extreme, in that sense, so it's what I went with to silence the blakeyrat. So far, so good...
It seems, though, that those journals might not be sufficient. My understanding is that a typical journaling filesystem is keeping track of uncommitted changes, which I think is on a different level (low level, driver / hardware, etc) than what blakey was thinking, which was more like a transaction in an RDBMS.
-
@blakeyrat said:
The problem is, I don't know who told Explorer to open that path.
My guess is it was something in the RunOnce registry key. And since it was in RunOnce, you will never ever be able to find out what the actual command was supposed to be, since the value was deleted as just before it was run.
@fatbull said:On Vista and 7, my Program Files directories are now indeed called Program Files on disk, but the Shell still displays the localized name to me (probably due to some desktop.ini magic).
Was I the only one confused when I saw "Uporabniki" (Users) in the Open dialog box, then found out that typing C:\Up doesn't autocomplete, but typing C:\Uporabniki\ starts autocompleting again, however when you press Enter, you get a nasty "Path does not exist"?@fatbull said:Now that Program Files finally have the same name everywhere (read: hard-coded paths have won), do you really think MS would risk breaking applications semi-randomly from time to time just to prove a point?
Hardcoded paths didn't win, it's just that the way localization works changed with Vista.
@Weng said:The real confusion is that the localized folders still exist.
Not as far as I can see - Explorer just does some magic if you enter the localized name (but as I mentioned above, this magic is incomplete).@Weng said:TRWTF is that Explorer, the common UI dialogs, etc. don't handle symlinks transparently.
Symlinks are handled transparently, however the old name symlinks (C:\Documents and Settings, My * etc. are special kind of symlinks that only let you access stuff beyond them, but don't let you list their content, primarily to prevent old backup software from backing up stuff twice and going into loops (hint: try putting c:\Documents and Settings%USERNAME% in Explorer's address bar, then press Alt+Up to to the parent directory).
@Weng said:Actually, NTFS has supported them for a Long Time(TM) - but they were never exposed via UI or API until Vista.
Symlinks are just special type of reparse points, however their functionality wasn't supported by the OS before Vista (while you can see symlinks created in Vista/7 from XP, they won't work, because the OS doesn't know how to resolve them; only directory junctions work, since those were supported since Windows 2000).
@El_Heffe said:I don't really understand why they felt the need to have separate directories for 64 bit and 32 bit programs -- Program Files and Program Files (x86).
I think this is legacy from !FX32 from Windows NT on Alpha.
-
... what do recycle bins, transactional/CoW/snappshotting file systems, or group policies in the registry have anything at all to do with GUI vs CLI? They're totally orthogonal concepts. I don't want to interfere with the forums' great propensity (culture?) of topic derailment, but I'm confused because in these unrelated discussions, the topic is still brought up. You can have a recycle bin with a command line, just as you can have permanent delete with a graphical file manager. (
alias rm='mv ~/recyclebin'gets you 90% there. The remaining 10% could be written with a simple function but nobody's asking for it.) The direction this thread has taken is bewildering!
-
@Xyro said:
... what do recycle bins, transactional/CoW/snappshotting file systems, or group policies in the registry have anything at all to do with GUI vs CLI? They're totally orthogonal concepts. I don't want to interfere with the forums' great propensity (culture?) of topic derailment, but I'm confused because in these unrelated discussions, the topic is still brought up.
The recycle bin is one of blakeys obsessions regarding CLIs, which is apparently why he always brings it up. Supposedly, its lack as a default mechanism in deleting files proves the inferiority of a CLI over GUI shells like windows explorer. The transactional stuff was an offshoot of that.
-
@boomzilla said:
@Xyro said:
... what do recycle bins, transactional/CoW/snappshotting file systems, or group policies in the registry have anything at all to do with GUI vs CLI? They're totally orthogonal concepts. I don't want to interfere with the forums' great propensity (culture?) of topic derailment, but I'm confused because in these unrelated discussions, the topic is still brought up.
The recycle bin is one of blakeys obsessions regarding CLIs, which is apparently why he always brings it up. Supposedly, its lack as a default mechanism in deleting files proves the inferiority of a CLI over GUI shells like windows explorer. The transactional stuff was an offshoot of that.
The recycle bin example is just an easy example to show that:
1) The CLI is user-hostile
2) CLI developers don't careThere are others, of course, and I mentioned some in this thread. And when you're more user-hostile than SQL, which does implement a type of UNDO operation, that's really saying something.
-
@El_Heffe said:
I don't really understand why they felt the need to have separate directories for 64 bit and 32 bit programs -- Program Files and Program Files (x86). Maybe they thought that somebody might want to install a 64 bit and 32 bit verson of the same program, but I'm not really sure why you would do that. And if you did write a program that comes in both 64 bit and 32 bit versions why not design them so that they install to C:\Program Files\Foobarx64 and C:\Program Files\Foobarx86.
Say for example that you have two programs that you need to work with, and one of them has been updated to 64-bit, but the other one hasn't. If they both use the same shared libraries that support both 32- and 64-bit, then you will need two copies of the same library - one 32-bit and the other 64. But because the libraries are the same (except for the compiled architecture), you can't store them both in the same folder. Thus the solution would be to have two separate folders (one for 32-bit and the other 64).
-
@blakeyrat said:
The recycle bin example is just an easy example to show that:
2) CLI developers don't careWasn't the "Recycle Bin" paradigm introduced with the GUI? And the GUI paradigm was introduced AFTER the CLI? And in Windows, isn't the "Recycle Bin" a special folder that exists somewhere deep in the registry? So really, that should be "[b]GUI developers[/b] don't care. If they did, they would have created a CLI app that could access the Recycle Bin.
-
@dohpaz42 said:
So really, that should be "GUI developers don't care. If they did, they would have created a CLI app that could access the Recycle Bin.
Look, since the point was obviously missed, it is this:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
That's not to say the safety net in the CLI example needs to be identical to the Recycle Bin concept, or identical to the SQL Transaction concept. But it does need to exist in some form or another. The fact that database transactions and GUI recycle bins have been perfected for 20 years, and that CLIs still don't have any similar mechanism is unforgivable in my opinion.
Edit: Another part of the problem is that Boomzilla, instead of saying, "oh yeah I guess that doesn't exist in CLIs... that's a little odd I guess", which I would have been fine with, actually was trying to argue that it shouldn't exist, which is a whole new level of crazy.
-
@blakeyrat said:
Look, since the point was obviously missed, it is this:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
That's not to say the safety net in the CLI example needs to be identical to the Recycle Bin concept, or identical to the SQL Transaction concept. But it does need to exist in some form or another. The fact that database transactions and GUI recycle bins have been perfected for 20 years, and that CLIs still don't have any similar mechanism is unforgivable in my opinion.
Except that these things do exist, but few people care to bother. In blakey's world, not forcing users to use a useful feature that users don't really seem to want is known as "hostile to the user." Why he cares so much about something he doesn't use is another mystery.
-
@blakeyrat said:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
Actually, the biggest problem is that Microsoft chose to implement the recycle bin as part of Explorer instead of as part of the file system driver. This doomed it forever to an inconsistent implementation. Novell got this right back in 1985, their recycle bin (SALVAGE.EXE) did allow a user to undo things that happened on the command line.
-
@boomzilla said:
Except that these things do exist,
Uh? You mentioned to kind of possibilities, one of which doesn't ship on anything by default, and the other requires installing a whole new filesystem. Unless there's something else you haven't yet named. I think "do exist" is a little strong. When it ships by default on every install of bash, then it exists.
@boomzilla said:
Why he cares so much about something he doesn't use is another mystery.
I don't use bash or a CLI much now, but I used it daily when administering a MUD. Which is how, for example, I know you're full of shit when you say setting up SSH isn't complicated.
And I don't use Lotus Notes, either. That doesn't mean I shouldn't care that it's user hostile. I'm in this industry, too. And I don't want products like bash and Lotus Notes giving the rest of us a bad name.
-
@blakeyrat said:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
That safety net helped a lot when one of our clients deleted their zone from the Windows DNS server by accident. Oh, that's right - it didn't!
-
@blakeyrat said:
@boomzilla said:
Except that these things do exist,
Uh? You mentioned to kind of possibilities, one of which doesn't ship on anything by default, and the other requires installing a whole new filesystem. Unless there's something else you haven't yet named. I think "do exist" is a little strong. When it ships by default on every install of bash, then it exists.
@boomzilla said:
Why he cares so much about something he doesn't use is another mystery.
I don't use bash or a CLI much now, but I used it daily when administering a MUD. Which is how, for example, I know you're full of shit when you say setting up SSH isn't complicated.
And I don't use Lotus Notes, either. That doesn't mean I shouldn't care that it's user hostile. I'm in this industry, too. And I don't want products like bash and Lotus Notes giving the rest of us a bad name.
TRWTF is that it took 139 entries in this thread primarily about bad interace design for Lotus Notes to be mentioned.
-
@blakeyrat said:
@boomzilla said:
Except that these things do exist,
Uh? You mentioned to kind of possibilities, one of which doesn't ship on anything by default, and the other requires installing a whole new filesystem. Unless there's something else you haven't yet named. I think "do exist" is a little strong. When it ships by default on every install of bash, then it exists.
WTF are you talking about? Maybe you should change your username to Humpty Dumpty. Anyways, if people did care to have them, I'm sure they would be installed by default.
@blakeyrat said:
I don't use bash or a CLI much now, but I used it daily when administering a MUD. Which is how, for example, I know you're full of shit when you say setting up SSH isn't complicated.
Well, maybe things have changed since then. Here's basically what you do on an apt based linux distro to set up ssh:
# apt-get install openssh-client openssh-server # /etc/init.d/ssh start
Now, you may have more specific things that need configuring, but that will get you going.
@blakeyrat said:
And I don't use Lotus Notes, either. That doesn't mean I shouldn't care that it's user hostile. I'm in this industry, too. And I don't want products like bash and Lotus Notes giving the rest of us a bad name.
I think it's pretty fair to say that you don't really have a clue what bash even is. Or anyways, can't articulate it.
-
@blakeyrat said:
Look, since the point was obviously missed, it is this:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
That doesn't make it better, that makes it different. Besides, you missed my point, which is this:
If, as a GUI user, you feel that you need such safety nets such as the Recycle Bin paradigm when you work in the CLI, implement it. You're a developer, such that you have the capacity for such things. A regular user (read: a non-power user, such as you or me) does need this type of safety net, but more than likely won't be down in the shell working with files in such a capacity; if they are, then they are probably doing it wrong (sound familiar? It should, since you've made this type of argument before on various occasions). With that said, I've worked on the command line for years, and while I have made a few mistakes in the past, I've generally learned to be careful when deleting, or otherwise, modifying files.
@blakeyrat said:
That's not to say the safety net in the CLI example needs to be identical to the Recycle Bin concept, or identical to the SQL Transaction concept. But it does need to exist in some form or another. The fact that database transactions and GUI recycle bins have been perfected for 20 years, and that CLIs still don't have any similar mechanism is unforgivable in my opinion.
So says the GUI guy. A CLI is not a database, and thus does not need transactions. Could you imagine the overhead that would generate if the shell had to keep track of transactions? It wasn't built for that, and probably never will be; especially since in Windows the shell is merely emulated. Besides, nothing is stopping you from writing a script that emulates the GUI's Recycle Bin: merely overload the dele command so that instead of deleting stuff, it just moves it to a central folder (say, Trash or whatever name you want to give it). There's your safety net.
-
@dohpaz42 said:
Besides, nothing is stopping you from writing a script that emulates the GUI's Recycle Bin: merely overload the dele command so that instead of deleting stuff, it just moves it to a central folder (say, Trash or whatever name you want to give it). There's your safety net.
Are you trying to play into blakeyrat's hand? The open source mantra of "if you want it then write it yourself" is evidence that open source is geared towards developers instead of people in general. The statement has a tinge of "if you can't program, then just suck it up and use what we decide to give you".BTW, even if you guys beat blakeyrat on this one point, there are still 99 thousand other examples of GUIs being more usable than CLIs. Even if the CLI has some usability wins, it still loses overall. Merely pointing out one or two wins does not make a preponderance of evidence.
-
@Jaime said:
@dohpaz42 said:
Besides, nothing is stopping you from writing a script that emulates the GUI's Recycle Bin: merely overload the dele command so that instead of deleting stuff, it just moves it to a central folder (say, Trash or whatever name you want to give it). There's your safety net.
Are you trying to play into blakeyrat's hand? The open source mantra of "if you want it then write it yourself" is evidence that open source is geared towards developers instead of people in general. The statement has a tinge of "if you can't program, then just suck it up and use what we decide to give you".Well, his point was that this wasn't a normal user thing to do, which is something that blakey has said a lot, too. Anyways, there are things already written by others that do these things, so...meh. So much of this thread seems to be blakey's blind stumblings while treating RH 5.0 like it was Windows.
@Jaime said:
BTW, even if you guys beat blakeyrat on this one point, there are still 99 thousand other examples of GUIs being more usable than CLIs. Even if the CLI has some usability wins, it still loses overall. Merely pointing out one or two wins does not make a preponderance of evidence.
Good lord. You're bringing up the same false dichotomy that blakey loves. Different tools for different jobs. I haven't seen anyone around here saying they always use the CLI, or even that it's a good idea. There's not really an "overall" that anyone but you or blakey is talking about. You guys have totally bought into the GUI paradigm that Windows follows, and are happily productive. Great! Some of us like more of a mixture, because sometimes we find that a CLI is useful, too.
-
This GUI vs. CLI debate is just getting more and more insane. My points were never addressed, so I'm not going to contribute any more of them.
If anything, we should be arguing about a real issue with our current state of computing in the second decade of the twenty-first century: [i]CISC vs. RISC[/i].
-
@boomzilla said:
Good lord. You're bringing up the same false dichotomy that blakey loves. Different tools for different jobs. I haven't seen anyone around here saying they always use the CLI, or even that it's a good idea. There's not really an "overall" that anyone but you or blakey is talking about. You guys have totally bought into the GUI paradigm that Windows follows, and are happily productive. Great! Some of us like more of a mixture, because sometimes we find that a CLI is useful, too.
Usability is a real thing, not just a statement that "it works for me". Usability is usually broken into five areas (Jakob Nielson's list, not mine):- Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
- Efficiency: Once users have learned the design, how quickly can they perform tasks?
- Memorability: When users return to the design after a period of not using it, how easily can they re establish proficiency?
- Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
- Satisfaction: How pleasant is it to use the design?
Blakeyrat's point about undo fits nicely into the fourth bullet point above. The CLI advocates have stated that they see the CLI doing well on the efficiency point. For me, the big differentiator is learnability. GUIs are naturally exporable and discoverable. Tab completion in a CLI is designed more for efficiency than for learnability. Once you define usability and start assessing models against the definition, it becomes clear that CLI interfaces have poorer usability than even a rudimentary GUI. I'm not saying they don't work and I'm not saying that there aren't things that can only be done at the command line, I'm simply saying that the usability sucks.
Research shows that experts prefer an expert user interface that isn't clutted with stuff for novices. That same research also shows they the experts constantly make the wrong choice and experts that are forced to use the more usable interface are more productive, whether they feel more productive or not.
Another important point is how we got to discussion about CLIs from scripting. For those who think that a script is just a collection of commands that could be issued at a command prompt, this is a logical step. However, for those who mainly write scripts that have functions, control structures, and variables, most of which are incompatible with typing at the command line (except trivial cases), this seems to be a nonsequitur. Typing at a command line is not scripting.
-
@Jaime said:
Usability is a real thing, not just a statement that "it works for me".
This is true, but it's not quite as objective or clear cut as you're trying to make it. As blakeyrat loves to explain, you generally have to test something in order to figure out if it's good or bad.
@Jaime said:
Usability is usually broken into five areas (Jakob Nielson's list, not mine):
- Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
- Efficiency: Once users have learned the design, how quickly can they perform tasks?
- Memorability: When users return to the design after a period of not using it, how easily can they re establish proficiency?
- Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
- Satisfaction: How pleasant is it to use the design?
Blakeyrat's point about undo fits nicely into the fourth bullet point above.
Except that blakeyrat isn't making a point, but simply alleging something he pulled out of his ass. Indeed, how many errors do the users make? For that matter, even with a recycle bin, you have to notice that you made an error in order to correct it. Either way, we're way too focused on deleting files.
@Jaime said:
The CLI advocates have stated that they see the CLI doing well on the efficiency point. For me, the big differentiator is learnability. GUIs are naturally exporable and discoverable. Tab completion in a CLI is designed more for efficiency than for learnability.
Yes, I suspect we all agree with this. I've pretty much said as much in this thread. Tab completion also helps to prevent errors, as anyone who's used some sort of Intellisense can attest.
@Jaime said:
Once you define usability and start assessing models against the definition, it becomes clear that CLI interfaces have poorer usability than even a rudimentary GUI. I'm not saying they don't work and I'm not saying that there aren't things that can only be done at the command line, I'm simply saying that the usability sucks.
Yes, we already got that the usability sucks for you. Maybe you're just doing it wrong. This reminds me about arguing over automatic or manual transmissions. Personally, I hope to never have to drive a manual ever again. But they're still useful in some applications, even though there's a much higher learning curve, and a lot more opportunities for mistakes.
The biggest place where a CLI falls short is in the first, Learnability, which we've already agreed upon. I suspect that for common tasks (remember, no one here is arguing for the straw man of linear video editing--whatever the fuck that is--in a CLI) the CLI will typically beat the GUI in efficency.
@Jaime said:
Research shows that experts prefer an expert user interface that isn't clutted with stuff for novices. That same research also shows they the experts constantly make the wrong choice and experts that are forced to use the more usable interface are more productive, whether they feel more productive or not.
Indeed, I've read similar research. And it equates with my experience. Believe it or not, but I do all sorts of stuff in a GUI environment. But not everything. Sometimes the GUI just gets in the way. Now, you may say that the right GUI just hasn't been written, and maybe you're correct. But for a lot of those things, a superior CLI approach works pretty well for me (and many others), at least until the right GUI designer comes along.
I've agreed with many of blakey's rants about how CLIs could be made better. And GUIs that could be made better. We've got to work with what exists. Actually, what a lot of GUIs lack is good integration with the keyboard. One of the most frustrating things for me is having to go between mouse and keyboard a lot. Some applications are better than others. Excel is one of my favorites for not minimizing the need for the mouse.
@Jaime said:
Another important point is how we got to discussion about CLIs from scripting. For those who think that a script is just a collection of commands that could be issued at a command prompt, this is a logical step. However, for those who mainly write scripts that have functions, control structures, and variables, most of which are incompatible with typing at the command line (except trivial cases), this seems to be a nonsequitur. Typing at a command line is not scripting.
Wrong. Scripting was simply one offshoot of the thread. I'm pretty sure you're the only one who has equated scripting with entering commands in a CLI (over and over and over). Well, maybe blakeyrat, but it's hard to tell sometimes what he really means.
-
@boomzilla said:
I'm pretty sure you're the only one who has equated scripting with entering commands in a CLI (over and over and over). Well, maybe blakeyrat, but it's hard to tell sometimes what he really means.
That would be you, I've said the exact opposite at least ten times in this thread. Here is the first instance:@boomzilla said:
@Jaime said:
If you played with PowerShell in the blue cmd window, then you weren't scripting, you were simply running applets ad-hoc at a command line. By complaining about PowerShell in this context, you were taking the faults of cmd and assigning them to PowerShell.You obviously haven't tried the ISE (Integrated Scripting Environment). Or even tried typing any PowerShell commands in the "blue CMD window".
You're right about ISE. I wasn't aware of it, though I'll check it out. It looks like it provides a more reasonable shell interface. The "blue CMD window" is where I've played around with powershell (minimally). And like I said, it felt pretty much like using cmd, from a user experience POV. There are two things that really suck about it: resizing the console and copying text.
I can live with the tab-completion, though it's much worse than a modern bash shell, especially when it comes to command auto-completion.
-
@Jaime said:
@boomzilla said:
I'm pretty sure you're the only one who has equated scripting with entering commands in a CLI (over and over and over). Well, maybe blakeyrat, but it's hard to tell sometimes what he really means.
That would be you, I've said the exact opposite at least ten times in this thread. Here is the first instance:Are you using some sort of invisible font to prevent me from reading the actual evidence? I really can't see how you get from what I wrote (below) to your equivalence of CLI use and scripting.
@Jaime said:
@boomzilla said:
@Jaime said:
If you played with PowerShell in the blue cmd window, then you weren't scripting, you were simply running applets ad-hoc at a command line. By complaining about PowerShell in this context, you were taking the faults of cmd and assigning them to PowerShell.You obviously haven't tried the ISE (Integrated Scripting Environment). Or even tried typing any PowerShell commands in the "blue CMD window".
You're right about ISE. I wasn't aware of it, though I'll check it out. It looks like it provides a more reasonable shell interface. The "blue CMD window" is where I've played around with powershell (minimally). And like I said, it felt pretty much like using cmd, from a user experience POV. There are two things that really suck about it: resizing the console and copying text.
I can live with the tab-completion, though it's much worse than a modern bash shell, especially when it comes to command auto-completion.
Uh...I was talking about how the old powershell interface was pretty much the same as CMD, so what I was really saying was that they hadn't improved the interface at all at that point, which is similar, but subtly different from what you're saying here. I'm not sure why you said it, anyways.
-
@ender said:
@blakeyrat said:
One of the things that makes the GUI better is that it has a safety net to prevent the accidental deletion of files. CLIs do not have this safety net.
That safety net helped a lot when one of our clients deleted their zone from the Windows DNS server by accident. Oh, that's right - it didn't!It could have been, if they had been using PowerShell. Score one for Mcrosoft (and look, Blakey, MS DOES have exactly what you're asking for. From the Start-Transaction cmdlet documention in Windows PowerShell:
Windows PowerShell Copyright (C) 2009 Microsoft Corporation. All rights reserved. PS C:\Windows\system32> help transaction Name Category Synopsis ---- -------- -------- Get-Transaction Cmdlet Gets the current (active) transaction. Start-Transaction Cmdlet Starts a transaction. Complete-Transaction Cmdlet Commits the active transaction. Undo-Transaction Cmdlet Rolls back the active transaction. Use-Transaction Cmdlet Adds the script block to the active transaction. about_transactions HelpFile Describes how to manage transacted operations in Windows PowerShell. PS C:\Windows\system32> help start-transaction NAME Start-Transaction SYNOPSIS Starts a transaction. SYNTAX Start-Transaction [-Independent] [-RollbackPreference {Error | TerminatingError | Never}] [-Timeout <int>] [-Confir m] [-WhatIf] [<CommonParameters>] DESCRIPTION The Start-Transaction cmdlet starts a transaction, which is a series of commands that are managed as a unit. A tran saction can be completed ("committed"), or it can be completely undone ("rolled back") so that any data changed by the transaction is restored to its original state. Because the commands in a transaction are managed as a unit, eit her all commands are committed or all commands are rolled back. By default, transactions are rolled back automatically if any command in the transaction generates an error, but yo u can use the RollbackPreference parameter to change this behavior. The cmdlets used in a transaction must be designed to support transactions. Cmdlets that support transactions have a UseTransaction parameter. To perform transactions in a provider, the provider must support transactions. The Wind ows PowerShell Registry provider in Windows Vista and later versions of Windows supports transactions. You can also use the Microsoft.PowerShell.Commands.Management.TransactedString class to include expressions in transactions on any version of Windows that supports Windows PowerShell. Other Windows PowerShell providers can also support transa ctions. Only one transaction can be active at a time. If you start a new, independent transaction while a transaction is in progress (neither completed nor undone), the new transaction becomes the active transaction, and you must commit o r roll back the new transaction before making any changes to the original transaction. The Start-Transaction cmdlet is one of a set of cmdlets that support the transactions feature in Windows PowerShell . For more information, see about_Transactions. RELATED LINKS Online version: http://go.microsoft.com/fwlink/?LinkID=135262 about_Transactions Get-Transaction Complete-Transaction Undo-Transaction Use-Transaction REMARKS To see the examples, type: "get-help Start-Transaction -examples". For more information, type: "get-help Start-Transaction -detailed". For technical information, type: "get-help Start-Transaction -full".Since I used pre tags, here's the hyperlink for the documentation: http://go.microsoft.com/fwlink/?LinkID=135262
