- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Other people don't have your computer.
Admin
You have a point, but you take it too far. Computers aren't capable of thinking like humans. At least not yet. Therefore, as a human using a computer, sometimes you have to think like it would.
Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path.
Admin
Admin
Wait a minute? I thought Mac machines were always the paragon of stability and thats why people used them, not because people thought themselves to elite for Winboxes? This has to be troll food.
Admin
Yep. Out of all of the stuff in this WTF, what annoyed me the most was the author saying "...would allow it’s communications to pass through the firewall"
It SO breaks up the flow of reading the text to come across a typo like this.
Admin
Admin
Admin
Admin
When I said "This", how do you know I wasn't self referencing?
Admin
But this isn't brain dead behaviour. This behaviour would have to intentionally be written in this terrible method. I also do not believe that it existed ever.
Admin
Actually, it's the other way around. At least when storing to HFS+ disks, the native path separator even for Mac OS X is the colon. If you access files through most of the high-level APIs, particularly Carbon (the Mac OS 9 compatible API), then forward-slash is allowed in files, colon is disallowed, and colon is the path separator.
However, if you access files through the BSD APIs, forward-slash is the path separator. So, there is an automatic translation from forward-slash to colon and vice versa. Thus, creating a file "a:b" through a BSD API will result in a file "a/b" on disk. An existing file "c/d" on disk will appear through a BSD API (e.g., ls) as "c:d". So then forward-slash is a disallowed character in filenames but colon is allowed. So in the end you have compatibility with both Mac OS 9 and with BSD.
HFS+ technically permits any characters in filenames, colon is just barred by the OS. Any other characters will work, depending on the API. Some weird characters are unlikely to work unless you're particularly careful. For example, Mac OS X stores some internal data in a directory whose name starts with four null characters, virtually guaranteeing that it is a pain to access. (In order to render it in a C string, they use a UTF-8 encoding for a null that is technically invalid but conveniently contains no nulls.)
Admin
I would say there are three separate separators. The first separates path components. The second separates arguments in a CLI. The third separates "words" within an argument. The first two, not just the first one, are basically new to technology. (The closest analogy to the second which I can think of off the top of my head is the separation of function arguments in math, which is traditionally done with the comma.)
All three of those separators "must" exist regardless of what file system choices you make, unless you want echo "Hello world" to not work. Thus if you decide that the character 0x20 should act as a separator for both arguments and words within an argument (the latter is definitely reasonable, unless you want something like echo "Hello_world" to actually output Hello world), we already need and have a means for distinguishing the two.
And because we already invented escaping, there's no fundamentally new problem that is introduced by having spaces in file names. The biggest problem now is that tools have to realize that spaces can't be used to separate file names. But the fact that they don't always do is just a matter of lazy coding IMO rather than "this is a hard problem to solve."
Absolutely, which is why I qualified my statement with "as best as possible." And dealing with odd characters in file names is not something that is hard. (Or rather, it's something that, when it is hard, is sort of "artificially" hard because other people made bad decisions.) Yes, I agree it needs a deterministic way of parsing a path. But the only thing you need for that is one single path separator, plus perhaps an end-of-string terminator. POSIX gets away just fine saying that any character is allowed in a file name except for / and NUL. And you don't even need to exclude those if you use an different representation, e.g. ["a", "b", "c"] instead of "a/b/c".That does push the problem up the stack a little bit, but it's just a matter of escaping. And fortunately, we know how to do that.
I mean, flip things around. Spaces aren't the only character that causes problems; as pointed out earlier, hyphens can too. Should we exclude those as well?
Admin
Even before that, Red Hat Linux was doing a halfway decent job of package management, but only halfway.
Admin
After some French TV show pronounced MMORPG as "meuporg", a meme has been born. http://www.youtube.com/watch?v=MwiCLnlJeco
Admin
But then you turned it to (paraphrasing) "we should support the top X% of people". Different design criteria. But let's suppose that is "axiomatic" as you claim. Most people, when they have some data to capture and organize, create a spreadsheet. Never mind that a bunch of computer scientists came up with formal rules for optimal data accuracy decades ago, have been improving on it ever since, and there are carefully crafted databases (engines and schemas) implementing this designed-for-reliability-and-performance architecture. You'd toss it all, because it doesn't win the popular vote?
There are well thought out good ways to design and build good systems. There are also sloppy hackarounds. The masses are not qualified to tell the difference. You should be, if you're in this business. Stop using popularity to determine what is right.
Admin
There are two places where characters need to be interpreted; in Unix, different decisions are made at each place, and neither one restricts the choice of spaces.
At the level of the kernel (you can substitute other APIs here as well), the choice was made to (1) not allow escapes and (2) always use / as a directory separator. As a consequence, it is not possible to use / in file names. However, spaces at this level cause absolutely zero problems; the only special character is / (and NUL for the terminator).
Two more points about this level. First, theoretically it would have been possible to use spaces as a directory separator. But that's not your argument, nor is it a good idea (at least I'd argue). A large part of that has to do with the frequency of characters. You could use A as a directory separator. Why's this a terrible idea? Because A is a common character that you'd actually want to be able to use in file names! Sure, you could always write _ for A, but that'd become a PITA. IMO, spaces in file names are similar, though obviously less extreme. Character frequency shouldn't be the only design factor (you also want something that is evocative of a separator), but it certainly should be one. (And to tie this into my last comment, this is because choosing a frequent character, like A, will annoy too many of your users.)
Second, the Unix way is not the only way. You could modify either of its assumptions and either provide some way for / to be escaped or a different API entirely (["a", "b", "c"]). Such an API would enable the use of / in file names. If you change to counted strings (I'll call them "God's strings" because this thread doesn't have enough dispute in it yet :-)) then you could also allow NUL and thus any character in your file names.
(I think any of these choices is somewhat reasonable; if I were to make an OS, I'd probably go with the ["a", "b", "c"] API. Perhaps with a wrapper that uses / but allows escapes.)
The second level that has to interpret characters is the shell. CLIs are the main locus of problems; GUIs are almost problem-free in comparison. But shells also have no fundamental problem with spaces, because you can escape any character in the shell.
The only real problems with spaces are because of what I consider poor decisions (granted from the standpoint of spaces should be allowed) and lazy coding. But there are almost no actually hard problems to solve, it just requires conscious thought and a recognition that there are "obnoxious" file names. (E.g. -print0 can't have been hard to add to find, nor -0 to xargs. Though how I really feel about that is in part a whole other discussion -- basically I think the Unix utilities are pretty fundamentally flawed and don't work nearly as well together in pipelines as Unix proponents like to think they do.)
But it's not even a question in my mind that it's worth paying attention to such file names, even if you were to design a system from scratch. The usability benefits of allowing spaces and other funky characters far outweigh the inconveniences they allow.
Admin
[quote user="deckard"][quote user="Andrew"][quote user="deckard"] CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. [/quote]
Then why does cmd.exe empirically not work this way?[/quote] Because CMD validates the user input first. It only assumes the user wants to launch a new process if the user enters a valid string. CreateProcess doesn't return the error message that CMD does on entering an invalid path, for example.
Admin
Windows XP, Vista, 7, and 8 all do this. Just look at your startup items in the registry and startmenu->programs->startup. Many programs have the stupid mistake of setting their startup entries to not have quotes on the path. So you have C:\Program Files\McJaffa Scan Naow\Scanner.exe, but sometime later the user installs McJaffa Suite which installs in C:\Program Files\McJaffa\Suite\av.exe Suddenly the startup entry that was launching the Scan Naow app is opening the C:\Program Files\McJaffa folder at every start!
Admin
I always wondered why/how this line in an AutoHotKey script actually worked:
Run, C:\Games\DCS A-10C\bin\dcs.exe --net-mode gui, C:\Games\DCS A-10C
Yes, the "--net-mode gui" part is a parameter to dcs.exe.
I guess now I know! Lots of the program's instructions are basically just wrappers around Windows API calls.
Admin
Admin
All turds indeed, but I'm not sure Redmond is hell bent on making crap, I believe the substantial improvements with XP and 7 are proof that some things can push them towards better solutions - even if it remains microsoft-y.
That way I believe the linux vs Windows war may end, when Redmond will create a linux based windows compatible monster at some point - or when they make a windows that's globally as fine as a linux, including GUI.
What's way more interesting nowadays is flaming osX anyway, it's so much worse than windows and linux both - fail security, no fucking maximize button on windows and other retarded crap... I think microsoft have found a competitor.
Admin
Well that'll teach you to use a user OS for server purposes.
Seriously, if you're going to use windows, you could also respect its windowsness instead of trying to play it leet without c drive -- while using the noobest OS of all .
Admin
Admin
Admin
Final Fantasy XI didn't launch until the 2000s, for what it's worth. It couldn't have, for Final Fantasy X wasn't out until 2001 itself. :)
Admin
This doesn't make the story bull. It doesn't matter whether Windows was going to give up after the first try, or try again with the first space as part of the command, because just the first try (C:\Program "Files\etc") would cause the error described.
Admin
Admin
Windows actually does that? That's a WTF right there...
Admin
Admin
IT WORKS even in Windows 7. When you try to REMOVE quotes when editing a shortcut, Windows 7 adds them BACK (if the executable exists, I presume). So using normal "properties" dialog you cannot remove quotes from around the path.
BUT when you paste the command directly to CMD.exe, in my case C:\Program Files (x86)\LuaEdit 2010\LuaEdit.ext
It LAUNCHES C:\Program.exe.
Admin
Linux allows them, however Linux distributions don't come pre-configured with key system paths that have spaces littered in them.
Admin
Admin
I wish, with all my heart, that I could forget enough of my past to find it hard to believe that an antivirus would be this stupid.
(Sadly, I can still remember the year when system-wrecking side-effects of installing or uninstalling Norton accounted for over 30% of all failures I was asked to troubleshoot. Yes, seriously.)
Admin
Im pretty sure this is about eve online and NOD32, see thread:
https://forums.eveonline.com/default.aspx?g=posts&t=80365
Admin
Admin
/ and \ are file separators, not path separators.
: and ; are path separators.
That is all.
Admin
It's that piece of krap AVG of course.
Admin
Admin
Admin
No BS. The behaviour described still works in Windows Server 2008R2 64-bit...
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\richard.breese>d:
D:>dir "a bc" Volume in drive D is Code Volume Serial Number is AC48-6518
Directory of D:\a bc
24/04/2012 11:58 <DIR> . 24/04/2012 11:58 <DIR> .. 24/04/2012 11:58 16 C.exe 1 File(s) 16 bytes 2 Dir(s) 503,563,747,328 bytes free
D:>a bc\c.exe This version of D:\A.exe is not compatible with the version of Windows you're ru nning. Check your computer's system information to see whether you need a x86 (3 2-bit) or x64 (64-bit) version of the program, and then contact the software pub lisher.
D:> D:>"a bc\c.exe" This version of D:\a bc\C.exe is not compatible with the version of Windows you' re running. Check your computer's system information to see whether you need a x 86 (32-bit) or x64 (64-bit) version of the program, and then contact the softwar e publisher.
D:>
Admin
Admin
Path delimiters stem from the kernel API, which (only) accepts paths as strings. There's no way using the POSIX API to create a file with / in the name (or NUL), because the kernel splits up paths on / and there's no way to escape it.
This goes well beyond just the shell. In fact, it's the shell that has escaping and can deal with special characters: it's the kernel that doesn't.
Admin
Admin
It's the open call and things like it that are most closely related to the NT API, not the shell. (The VMS $OPEN system call also specifies file name by string.) And for that reason, in the absence of evidence to the contrary, I still say you're probably wrong: NT's design comes from the fact that the string-taking API is nearly universal among OS kernels, not from the shell.
Admin
Admin
Are you sure MS have a "trial" phase?
Admin
The real WTF is why anyone would play Doom without music. The Doom music was awesome!
Admin
The "problem" still exists in Windows 10. I created program.exe in C:. Every call to an application in "C:\Program Files (x86)" or "C:\Program Files" without quotes from the command line (cmd.exe) starts the program.exe in C:.
Admin
Sometimes we get an error when we try to delete a File or a folder for no reason , but of course there is a reason.We have many damage file or blocked files.Do not worry if we want to remove the error files or too long path files from our system,here I suggest a smooth way.So use “Long path tool” software and keep yourself.
Admin
oh, this reminds me of an old Multi-player game i used to play, called "FLYFF". the game worked fine, except for an odd graphics glitch, but the third-party security program they used, after an update, made it impossible to play. i tried to contact the security company, several times, and they kept saying "re-install the GAME"-and got the name of the game wrong! three times i e-mailed them, and they got three different wrong names for the game! so i had to give up.
-the graphics glitch made the picture shake constantly whenever one of the fancy trees with white flowers was on the screen. after failing to find the cause, they finally replaced all the trees with simpler green ones.