So THAT's how you get a file extension





  • I didn't try it out but at least he's checking for the final dot in the pathname. The first comment is completely wrong. Obviously it should have been:

    String fn = "myFilename.extradothere.myExtension";
    String[]] fns = fn.Split('.');
    String ext = fns[fns.Length - 1];

    Seriously:

    String ext = System.IO.Path.GetExtension("myFilename.extradothere.myExtension"); 



  • Obviously, depending on your language of choice:

    return inputstring.split('.').pop();

    TRWTF of course being that extensions are considered important - they're just an indication at best.



  • @Monomelodies said:

    TRWTF of course being that extensions are considered important - they're just an indication at best.

    I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.



  • @DrJokepu said:

    @Monomelodies said:
    TRWTF of course being that extensions are considered important - they're just an indication at best.

    I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.

    They're meant to be important, sure. But since the user can change them to whatever he wants at any time, they cannot be trusted to always provide an accurate indication of what a file actually is.



  • @DrJokepu said:

    @Monomelodies said:
    TRWTF of course being that extensions are considered important - they're just an indication at best.

    I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.
     

    Yeah, and that's TRWTF...



  • @hvm said:

    Yeah, and that's TRWTF...
     

    QED 🙂 My favourite part is that they're supposed to be important, but Windows hides them by default. C'mon...



  • @Monomelodies said:

    QED
    I don't think that means what you think it means.



  • @Monomelodies said:

    QED
    Quod erat demonstrandum is used at the end of mathematical proofs as an indication that the proof is finished, usually as a placeholder so that you can skip to the end of the proof quickly and continue reading whatever paper in which the proof is contained. It means "Which was meant to be shown", though I'm sure your favourite Wikipedia has another translation of it which amounts to the same thing but you will try to use against me somehow.

    What you did was state "The real WTF is extensions are important". Then hvm said "The real WTF is extensions are important", which isn't a proof of your statement. It's simply a restating of it without any logical backing. Then you said QED, indicating that your original statement was proven, when it in fact has not been. If you think one could prove statements by restating them, then I have some rocks I want to sell you. They keep bears away: they keep bears away. QED



  • @Monomelodies said:

    QED 🙂

    Huh? Quod erat demonstrandum? That doesn't make any sense in this context
    @Monomelodies said:
    My favourite part is that they're supposed to be important, but Windows hides them by default.

    Windows displays icons, which are (partially) based on the extension. The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension. The technical decision to have extensions in CP/M was made decades ago and it might or might not be relevant today. Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.



  • @Welbog & DrJokepu

    But you see, someone agreed with him!  If two people agree on something, it must be true.  That's how we know that Windows sucks.  Also, Linux sucks, BSD sucks, AIX sucks, Solaris sucks.  Two people agree on it it must be true!



  • @TooWhiteAndNerdy said:

    That's how we know that Windows sucks.  Also, Linux sucks, BSD sucks, AIX sucks, Solaris sucks.  Two people agree on it it must be true!
    Thank God I use the only operating system that everyone can agree doesn't suck: MINIX.



  • @DrJokepu said:

    Windows displays icons, which are (partially) based on the extension. The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension. The technical decision to have extensions in CP/M was made decades ago and it might or might not be relevant today. Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.

    Exactly.  It made sense at one time and even if it is a bit cumbersome today, it's not that big of a deal.  MIME is maybe a tad better, but the UNIX "magic number" method is absolutely the stupidest thing ever.  How anyone can bitch about Windows file extensions while using Linux is beyond me.  Mac OSX probably has the best way of representing the data with the Uniform Type identifiers, which are basically like MIME types, except they are oriented around the concept of who produced the file format and not an arbitrary spec that may vary between apps.



  •  @bstorer said:

    @Monomelodies said:
    QED
    I don't think that means what you think it means.

    I am so sorry for confusing you all. No, really. My apologies. I'll try to be clearer next time, right? We all friends again now? I was of course referring to the excellent post I was quoting highlighting the "at least, they are meant to be" part, which is the QED in this whole story. Again, sorry for assuming you'd get that.



  • @DrJokepu said:

    Windows displays icons, which are (partially) based on the extension.

    Windows displays icons? Cool! I gotta try it someday...</sarcasm>

    @DrJokepu said:

    The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension.

    Yeah, and that's the part that scares me. When designing a system I surely wouldn't let anything depend on a parameter so easily edited. (And I definitely wouldn't hide it by default!)

    @DrJokepu said:

    Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.

    It makes sense in that in most cases, it'll be correct and then it's a quick and human-readable way to determine the file-type. But that's something totally different than saying it's in any way relevant - is a binary containing a program less a program if I change the extension from .exe to .fyf? I don't think so. I sure as hell wouldn't depend on it when dealing with files...



  • @morbiuswilters said:

    but the UNIX "magic number" method is absolutely the stupidest thing ever

    Correct me if I'm wrong (no, really!) but wasn't that originally some (agreedly, shitty) way of dealing with memory management? The idea of magic numbers identifying file types is wide-spread nowadays (e.g., in every standardised image format I can think of) and if nothing else is certainly not arbitrary between apps - that's why file formats are defined (a PNG made in Gimpon Linux will work in Photoshop on Windows because, like, the PNG format is standardised, and the first bytes signal that it should at least in theory be a valid PNG file).

    But maybe I misunderstood you?

    @morbiuswilters said:

    except they are oriented around the concept of who produced the file format and not an arbitrary spec that may vary between apps.

    I can see that coming in handy:

    if (file.type == 'html') {
        if (type.generator.match(/m(icro)?s(oft)?/)) {
            parse(file.contents, PARSER_QUIRKS_MODE);
        } else {
            parse(file.contents, PARSER_COMPLIANT_MODE);
        }
    }

    ... or something to that extent...

    (yes, I was being sarcastic there - it feels like a solution to a problem that shouldn't be there in the first place. But I don't know OSX well enough to determine if this is a good idea that works well in practice, a bad idea that works anyway, or simply not true.)



  • @morbiuswilters said:

    How anyone can bitch about Windows file extensions while using Linux is beyond me.

    The one thing I hate about UNIX based filesystems is case sensitivity. It really pisses me off when teSt.txt is considered different from test.txt, and both can exist in the same directory! I can tolerate case sensitivity in a programming language, but it's ridiculous when imposed on files!



  • @donniel said:

    The one thing I hate about UNIX based filesystems is case sensitivity. It really pisses me off when teSt.txt is considered different from test.txt, and both can exist in the same directory! I can tolerate case sensitivity in a programming language, but it's ridiculous when imposed on files!
    I think the opposite.  I don't think Windows should treat the two filenames as the same.  It just "feels" more right to have the filesystem be case sensitive.  However, I can't think of a real-life example of where it fucked me over on either OS. 

    What does get me sometimes is the difference between how Windows Explorer treats numbers versus UNIX's ls.

    If you have file1.txt, file2,txt, all the way to file100.txt, ls will sort them alphabetically, with 10 coming between 1 and 11.  Windows Explorer will order them by the number, basically assuming a preceding 00 or 0. 

    The "solution*" is simple.  I always zero pad numbers in file names.  That way they're ordered the same in Windows Explorer and ls.

    *solution to a problem that's probably only in my head, and I've never heard anyone else complain about.



  • @Monomelodies said:

    It makes sense in that in most cases, it'll be correct and then it's a quick and human-readable way to determine the file-type. But that's something totally different than saying it's in any way relevant - is a binary containing a program less a program if I change the extension from .exe to .fyf? I don't think so. I sure as hell wouldn't depend on it when dealing with files...

    Well if windows won't run the program if it has the extension .fyf, program.fyf is not a functional program. The extension IS important in windows. Saying it's not important is the same as saying that the executable bit in a UNIX permission is not important.



  • @Monomelodies said:

    Yeah, and that's the part that scares me. When designing a system I surely wouldn't let anything depend on a parameter so easily edited. (And I definitely wouldn't hide it by default!)

    ...

    I sure as hell wouldn't depend on it when dealing with files...

     

     

    I don't see what the security risk of filename extensions is, or why it's scary...in fact, it's an easy way to see what's going to happen when you open the file.  Sure, you can take a virus and rename it with a .gif extension or something, and no one will suspect it's a virus, but when you try to open it, it won't be run since Windows treats it as an image.  You can't run a program without knowing it, since it's easy to see the .exe on the end, even if you change the program icon to make it look like another file type.  That's why I always laugh at the viruses I get by e-mail, which say "open this amazing image!", and then have an attachment named baseball.jpg.exe or something like that.

    Now with extensions hidden of course, you can do just that and it'll be much harder to see that the supposed image you downloaded is really a program until you try to open it, but as long as you keep the extensions visible then it's fine.

    Also, for depending on the extension to deal with files, just about all programs create files with the right extension anyways, so if they don't you can assume that someone changed it for a reason (trying to open an image in Notepad, for example, by renaming with a .txt extension).

     

    @morbiuswilters said:

    the UNIX "magic number" method is absolutely the stupidest thing ever

    Not the perfect solution, of course, but it's a bit better (for accuracy) than file extensions if it's used right.  ELF programs, PNGs, JPEGs, and bitmaps all have a certain string near the beginning of the file which is part of the standard - it's not a PNG if it doesn't have the "PNG" in it - so it's a 99% foolproof way to detect these file types (the 1% is for if you have a binary file for something completely different which just happens to have the exact same sequence).  Plenty of other file types have these identifying strings (or just a few "magic" bytes) too, so it's pretty accurate.  Now if some people had decided way back that the first X bytes of every file would be the MIME type as text, then that would make things easier, but the "magic number" detection seems to me like a pretty good substitute.

    Now, a bad use for the whole "matching patterns in file contents" thing is with types of text files.  GNOME comes with a MIME type for C source files based on contents, and it's always detecting my assembly sources (which have #include on the first line) as C source files and bringing up the "this file is different than it appears" security dialog and refusing to open them by a simple double-click, which is a huge pain in the ass.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.