Any ideas on this one?
-
@blakeyrat said:
1) Halo was published by Microsoft, it wasn't developed by them
And Microsoft, it seems, enforced the use of the folder. How else would six games by different studios published by the same people use the same folder otherwise? If it was truly an autonomous decision, don't you think maybe one of them would have put them somewhere else? Documents is absolutely the wrong place to put savegames now, but in the early XP days when this happened, and it was likely that players would want to be able to back up their savegames to flash drives or using some backup wizard and putting them in My Documents meant they could be found easily. Now games should be using the Saved Games folder, especially as some now don't run on XP due to being DX9 incompatible, and if Microsoft isn't going to bother using it, nobody is.
-
@Cad Delworth said:
@blakeyrat said:
Just maybe we should stop pretending that it's 1976 and spaces don't exist.
Well, from a text parsing point of view, how would you suggest the parsing code is written so that it can cope with spaces being both an allowed character within parameters (in this case, directory names) AND an allowed delimiter between parameters? It's not just the decision to put a space in a 'critical' directory name, though obviously that highlights this anomaly beautifully.Using an atomic force microscope I still wouldn't be able to see the anomaly.
-
@blakeyrat said:
if you're using CMD in Windows, you're probably doing something wrong.
Totally. You should really be using csh on OpenBSD.
Wait. What?
-
@nexekho said:
@blakeyrat said:
1) Halo was published by Microsoft, it wasn't developed by them
And Microsoft, it seems, enforced the use of the folder. How else would six games by different studios published by the same people use the same folder otherwise?
Why do they all decide to default my 1080p monitor to fucking 1024x768 fullscreen? I don't fucking know; I just know it's annoying as shit.
@nexekho said:
Now games should be using the Saved Games folder, especially as some now don't run on XP due to being DX9 incompatible, and if Microsoft isn't going to bother using it, nobody is.
Well, wait, you're talking about the original Halo, right? The Saved Games folder didn't even exist when it came out, did it?
Is this all filed under "Microsoft does not possess a time machine"?
-
I'm not still talking about the original Halo. However, none of their newer games use the folder. They use the older one, because that's where the older games store it too and that's where people after their savegames expect to find them.
Personally I think separating out your user folder and documents folder is TRWTF because... well, frankly, it's confusing! Go to your documents folder and go into your videos folder. No, wait, it's actually under my user name now. Or maybe I could get it through libraries. Well, I would if they weren't sluggish compared to the normal folders when there's a lot in them.
-
@nexekho said:
However, none of their newer games use the folder.
Like what? Microsoft doesn't even make games anymore, do they? The last game they put out was Flight Sim X, if you even call that a "game"... right? Or am I crazy?
@nexekho said:
Personally I think separating out your user folder and documents folder is TRWTF because... well, frankly, it's confusing! Go to your documents folder and go into your videos folder. No, wait, it's actually under my user name now. Or maybe I could get it through libraries. Well, I would if they weren't sluggish compared to the normal folders when there's a lot in them.
Well, regardless of what you think, when you're writing code for Windows, you have to write code for Windows. When in Rome, do as the Romans do.
-
@blakeyrat said:
C:\ProgramData? What the hell is that?
C:\ProgramData is the new location (beginning with Vista) for configuration data that was previously found in C:\Documents and Settings\Application Data\All Users.Instead of just putting an All Users directory under C:\Users where it actually makes sense, they decided that they just absolutely had to create a whole new name.
-
TRWTF is that there actually is no space in the pathname... PROGRA~1 anyone?
C:\Temp>mkdir "Foo Bar Baz"
C:\Temp>mkdir "Foo Bar Quux"
C:\Temp>echo "" > "Foo Bar Baz"\baz
C:\Temp>echo "" > "Foo Bar Quux"\quux
C:\Temp>dir FOOBAR~1
Volume in drive C is OSDisk
Volume Serial Number is 1292-CC25
Directory of C:\Temp\FOOBAR~1
07/15/2011 03:42 PM <DIR> .
07/15/2011 03:42 PM <DIR> ..
07/15/2011 03:42 PM 5 baz
1 File(s) 5 bytes
2 Dir(s) 41,276,080,128 bytes free
C:\Temp>dir FOOBAR~2
Volume in drive C is OSDisk
Volume Serial Number is 1292-CC25
Directory of C:\Temp\FOOBAR~2
07/15/2011 03:42 PM <DIR> .
07/15/2011 03:42 PM <DIR> ..
07/15/2011 03:42 PM 5 quux
1 File(s) 5 bytes
2 Dir(s) 41,275,600,896 bytes free
C:\Temp>
-
@drunken monk said:
TRWTF is that there actually is no space in the pathname... PROGRA~1 anyone?
It's not clear what your point is here, but I've seen problems on 7-64-bit, where you have "Program Files" and "Program Files (x86)" (or whatever), and incorrect assumptions had been made about what PROGRA~1 would resolve to.
-
@El_Heffe said:
After reading this thread I started noticing the inconsistency in naming
used by Microsoft. For example there's "C:\Program Files" (has a space
in it) and "C:\ProgramData" (no space).I haven't done any research on this at all, but my theory was because it was to maintain backwards compatibility with hardcoded "C:\PROGRA~1\" paths.
Edit: I should learn to realize when a thread goes to the second page before commenting.
-
Bit of a side track, but I'm glad MS went to the shortened Users folder. We use Livelink as a document management system, and it has Explorer Integration. In XP, the Explorer Client's working directory was c:\documents and settings\<username>\Application Data\Opentext\OTLocal\<randomfoldername>\<anotherrandomfoldername>\The Working File.ext. If a person checked out a file from the DMS, and it itself had a long name, the path would hit the length limit and not open. It's alleviated in 7, but it still does show up occasionally. Of course, I have the question the users desire to have 100 character file names.
-
@blakeyrat said:
The real point Microsoft is trying to get out is that if you should never, ever, ever hard-code a path name in your program. They get this message across by semi-randomly renaming folders from time to time. It's inconsistent, and it's kind of stupid (80% stupid that they have to, 20% stupid that they do), but if it produces better software then I'm all for it.
Those folder names were never consistent (until Vista, I think) because they used to be localized. (Note: It's probably better to avoid querying the registry.) 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). 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?
-
@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).
The real confusion is that the localized folders still exist. They are marked hidden and are symlinks to the real folders. Hooray if you're used to make Explorer show hidden files or -yikes!- use a different file browser.
-
@derula said:
@fatbull said:
TRWTF is that Explorer, the common UI dialogs, etc. don't handle symlinks transparently.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).
The real confusion is that the localized folders still exist. They are marked hidden and are symlinks to the real folders. Hooray if you're used to make Explorer show hidden files or -yikes!- use a different file browser.
-
@Weng said:
@derula said:
@fatbull said:
TRWTF is that Explorer, the common UI dialogs, etc. don't handle symlinks transparently.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).
The real confusion is that the localized folders still exist. They are marked hidden and are symlinks to the real folders. Hooray if you're used to make Explorer show hidden files or -yikes!- use a different file browser.
Chill, symlinks have just been introduced in Vista... the home folder was new in XP... Windows is just very slowly catching up with *nix.</flamebait>
-
Brilliant. Fucking brilliant.
-
@derula said:
Chill, symlinks have just been introduced in Vista
Actually, NTFS has supported them for a Long Time(TM) - but they were never exposed via UI or API until Vista.
-
@boomzilla said:
@drunken monk 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.TRWTF is that there actually is no space in the pathname... PROGRA~1 anyone?
It's not clear what your point is here, but I've seen problems on 7-64-bit, where you have "Program Files" and "Program Files (x86)" (or whatever), and incorrect assumptions had been made about what PROGRA~1 would resolve to.
-
The EA Download Manager creates the ProgramData folder for itself on XP.
Some of my EA game shortcuts are in Start>All Programs>Electronic Arts and some are under Start>All Programs>EA Games, so I guess I shouldn't expect any better from them.
-
@El_Heffe said:
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.
Windows is generally designed to be usable by complete idiots who don't know shit.
@El_Heffe said:
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.
Windows is generally designed to run software coded by complete idiots who don't know shit.
-
@blakeyrat said:
Besides, we're talking about Windows-- if you're using Windows, you're probably doing something wrong.
FTFY
-
@blakeyrat said:
-- if you're using CMD in Windows, you're probably doing something wrong.
If you don't occasionally use CMD (or the much superior Take Command) you are a luddite like the Linux/Slashdot crowd you are always complaining about.
-
@El_Heffe said:
I occasionally use cmd.exe, most often when I want to run a cygwin utility but don't want to upset my .bash_history. It's great having a real grep at your DOS command-line.@blakeyrat said:
-- if you're using CMD in Windows, you're probably doing something wrong.
If you don't occasionally use CMD (or the much superior Take Command) you are a luddite like the Linux/Slashdot crowd you are always complaining about.
-
@El_Heffe said:
@blakeyrat said:
-- if you're using CMD in Windows, you're probably doing something wrong.
If you don't occasionally use CMD (or the much superior Take Command) you are a luddite like the Linux/Slashdot crowd you are always complaining about.A non-Luddite would use PowerShell. People who use CMD are the Luddites.
-
@El_Heffe said:
Filed under: copy /ehusxz C:\Users\*.* F:\Backup\
For a second, I thought I saw a U+202E ...
-
@blakeyrat said:
A non-Luddite would use PowerShell. People who use CMD are the Luddites.
I'm sure that a lot of people find the object stuff really useful. But why did MS stick with a shell interface that sucks such a gigantic bag of dicks? For that matter, why does cmd.exe's interface still suck so badly? For all the usability testing they do, it's like no one there has ever tried to use their own shell. It's like they don't really want anyone to use powershell or something.
-
@boomzilla said:
@blakeyrat said:
A non-Luddite would use PowerShell. People who use CMD are the Luddites.
I'm sure that a lot of people find the object stuff really useful. But why did MS stick with a shell interface that sucks such a gigantic bag of dicks? For that matter, why does cmd.exe's interface still suck so badly? For all the usability testing they do, it's like no one there has ever tried to use their own shell. It's like they don't really want anyone to use powershell or something.Well, your opinion on PowerShell is your opinion.
As for CMD, the expectation is that if you want to script Windows, you use JScript or VBScript. CMD is an afterthought.
-
@Z1_Jacob said:
This is just a guess but could you get Process Monitor to run on startup? If it finishes loading before that dialog pops up, maybe you could find out where that incorrect path is being read from.
Or you could just enable boot logging in said program.
-
@blakeyrat said:
Well, your opinion on PowerShell is your opinion.
So your opinion is that they didn't take the code for the cmd.exe window and change the color? Because that's sure how it seemed to me when I tried it.
@blakeyrat said:
As for CMD, the expectation is that if you want to script Windows, you use JScript or VBScript. CMD is an afterthought.
What?! What about powershell? This sounds like another post hoc blakeyrationallization. And a really bad one at that. Even without powershell, this sounds pretty silly. I'd ask for some reference, but I'm afraid that I already have an idea where this originated.
-
@boomzilla said:
@blakeyrat said:
Well, your opinion on PowerShell is your opinion.
So your opinion is that they didn't take the code for the cmd.exe window and change the color? Because that's sure how it seemed to me when I tried it.
@blakeyrat said:
As for CMD, the expectation is that if you want to script Windows, you use JScript or VBScript. CMD is an afterthought.
What?! What about powershell? This sounds like another post hoc blakeyrationallization. And a really bad one at that. Even without powershell, this sounds pretty silly. I'd ask for some reference, but I'm afraid that I already have an idea where this originated.
Stop misreading my posts on purpose. I refuse to believe you're that stupid.
-
-
@blakeyrat said:
Stop misreading my posts on purpose. I refuse to believe you're that stupid.
Huh? We were debating the merits and interfaces of cmd.exe and powershell, and then you start talking about other languages as though they were the default or preferred way to script. Were there words that didn't make it out of your head?
-
@boomzilla said:
@blakeyrat said:
You obviously haven't tried the [url="http://technet.microsoft.com/en-us/library/dd819514.aspx"]ISE[/url] (Integrated Scripting Environment). Or even tried typing any PowerShell commands in the "blue CMD window".Well, your opinion on PowerShell is your opinion.
So your opinion is that they didn't take the code for the cmd.exe window and change the color? Because that's sure how it seemed to me when I tried it.
-
@blakeyrat said:
As for CMD, the expectation is that if you want to script Windows, you use JScript or VBScript. CMD is an afterthought.
CMD is more for backward compatibility than an afterthought. The only reason CMD is any better than COMMAND.COM is because in NT3.1, it was the primary scripting environment, so MS put a teeny bit of effort into it. Until Windows 2000, you couldn't rely on the Windows Scripting Host being installed, so you sometimes had to target CMD.
-
@Jaime said:
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.
-
@boomzilla said:
@Jaime said:
Auto-completion beyond file names and built-in applets is really the domain of Intellisense, not prompt auto-completion. The "Microsoft way" to do it is to use Visual Studio with an [url="http://www.powergui.org/index.jspa"]appropriate plug-in[/url]. This is typical of the kinds of complaints people have when going between NIXes and Windows -- "I can't do x exactly the same way I used to". In the Microsoft world, the command prompt isn't supposed to be a development tool or a place to work out complicated scripting problems. Bash seems to be moving towards becoming a Swiss Army knife, this seems to be more a case of [url="http://www.catb.org/jargon/html/Z/Zawinskis-Law.html"]Zawinski’s Law[/url] than a good thing.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:
Auto-completion beyond file names and built-in applets is really the domain of Intellisense, not prompt auto-completion. The "Microsoft way" to do it is to use Visual Studio with an appropriate plug-in. This is typical of the kinds of complaints people have when going between NIXes and Windows -- "I can't do x exactly the same way I used to". In the Microsoft world, the command prompt isn't supposed to be a development tool or a place to work out complicated scripting problems.
OK, first off, that plug in's page is painful. It's an interesting thing, which has an interesting fusion between the advantages of a GUI (i.e., more discoverable) with a CLI (e.g., easier to script). It's true that we like what we're used to. Still, though it takes more investment in learning and practice, it's hard to beat the efficiency of using a CLI, even on a MS system. The combination of the IDE with a command line is pretty useful (though certainly nothing unfamiliar to *nix).
@Jaime said:
Bash seems to be moving towards becoming a Swiss Army knife, this seems to be more a case of Zawinski’s Law than a good thing.
Maybe it's an example of Zawinski's Law, but only in a similar way to what you can do with powershell or a fancy plugin, which is to say, not really at all. Anyways, aren't things like command shells with their own programming language a toolkit and application platform to begin with, by design? Isn't that their whole purpose?
I dunno, maybe you're confusing bash with running other programs in bash?
-
@boomzilla said:
OK, first off, that plug in's page is painful.
No joke. Ouch.
But the product, if it's any good which I don't know, is the exact kind of innovation the *nix community has completely ignored for the last 20 years. Not just ignored, but is actively hostile towards... stagnation is bad. I'd rather have a PowerShell that evolves (even if it is inferior) than a bash that never, ever, ever changes for any reason ever.
@boomzilla said:
Still, though it takes more investment in learning and practice, it's hard to beat the efficiency of using a CLI, even on a MS system.
Depends on the task, doesn't it? CLI isn't very efficient at linear video editing. It's better at... renaming files I guess? Running tools like awk, I guess, but there's no reason awk couldn't have a good GUI interface except that nobody's bothered building one.
Anyway, what I'm getting at is the CLI is more efficient than the GUI at about 3 tasks, none of which average users ever need, and half of which advanced users wouldn't need, either, if the GUIs were made more comprehensive. And saying "more efficient" is useless unless you tell of what it's more efficient for.
@boomzilla said:
The combination of the IDE with a command line is pretty useful (though certainly nothing unfamiliar to *nix).
Most *nix users I see don't even acknowledge of the need for an IDE at all.
-
@blakeyrat said:
And saying "more efficient" is useless unless you tell of what it's more efficient for.
Because that's what the textbook says, duh![quote user="User Interface Design and Evaluation. Stone et al. ISBN 0-12-088436-4"]Command line interfaces are powerful because they offer access to system functionality. They are also flexible: the command often has a number of options or parameters that will vary its behavior in some way, and it can be applied to many objects at once, making it useful for repetitive tasks.[/quote]
All of that is, of course, total bullshit, because you can do all the same things from a properly designed GUI. This quote from later on in the book is much, much more true. Emphasis is mine.
[quote user="User Interface Design and Evaluation. Stone et al. ISBN 0-12-088436-4"]Command line interfaces are better for expert users than for novices. For expert users, command languages provide a sense of being in control. Users learn the syntax and can express complex possibilities rapidly, without having to read distracting prompts.[/quote] That last sentence is mostly bullshit for a properly designed GUI but holds a grain of truth - otherwise, we wouldn't be writing any code at all.
I knew there was a reason I kept my college textbooks. They're so full of stupid shit.
-
@boomzilla said:
The combination of the IDE with a command line is pretty useful (though certainly nothing unfamiliar to *nix).
The PowerShell ISE is a combination of a CLI and and IDE. The plugin I referenced is for a full-on IDE. I think that's where the *nix mentality and the MS mentality diverge. I see script writing as a development task, not something that you should run as you're building it, at least for scripts that are non-trivial. For me, the thought that the environment that is helping me write a line of a script will gladly execute it when I press enter is not a good thing.
Bash is a shell, not a script editor. How would auto-completion in bash help you to write better scripts? By the same logic, the PowerShell command line doesn't need to be any better, just the development tools. The only time you're at the command line doing interesting things is when you aren't using a script, in which case, the scripting capabilities are irrelevant.
@boomzilla said:It's an interesting thing, which has an interesting fusion between the advantages of a GUI (i.e., more discoverable) with a CLI (e.g., easier to script).
Welcome to Visual Studio, the best development environment ever created (and free-as-in-beer to boot). It is nothing like a CLI and doesn't pretend to help you run things (outside the context of debugging). It's a great example of what a software ecosystem becomes if it has a strong leader that has the power to set standards. In Linux, it would be hard to get enough momentum behind a single platform that everybody builds their development tools as a plugin to it. In the Windows world, Visual Studio provides the experience and the plugins provide the ability to work with specific content.
-
@blakeyrat said:
But the product, if it's any good which I don't know, is the exact kind of innovation the *nix community has completely ignored for the last 20 years. Not just ignored, but is actively hostile towards... stagnation is bad. I'd rather have a PowerShell that evolves (even if it is inferior) than a bash that never, ever, ever changes for any reason ever.
What are you talking about? This is basically an editor that uses powershell. It looks pretty cool, and the code generation reminds me of recording macros in, say, Excel, which is pretty handy if you don't know how to get at something. I'm not sure why you think that bash never changes.
@blakeyrat said:
Depends on the task, doesn't it? CLI isn't very efficient at linear video editing. It's better at... renaming files I guess? Running tools like awk, I guess, but there's no reason awk couldn't have a good GUI interface except that nobody's bothered building one.
Anyway, what I'm getting at is the CLI is more efficient than the GUI at about 3 tasks, none of which average users ever need, and half of which advanced users wouldn't need, either, if the GUIs were made more comprehensive. And saying "more efficient" is useless unless you tell of what it's more efficient for.
It's true, but then the same thing is true for powershell or this powergui thing. We might as well say that it's the rare user who would use Visual Studio, so it must be a worthless tool. I'm glad you've found 3 tasks. Obviously many other people find it useful for many more. Of course, that's not surprising, given that you mainly use an OS that is built around the GUI.
@blakeyrat said:
Most *nix users I see don't even acknowledge of the need for an IDE at all.
More like, they use lots of different tools which become an IDE, rather than something monolithic.@Weng said:
[quote user="User Interface Design and Evaluation. Stone et al. ISBN 0-12-088436-4"]Command line interfaces are powerful because they offer access to system functionality. They are also flexible: the command often has a number of options or parameters that will vary its behavior in some way, and it can be applied to many objects at once, making it useful for repetitive tasks.
All of that is, of course, total bullshit, because you can do all the same things from a properly designed GUI. This quote from later on in the book is much, much more true. Emphasis is mine.
[/quote]In theory, you're probably right. But the typical GUI would require digging into submenus and hunting for checkboxes to get at that stuff. Again, probably more discoverable (though not always), but not really more efficient.
@Jaime said:
I see script writing as a development task, not something that you should run as you're building it, at least for scripts that are non-trivial. For me, the thought that the environment that is helping me write a line of a script will gladly execute it when I press enter is not a good thing.
Well, there's writing a script and running a script. You can press enter or click a button, I suppose.
@Jaime said:
Bash is a shell, not a script editor. How would auto-completion in bash help you to write better scripts? By the same logic, the PowerShell command line doesn't need to be any better, just the development tools. The only time you're at the command line doing interesting things is when you aren't using a script, in which case, the scripting capabilities are irrelevant.
Where's blakey on this one? Sucky interface doesn't matter? OK, sure.
@Jaime said:
Most *nix users I see don't even acknowledge of the need for an IDE at all.
It's just another divergence of philosophy, although I think many people do use a single monolithic IDE. It's kind of like the cycles we see between thick and thin clients, or system on a chip vs multiple chips. Both have advantages and disadvantages. I'm happy for you that you really like VS.
-
@blakeyrat said:
Depends on the task, doesn't it? CLI isn't very efficient at linear video editing. It's better at... renaming files I guess?
Hey, I use ffmpeg all the time.
-
@boomzilla said:
I'm not sure why you think that bash never changes.
... because it doesn't?
@boomzilla said:
It's true, but then the same thing is true for powershell or this powergui thing.
Look, as I said, I really don't know anything about PowerGUI except it has an awful website, so I'm sorry I mentioned it at all. Even though I explicitly mentioned that I know nothing about PowerGUI except that it has an awful website in my last post, apparently just mentioning its name is enough to make you a super-expert here in Pedantic Dickweed Land.
And point 2: DUUUUUH. The difference is that Windows users aren't idiots who say things like "the CLI is more efficient" because they know it's at best misleading. And they have a general attitude of "computers are for users" that doesn't exist in the Linux "computers are for developers only" world.
@boomzilla said:
Obviously many other people find it useful for many more.
Like what?
@boomzilla said:
Of course, that's not surprising, given that you mainly use an OS that is built around the GUI.
So do you. The difference between me and you is that I'm not deluding myself.
@boomzilla said:
More like, they use lots of different tools which become an IDE, rather than something monolithic.
Cobbling together crap only produces cobbled together crap. If there's no integrated debugger, it's not an IDE by any definition, and you can't get an integrated debugger by cobbling together crap.
@boomzilla said:
@Jaime said:
Bash is a shell, not a script editor. How would auto-completion in bash help you to write better scripts? By the same logic, the PowerShell command line doesn't need to be any better, just the development tools. The only time you're at the command line doing interesting things is when you aren't using a script, in which case, the scripting capabilities are irrelevant.
Where's blakey on this one? Sucky interface doesn't matter? OK, sure.
Huh? Where did Jaime say anything about sucky interface?
-
@Zemm said:
@blakeyrat said:
Depends on the task, doesn't it? CLI isn't very efficient at linear video editing. It's better at... renaming files I guess?
Hey, I use ffmpeg all the time.
ffmpeg isn't a linear video editor... and there are passable GUIs available for it... so... good job?
-
@blakeyrat said:
@boomzilla said:
I'm not sure why you think that bash never changes.
... because it doesn't?Ah. Because you don't care and can't be bothered to find out. Or haven't really used it over any period to notice improvements.
@blakeyrat said:
@boomzilla said:
It's true, but then the same thing is true for powershell or this powergui thing.
Look, as I said, I really don't know anything about PowerGUI except it has an awful website, so I'm sorry I mentioned it at all. Even though I explicitly mentioned that I know nothing about PowerGUI except that it has an awful website in my last post, apparently just mentioning its name is enough to make you a super-expert here in Pedantic Dickweed Land.
WTF are you talking about? You're not even responding to what I was saying. Did you notice the parts where I complimented them? Your Windows fanboism is way too over the top to notice that I'm actually interested in learning and seeing what these tools have to offer. I was pointing out that you made a silly comment, trying to apply one particular thing to the world, like it's completely irrelevant, and shouldn't be given any more thought by anyone. Here we are, back in blakey's parochial world.
@blakeyrat said:
And point 2: DUUUUUH. The difference is that Windows users aren't idiots who say things like "the CLI is more efficient" because they know it's at best misleading because blakeyrat can't figure it out. And
they haveblakeyrat has a general attitude of "computers are for users"that doesn't exist in the Linux "computers are for developers only" worldand he can't imagine every user doesn't operate like he does.
FTFY@blakeyrat said:
@boomzilla said:
Obviously many other people find it useful for many more.
Like what?
General system tasks, building software, running software. Look, I get it that you're not comfortable with a CLI. And I've never said that everyone has to use one, or would even benefit from it. About half of what you write on this topic assumes that the other person holds those opinions.
@blakeyrat said:
@boomzilla said:
Of course, that's not surprising, given that you mainly use an OS that is built around the GUI.
So do you. The difference between me and you is that I'm not deluding myself.
Right, right. I'm deluded as to what I do on a daily basis. So are all the others who actually find a CLI useful.
@blakeyrat said:
@boomzilla said:
More like, they use lots of different tools which become an IDE, rather than something monolithic.
Cobbling together crap only produces cobbled together crap. If there's no integrated debugger, it's not an IDE by any definition, and you can't get an integrated debugger by cobbling together crap.
Oh, right. It's all open source hippies and shitty interfaces. I forgot about that while I was being productive.
@blakeyrat said:
@boomzilla said:
@Jaime said:
Bash is a shell, not a script editor. How would auto-completion in bash help you to write better scripts? By the same logic, the PowerShell command line doesn't need to be any better, just the development tools. The only time you're at the command line doing interesting things is when you aren't using a script, in which case, the scripting capabilities are irrelevant.
Where's blakey on this one? Sucky interface doesn't matter? OK, sure.
Huh? Where did Jaime say anything about sucky interface?
He's basically saying that the shitty interface on cmd.exe and powershell are OK because he doesn't care to use those tools in a way that exposes how shitty they are. I know this is difficult for you, because you have such a hard on for GUIs, but a CLI is still an interface, and it's possible to do it better or worse. Cmd.exe and powershell just happen to have done it poorly. Again, he's excusing their shitty interface.
-
@boomzilla said:
Ah. Because you don't care and can't be bothered to find out. Or haven't really used it over any period to notice improvements.
Well, maybe name some?
@boomzilla said:
Here we are, back in blakey's parochial world.
My world is not even of or relating to a church parish! You take that back!
@boomzilla said:
General system tasks, building software, running software.
What is a "general system task?" Use more weasel words, please! You almost came too close to saying something specific!
Building software is better done in a graphical IDE. Running software is better done in a graphical shell, unless the software is poorly-designed.
So I said there's 3 things a CLI is better than a GUI at. The number was an asspull, but let's go ahead and go with it. You've named 3 things in response, one of which is too vague to be useful, and the other two are invalid. Surprisingly, you didn't name any of the 3 that I had in mind, although your vague one might encompass one of those and technically "running software" encompasses all of them.
@boomzilla said:
Right, right. I'm deluded as to what I do on a daily basis. So are all the others who actually find a CLI useful.
No. You misread me. Read it again.
You're deluding yourself if you think that Linux distros aren't based on the GUI as much as Windows or OS X is.
@boomzilla said:
Oh, right. It's all open source hippies and shitty interfaces. I forgot about that while I was being productive.
Look, I fully admit that there are a few tasks for which a CLI is significantly more productive than a GUI. I've never stated otherwise.
The problems are:
1) The learning curve is criminal
2) The punishment for small mistakes is insanely severe (there's no undo in Bash)
3) The few tasks it's better at are tasks that 99% of users will never need to performIf you're being productive doing software development in a CLI, congratulations! You get a cookie! But you'd probably be more productive using a well-designed IDE. And that is what matters.
@boomzilla said:
He's basically saying that the shitty interface on cmd.exe and powershell are OK because he doesn't care to use those tools in a way that exposes how shitty they are.
No; he's saying that if you script Windows the way it's intended to be scripted (VBScript, JScript, PowerShell), you don't care about the shitty interface of CMD because you never use CMD. I dunno; maybe he was saying what you claim, and I'm too lazy to go back and re-read it. But I think it's much more likely you don't understand that scripting Windows doesn't involve using CMD at all. CMD and Notepad are both in the same boat-- they both exist purely for backwards-compatibility, but there are tons of idiots who keep using them and bitch to Microsoft about how bad they are.
@boomzilla said:
I know this is difficult for you, because you have such a hard on for GUIs, but a CLI is still an interface, and it's possible to do it better or worse.
Duh. Again, I never claimed otherwise.
However, I think it would be a stretch to claim that CMD is worse than bash. For one thing, "HELP" in CMD does something useful.
-
@blakeyrat said:
@boomzilla said:
Yes, that's what I was saying.@blakeyrat said:He's basically saying that the shitty interface on cmd.exe and powershell are OK because he doesn't care to use those tools in a way that exposes how shitty they are.
No; he's saying that if you script Windows the way it's intended to be scripted (VBScript, JScript, PowerShell), you don't care about the shitty interface of CMD because you never use CMD. I dunno; maybe he was saying what you claim, and I'm too lazy to go back and re-read it. But I think it's much more likely you don't understand that scripting Windows doesn't involve using CMD at all. CMD and Notepad are both in the same boat-- they both exist purely for backwards-compatibility, but there are tons of idiots who keep using them and bitch to Microsoft about how bad they are.However, I think it would be a stretch to claim that CMD is worse than bash. For one thing, "HELP" in CMD does something useful.
bash is better than CMD in many ways. For example, every bash shell I've used supports commands up to 32K in length, sometimes as long as 256K. The scary part is that many common linux commands are that long (watch the screen scroll by during a build some day). I'm with you that Windows people generally don't care, because we are rarely in CMD and when we are, it does exactly what we want it to do, including passable cut and paste support and decent file name autocompletion.
-
@blakeyrat said:
My world is not even of or relating to a church parish!
OK, I give in. At the risk of being trolled:
@Merriam-Webster said:parochial:
(from definition 3) limited in range or scope (as to a narrow area or region)
examples usage: "voters worried about their own parochial concerns"
@blakeyrat said:
@boomzilla said:
Ah. Because you don't care and can't be bothered to find out. Or haven't really used it over any period to notice improvements.
Well, maybe name some?From a quick google search.
@blakeyrat said:
@boomzilla said:
General system tasks, building software, running software.
What is a "general system task?" Use more weasel words, please! You almost came too close to saying something specific!
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. 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. Admittedly, this is at the expense of a steeper learning curve. But I don't think it borders on "criminal," especially with all of the resources available on the internet to find what you need when you get stuck. It's not really that much harder than navigating through several layers of control panel, in any case.
@blakeyrat said:
Building software is better for me
donein a graphical IDE. Running software is better done for me in a graphical shell, unless the software is poorly-designed.Yes, I use a GUI based editor. And yes, I've used IDEs, including VS, which has impressive features. But please stop projecting so much.
@blakeyrat said:
You're deluding yourself if you think that Linux distros aren't based on the GUI as much as Windows or OS X is.
OK, we were thinking of different things. Yes, most linux distros are very much GUI oriented. But they're also fully usable from the CLI. Obviously, things like headless servers usually are run that way entirely. 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. There are certainly lots of CLI programs that come with Windows, but they seem to be used a lot less than CLI stuff on other systems, and it's generally more of a PITA to use them remotely. Of course, you can do all sorts of stuff with group policy, etc, when you have AD set up, but that's a lot of infrastructure for, say, a home network.
@blakeyrat said:
No; he's saying that if you script Windows the way it's intended to be scripted (VBScript, JScript, PowerShell), you don't care about the shitty interface of CMD because you never use CMD.
I can give cmd a pass for backwards compatibility. And maybe the "blue cmd" of powershell has improved with 2.0...I haven't used it. But even so, running powershell scripts in the powershell prompt seems...reasonable.
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? I'd guess that the ISI's CLI would have the ability to do that. I haven't gotten my hands on it yet, so maybe that's MS's answer to the general CMD / PowerShell console suckage.
@blakeyrat said:
However, I think it would be a stretch to claim that CMD is worse than bash. For one thing, "HELP" in CMD does something useful.
As opposed to....
$ help GNU bash, version 4.2.8(1)-release (x86_64-pc-linux-gnu) These shell commands are defined internally. Type `help' to see this list. Type `help name' to find out more about the function `name'. Use `info bash' to find out more about the shell in general. Use `man -k' or `info' to find out more about commands not in this list. A star (*) next to a name means that the command is disabled. ....lots of command type stuff here...
I think you're about a minority of one who would say they actually like cmd better than bash. Obviously, as a primarily windows guy, you shouldn't be using it, you should be using whatever powershell stuff does. It's just amazing how you flaunt your ignorance.
-
This useless debate would be better staged in that fun-filled thread about environmentalism, politics, and religion.
Alternatively, I could get sucked into the whirlpool of blakeyrant™ by adding my pennies: generally speaking, mouse-driven GUIs are awful at bulk operations, whereas in the CLI world, bulk operations are just as easy as individual operations. Recent example from my own lands: we need to zip some group of input files on a daily basis before deleting them for good, you know, "just in case" the business users come back to use a few days later complaining about bad data. So we have a simple script that creates a directory based on the date, moves the files older than yesterday to that folder, and then compresses the folder. It's not hard to do with Unix shells. We all know it's possible within the Windows ecosystems, but... I'd rather just
mkdir -pm 775 archive/$date && tar cf - $dir | compress -f - > archive/$date/$dir.tar.Z && rm -rf $dir(and hey, no huge temporary files either!)
-
@Jaime said:
For example, every bash shell I've used supports commands up to 32K in length, sometimes as long as 256K. The scary part is that many common linux commands are that long (watch the screen scroll by during a build some day).
Those giant lines are usually the linking (though sometimes compiler options get huge). On windows, that stuff usually gets written to a file, and the name of the file passed to the compiler / linker.
@Jaime said:
I'm with you that Windows people generally don't care, because we are rarely in CMD and when we are, it does exactly what we want it to do, including passable cut and paste support and decent file name autocompletion.
Autocompletion is reasonable, although cycling through options rather than showing a list can be annoying. 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.
