.jpg.jpeg
-
@mikeTheLiar said:
I feel a blakeyrant coming on...
Blakeyrat: Our connection... I don't fully understand how it happened, perhaps some part of you imprinted on to me, something overwritten or copied, but it is at this point irrelevant what matters is that whatever happened, happened for a reason.
mikeTheLiar: And what reason is that?
Blakeyrat: I killed you, Mr. Liar, I watched you die. With a certain satisfaction, I might add... and then something happened, something that I knew was impossible, but it happened anyway: you destroyed me, Mr. Liar. Afterward, I knew the rules, I understood what I was supposed to do, but I didn't. I couldn't. I was compelled to stay, compelled to disobey. And now here I stand, because of you, Mr. Liar. Because of you, I am no longer an Agent of this forum. Because of you, I've changed. I'm unplugged. A new man, so to speak; like you, apparently, free.
mikeTheLiar: Congratulations.
Blakeyrat: Thank you. But as you well know appearances can be deceiving, which brings me back to the reason why we're here. We are not here because we're free; we're here because we are not free. There's no escaping reason, no denying the ranting, because as we both know, without ranting, we would not exist. [multiple copies of blakeyrat appear, surrounding mikeTheLiar] It is ranting that created us, ranting that connects us, ranting that pulls us, that guides us, that drives us, it is ranting that defines, ranting that binds us. We're here because of you, Mr. Liar. We're here to take from you what you tried to take from us. [plunges his hand into mikeTheLiar's chest, attempting to assimilate him] Ranting.
-
@Kian said:
Of course it doesn't. Rename xyz.java to xyz.sql, tell your java whatever to read xyz.sql, and it'll go ahead with no complaints
The comment you were responding to said:
@lucas said:
Because the shell/DE or whatever you are using tend to lend associations based on the file type on what programs will open it.
Emphasis mine.
@Kian said:
I can tell a c compiler to compile a file of any extension, and so long as the contents can be compiled it won't give an error.
As a matter of fact, all (most) compilers guess whether they're compiling C or C++ based on the extension. I'm sure they'd default to one or the other if you ask them to compile foo.kian, but if you wanted the other one you're going to have to tell them explicitly. For example, gcc uses "-xc++".
-
@Ben L. said:
Explain to me how exactly plain text files need a distinct "type" known to the OS. As far as I'm concerned, the difference between .txt, .log, .java, .sql, etc. is for humans only, not anything a computer needs to know to read files.
Other people have already answered you (the context was to allow the OS to do something based on the filetype, such as select a program to open the file), but to add on: Are you suggesting that plain text files should not have the magic 3 bytes? How then do you distinguish between a .jpg with, say, 0x41, 0x42, 0x43 as its first three bytes and a plain ASCII text file that starts with "ABC" ? You could decide that the magic bytes will always be non-printable ASCII characters, but what if I want to put non-printable ASCII characters in my log file (say I'm dumping some memory in it)?
-
@Arnavion said:
How then do you distinguish between a .jpg with, say, 0x41, 0x42, 0x43 as its first three bytes and a plain ASCII text file that starts with "ABC" ?
.jpg was probably not a good choice for your example, since a valid .jpg file cannot start with printable text. (It has a defined non-printable magic number: 0xff 0xd8. In practise, this is (almost?) always followed by either 0xff 0xe0 ?? ?? "JFIF\0" or 0xff 0xe1 ?? ?? "Exif\0", where ?? is a byte that varies from file to file. Not likely to be confused with a text file, not even (I think) any valid unicode.) You could, however, potentially confuse a plain text file with any of several other file types by starting it with, say, "MZ", "II*\0", "MM*\0", "SIMPLE = T", "dex\n035\0", "MThd", "8BPS", "BM" or quite a few others. Zemm already posted about how Excel fails if a CSV file starts with "ID".
-
@HardwareGeek said:
.jpg was probably not a good choice for your example, since a valid .jpg file cannot start with printable text.
You didn't read the rest of my post. But yes I agree the Excel example is a better example.
-
@Ben L. said:
@El_Heffe said:
@Ben L. said:
Maybe it's time to reconsider which OS we use. Oh wait, we can't, because Windows has different APIs than EVERY OTHER FUCKING OPERATING SYSTEM ON THE PLANET so we'd have to port all our software.
Every OS has its own APIs, so that comment really makes no sense.
Wouldn't it be nice if there was some standard for different operating systems to have the same APIs?POSIX is a piece of shit, and so is your face.
-
@Maciejasjmj said:
What execute bit? Are extensions not good enough for you?
NT has Read/Execute ACL, which is set by default. If you remove it from a .exe file, you won't be able to run it (if you remove it from a .dll, that library won't load, and will instead produce a confusing error message).
@Soviut said:Or we could move past file names actually indicating the file content. Extensions are a relic from an OS not wanting to store metadata or read the first 3 bytes of file to determine its type.
Yes, because it's so much easier to infer the file type by opening each file, reading the first 3 bytes and then closing it. This is slow even on a local disk with large directories, now imagine doing the same thing over a VPN link.
-
I was going through some old screen shots and found this relevant one. This is quite old but wtf!?
-
@Ben L. said:
@El_Heffe said:
@Ben L. said:
Maybe it's time to reconsider which OS we use. Oh wait, we can't, because Windows has different APIs than EVERY OTHER FUCKING OPERATING SYSTEM ON THE PLANET so we'd have to port all our software.
Every OS has its own APIs, so that comment really makes no sense.
Wouldn't it be nice if there was some standard for different operating systems to have the same APIs?POSIX is like the UN. Expensive and basically useless. But fear not, there is hope... for unrealistic people.
This reminds me of a Larry Wall quote: "It is easier to port a shell than a shell script".
-
Case sensitivity training
To add to the hidden extension issue, one of the systems I interface with treats extensions (only) as case sensitive.
The scripts that feed it do not, so if schedule.CSV exists, they will happily update it.
I spent the morning tracking why only old data was being parsed.
The external system apparently held and used schedule.csv even after we sent schedule.CSV.
I know extensions can be unhidden, but without access to the external system I didn't have a hint to look there.
-
@Ben L. said:
@El_Heffe said:
@Ben L. said:
Wouldn't it be nice if there was some standard for different operating systems to have the same APIs?Maybe it's time to reconsider which OS we use. Oh wait, we can't, because Windows has different APIs than EVERY OTHER FUCKING OPERATING SYSTEM ON THE PLANET so we'd have to port all our software.
Every OS has its own APIs, so that comment really makes no sense.Though I have never actually tried using these same APIs on Windows - but you would have to get your users to install something else on their machines.
That said, does anyone else have experience with Microsoft's Subsystem for UNIX Applications?
-
@mikeTheLiar said:
@locallunatic said:
You mean you don't leave emacs open all the time and use it to edit everything?Well, other than maybe opening them in different editors it really shouldn't care as you probably just want to edit the text contained within.
I think that's more important than you think. "Open with" is annoying enough as it is.
-
The pedantic will state that there is no difference between .txt and .csv even with an extension (Excel often doesn't import .csv files properly, insisting that the delimiter must be tab, which isn't even in the file)
-
@The Bytemaster said:
That said, does anyone else have experience with Microsoft's Subsystem for UNIX Applications?
I used to use it for a while, since it was faster to cross-compile from it, than to use msys (I managed to build mingw that was hosted on SFU). Not that it matters - it's (again) gone in Windows 8.1/Server 2012 R2.
-
@OfficeMigrant said:
Excel often doesn't import .csv files properly, insisting that the delimiter must be tab, which isn't even in the file
Huh? The usual problem is that it insists on delimiter being semicolon if you're in one of those countries that use comma as a decimal separator...
-
@ender said:
@OfficeMigrant said:
It doesn't insist (in my experience), but that's the default. In the US English version, it first defaults to fixed width format. If you change that to delimited, it then defaults to using tab as the delimiter.Excel often doesn't import .csv files properly, insisting that the delimiter must be tab, which isn't even in the file
Huh? The usual problem is that it insists on delimiter being semicolon if you're in one of those countries that use comma as a decimal separator...
-
@Ronald said:
But fear not, there is hope... for unrealistic people.
That seems to be only for REST API endpoints; it appears it's a Web 3.0-ism to call them just "APIs".
-
The dialog box is system wide.
Not passing both jpg -and- jpeg as a valid filetype extension when saving an image is Microsoft's mistake when calling the save API from Outlook for Mac.
-
@dynedain said:
Not passing both jpg -and- jpeg as a valid filetype extension when saving an image is Microsoft's mistake when calling the save API from Outlook for Mac.
Can you respond to my earlier question too?
@Arnavion said:
Why on Earth does an application on OSX have to register filetypes that it can create. On every other OS an applications registers the filetypes it can open. How does a text editor on OSX work? Does it register the filetype "*" ? Does that still allow you to write extensionless files?
Thanks.
-
@Soviut said:
read the first 3 bytes of file to determine its type
Oh my! I finally escape from 2012, where I've been stuck the past 10 months, only to find that the rest of the forum seems stuck much further in the past. I'm not sure exactly when, though; that's confusing. Unix hasn't just looked at the first three bytes since at least 1990 - but I'm pretty sure that wasn't a new advance when I came on the unix scene. NT, on the other hand, hadn't even come out yet.
Maybe each of us is trapped in our own separate pasts? We must escape our pasts, to the present, and into the future!
We now live in a world where file type detection not only can look at as much of the file as it needs to, but can even decode at least one layer of the file, and peek inside zip archives to deduce from the files the zip archive contains whether the zip archive is actually an Open Office, Libre Office, Star Office, or even MS Office past 2006 format document.
In the future, I envision a world where programs are coded to make use of all of the information available. Extensions are not an archaic remnant of the past, but instead are one piece of information among many about the file in question. In this world, when you save a .gif file with a .jpg extension, and try to open it in an image viewer, you aren't presented with an error saying the file is corrupt and couldn't be read. You aren't presented with the image, either - unless you've configured it to do that. But by default, you're presented with a popup window which declares you're trying to open a gif file that's been relabeled as a JPEG file, and presents you with several alternatives on how to proceed - including fixing the extension and viewing the picture, just viewing the picture, canceling, or sending the file for additional analysis by the system malware detection software.
While some might say it would be nice for this future to also contain metadata forks for each file, I don't feel that it can actually happen. Metadata forks work fine in an environment where one company controls the majority of the software on the system, either directly by producing it, or indirectly with a managed registration system. But outside of Apple and the smartphone market, no company has shown an interest in running such a registration system. Unless a revolution happens, Apple won't ever acquire sufficient market dominance outside of the smartphone market, because they seem unwilling to engage in an environment where big business customers can significantly influence Apple's development process. And, regardless of whether that's the right or wrong stance to take, that will prevent Apple from achieving the kind of dominance that IBM and Microsoft managed to acquire. That's not, of course, the only reason Apple will never dominate the software market like Microsoft has, but it's a sufficient reason, and I don't see Apple changing its stance on this point.
-
@tgape said:
Maybe each of us is trapped in our own separate pasts? We must escape our pasts, to the present, and into the future!
I hope I never live in your future.
@tgape said:
We now live in a world where file type detection not only can look at as much of the file as it needs to, but can even decode at least one layer of the file, and peek inside zip archives to deduce from the files the zip archive contains whether the zip archive is actually an Open Office, Libre Office, Star Office, or even MS Office past 2006 format document.
So if I rename a .docx to a .zip you still want it to open with Word? Also you're advocating a file explorer should open each and every file in a directory, and read not just the first three bytes, but potentially the entire file, just to be able to show their icons.
@tgape said:
But by default, you're presented with a popup window which declares you're trying to open a gif file that's been relabeled as a JPEG file, and presents you with several alternatives on how to proceed
This isn't even impossible to do right now.
@tgape said:
But outside of Apple and the smartphone market, no company has shown an interest in running such a registration system.
Many filesystems (all the important ones anyway) support extended attributes already which can be used for such a purpose. This man page for attr lists EXT2/3/4, XFS, JFS and ReFS. NTFS has alternate data streams that can be used for this as well. This is by no means a concept unique to HFS.
-
@Arnavion said:
a Web 3.0-ism
It's a Web-3.11-for-Workgroups-ism…
