dflemstr
It's a ball.
Sphinxter said:
Last edited by a moderator:
MIME types
- Thread starter dflemstr
- Start date
lulzfish
Pandora Defense Squad
Yeah but if we standardize on an extension, that would make it easier for... stuff... to happen. ?
I usually just don't have extensions for executables, I think that's how most Linux stuff goes.
I usually just don't have extensions for executables, I think that's how most Linux stuff goes.
Last edited by a moderator:
Butterman
Gief Pandara
I agree that we should standardize an extension.'lulzfish' said:
Nice work StreaK, this could come in handy for devs who don't like getting their hands dirty.
Last edited by a moderator:
skeezix
Internal Development
There is no need to introduce an extensin, at all... and it is also very much against the norm on Unix/Linux.
A .pnd file uses the extension to identify it as a pandora bundled app; remember thyat these guys live on _SD cards_.
An unbundled app (a directory with a PXML.xml) also does not need an extension, as everything about it is defined by the PXML.xml (ie: which contains the reference of what app(s) are in the directory, what to run, etc.)
Lastly, one can run any old executable, just as in Unix/Linux and as will be in the Angstrom packages etc, on the filesystem. Those are of course flagged with the executable bits as any other Unix filesystem file.
There is no need to identify an extension for apps just lieing around on SD card; they'll have PXML.xml files, which are trivial to make (and could be like 5 lines long, mostly empty, if they want to be.)
There is no need to overcomplicate things
jeff
A .pnd file uses the extension to identify it as a pandora bundled app; remember thyat these guys live on _SD cards_.
An unbundled app (a directory with a PXML.xml) also does not need an extension, as everything about it is defined by the PXML.xml (ie: which contains the reference of what app(s) are in the directory, what to run, etc.)
Lastly, one can run any old executable, just as in Unix/Linux and as will be in the Angstrom packages etc, on the filesystem. Those are of course flagged with the executable bits as any other Unix filesystem file.
There is no need to identify an extension for apps just lieing around on SD card; they'll have PXML.xml files, which are trivial to make (and could be like 5 lines long, mostly empty, if they want to be.)
There is no need to overcomplicate things
jeff
Last edited by a moderator:
lulzfish
Pandora Defense Squad
Then it's agreed.
The extension for Pandora executables shall be: .
The extension for Pandora executables shall be: .
Last edited by a moderator:
Sphinxter
Says What?
'dflemstr' said:
Last edited by a moderator:
dflemstr
It's a ball.
Sphinxter said:
Last edited by a moderator:
skeezix
Internal Development
You keep saying Unix/Linux apps use MIME types. It boggles my mind a little, but maybe you're just trying to simplify for someone since you seem to know what you're talking about otherwise
The file entry has a bitmask set; one of the bits is executable for any givne role, and thats it. If its flagged as executable for your permission role, you can run it. You can flag a textfile as executable and attempt to run it (which won't work of course).. theres no MIME type attached to an inode. Its not like traditional Mac OS where you've actually for a file type metadata entry that is then mapped to a handler or anything..
By definition, MIME was created for email, and later extended for browsers and other trans media.. but executables long predated that
jeff
The file entry has a bitmask set; one of the bits is executable for any givne role, and thats it. If its flagged as executable for your permission role, you can run it. You can flag a textfile as executable and attempt to run it (which won't work of course).. theres no MIME type attached to an inode. Its not like traditional Mac OS where you've actually for a file type metadata entry that is then mapped to a handler or anything..
By definition, MIME was created for email, and later extended for browsers and other trans media.. but executables long predated that
jeff
Last edited by a moderator:
skeezix
Internal Development
Dflem used MIME types too.
Consider a desktop file manager tool, just looking at directory; it'll first go by the hidden 'flag' (leading period say), and then check executable and setuid and other bits since those are easy and solid, and then start applying local rules. (A good questio offhand is if you get a .pnd and chmod +x it, will it be shown as an executable or an image; I imagine it depends on which app and wihch order they check things
I imagine most apps will then go to extensions, since Windows/DOS has cursed us with the concept. (A better examnple than Linux perhaps is OSX, which is essentially based on FreeBSD, but when they built the OSX engine on top of it they pissed all over things by deciding to use file extensins instead of the actually better metadta option from OS9 and earlier.)
Anyway, a .png file has no MIME data anywhere, just a file extension; the app will then look up the file extension against a database, be it MIME or otherwise, and figure out what to do.
MIME headers come in email uuencode type info, and in web browsers with the Content-type headers and so on, but when just looking at fils in a filesystem, I shoudl think few file browsers are using MIME at all.
So just seems an odd thing to bring out.
The situation as is sucks, for sure, though Gotta love Microsofts approach .. just hide the file extension, to sort of imply that its metadata, like dates and such.
jeff
Consider a desktop file manager tool, just looking at directory; it'll first go by the hidden 'flag' (leading period say), and then check executable and setuid and other bits since those are easy and solid, and then start applying local rules. (A good questio offhand is if you get a .pnd and chmod +x it, will it be shown as an executable or an image; I imagine it depends on which app and wihch order they check things
I imagine most apps will then go to extensions, since Windows/DOS has cursed us with the concept. (A better examnple than Linux perhaps is OSX, which is essentially based on FreeBSD, but when they built the OSX engine on top of it they pissed all over things by deciding to use file extensins instead of the actually better metadta option from OS9 and earlier.)
Anyway, a .png file has no MIME data anywhere, just a file extension; the app will then look up the file extension against a database, be it MIME or otherwise, and figure out what to do.
MIME headers come in email uuencode type info, and in web browsers with the Content-type headers and so on, but when just looking at fils in a filesystem, I shoudl think few file browsers are using MIME at all.
So just seems an odd thing to bring out.
The situation as is sucks, for sure, though
Gotta love Microsofts approach .. just hide the file extension, to sort of imply that its metadata, like dates and such. jeff
Last edited by a moderator:
Squidge
Certified Guru
'dflemstr' said:
Last edited by a moderator:
skeezix
Internal Development
Ah squidge, you were just being mean
Naturally it should be "./myapp" so that someone doesn't do a PATH attack on you
(go back 10 years or so ago and people were forevering making malicious scripts named 'ls', in hopes that they would accidentally get run by people, since no one ever types /usr/bin/ls ...)
jeff
Naturally it should be "./myapp" so that someone doesn't do a PATH attack on you
(go back 10 years or so ago and people were forevering making malicious scripts named 'ls', in hopes that they would accidentally get run by people, since no one ever types /usr/bin/ls ...)
jeff
Last edited by a moderator:
dflemstr
It's a ball.
I am also very aware of the fact that "." normally isn't in PATH. I was referring to being in another folder and having the executable folder in the PATH
OK, now when that is cleared: MIME types and that stuff isn't really my area of expertise; however here's how I understand it:
There are many types of files in Linux (Files, Executables, INodes/Directories, Devices, FIFOs etc.)
Executables have the x-bit set.
Directories use the x-bit to indicate that they are browsable.
That's what the x-bit does.
What I'm talking about are files in general (like a .pnd-file, which is NOT an executable etc.), and how they get recognized. We all know that this isn't through extensions, you can't fool Linux that easily.
So, how for example a jpeg-image gets recognized is by letting a library examine it (forgot it's name), and that library will then spit out a mime type for that file by using an internal recognition algorithm; in this case "image/jpeg". Then, the file manager or whatever has actions or previews or stuff like that saved for that mime type, and thus recognizes it as a jpeg-image.
Now let me hear, which part of this is wrong, according to you?
EDIT:
Proof (kinda). This is how KDE saves file associations:
HiRes:
CODE
http://img9.imageshack.us/my.php?image=snapshot4.png
Look to the left; that's the system I call MIME-type system.
The file patterns are only secondary recognition methods.
And hey, in any Linux distro, try removing the .jpg-extension from the file. It still gets recognized. Voilà.
OK, now when that is cleared: MIME types and that stuff isn't really my area of expertise; however here's how I understand it:
There are many types of files in Linux (Files, Executables, INodes/Directories, Devices, FIFOs etc.)
Executables have the x-bit set.
Directories use the x-bit to indicate that they are browsable.
That's what the x-bit does.
What I'm talking about are files in general (like a .pnd-file, which is NOT an executable etc.), and how they get recognized. We all know that this isn't through extensions, you can't fool Linux that easily.
So, how for example a jpeg-image gets recognized is by letting a library examine it (forgot it's name), and that library will then spit out a mime type for that file by using an internal recognition algorithm; in this case "image/jpeg". Then, the file manager or whatever has actions or previews or stuff like that saved for that mime type, and thus recognizes it as a jpeg-image.
Now let me hear, which part of this is wrong, according to you?
EDIT:
Proof (kinda). This is how KDE saves file associations:
HiRes:
CODE
http://img9.imageshack.us/my.php?image=snapshot4.png
Look to the left; that's the system I call MIME-type system.
The file patterns are only secondary recognition methods.
And hey, in any Linux distro, try removing the .jpg-extension from the file. It still gets recognized. Voilà.
Last edited by a moderator:
Squidge
Certified Guru
Ah right. The reason I didn't get it before is that the only reason I normally have X running is because the text console width isn't big enough, so I start X-Windows and open a xterm the size of the screen
I've never used KDE, or any X-Windows based file managers. If I want to view a file, I know it's a picture from the filename and extension, and type the command in to do it, that app then analyses the file, notices it's a JPEG from the header (typically not caring about the extension, as if it can't parse the file, the extension is useless also) and shows me the picture. I do the same with mp3s, wavs, wma's, etc.
How you were talking earlier, I though it was something built into a newer Linux file system - ie, when a file was created, it stated what type it was embedded in the file info structure.
Sure, we don't need the extensions for Pandora executables, but I think it would be easier that way to differentiate them from data files when viewing the file system remotely (eg, over nfs, samba, usb mass storage) when you don't have access to the permissions mask, and you don't want to open every file to tell what it is. If I was using linux and nfs, I wouldn't want to drag down every file of a 500 file directory just to know what type they were. This is where file extensions excel - as soon as you have the directory contents, you also know what is inside them. Considering the speed of nand compared to a typical desktop harddisk, I don't think it makes much sense to expect them to work the same way.
I've never used KDE, or any X-Windows based file managers. If I want to view a file, I know it's a picture from the filename and extension, and type the command in to do it, that app then analyses the file, notices it's a JPEG from the header (typically not caring about the extension, as if it can't parse the file, the extension is useless also) and shows me the picture. I do the same with mp3s, wavs, wma's, etc.
How you were talking earlier, I though it was something built into a newer Linux file system - ie, when a file was created, it stated what type it was embedded in the file info structure.
Sure, we don't need the extensions for Pandora executables, but I think it would be easier that way to differentiate them from data files when viewing the file system remotely (eg, over nfs, samba, usb mass storage) when you don't have access to the permissions mask, and you don't want to open every file to tell what it is. If I was using linux and nfs, I wouldn't want to drag down every file of a 500 file directory just to know what type they were. This is where file extensions excel - as soon as you have the directory contents, you also know what is inside them. Considering the speed of nand compared to a typical desktop harddisk, I don't think it makes much sense to expect them to work the same way.
Last edited by a moderator:
dflemstr
It's a ball.
Well, "ls --color" shows executables as green, and with a "*" at the end. That's all I need
And I use "find -perm +x -print0 | xargs -0 <whatever>" for executables usually, when I have more than 500 of them
But i see your point; only problem remaining is when there's a 'black sheep' executable that doesn't have the extension, therby being missed by those who have gotten used to the extension being there.
Ah, and I almost forgot: If you learn the ls color scheme, you're good to go (but noone wants to do that, right?).
"ls" also uses MIME types.
And, "file -i" gives you the MIME type of a file, for bash scripts etc. Just BTW.
And I use "find -perm +x -print0 | xargs -0 <whatever>" for executables usually, when I have more than 500 of them
But i see your point; only problem remaining is when there's a 'black sheep' executable that doesn't have the extension, therby being missed by those who have gotten used to the extension being there.
Ah, and I almost forgot: If you learn the ls color scheme, you're good to go (but noone wants to do that, right?).
"ls" also uses MIME types.
And, "file -i" gives you the MIME type of a file, for bash scripts etc. Just BTW.
Last edited by a moderator:
Squidge
Certified Guru
'dflemstr' said:Well, "ls --color" shows executables as green, and with a "*" at the end. That's all I need
Try doing that when the Pandora is connected to a Windows or Mac machine, where the 'x' permission is typically "lost in translation" due to the fact that the host os does not support such an attribute. You have no idea what is executable and what isn't without opening each file to find out.
Last edited by a moderator:
dflemstr
It's a ball.
Right, but why would you store raw linux executables on a Mac or Windows machine? PNDs, yes, but ELF-binaries?
Anyways, you wouldn't be able to do anything with those files anyways without +x (for example: execute them) besides copying them, of course. And I usually, when I put binaries somewhere, don't mix them with other files, so even copying them wouldn't be a problem. That's just me.
You could still go with "case file -i $file in; "mimetype") echo $file;" or something if your files indeed were mixed.
However, if you somehow find the need to store those files on a windows machine, then sure, make an extension for them. We should however, imho, follow the linux (or rather GNU) convention and go by MIME types primarily, since the Pandora uses a linux-based OS.
By the way, cool that you barely use X at all; I'd like to try that sometime. Accessing the WWW could prove difficult for me, however, since "links" or "lynx" both are insufficient for my needs.
Ah, and as mentioned, if you want to make any kind of file manager or something that uses file associations (hint, hint), look at libmagic (now I remembered, and someone mentioned it before). It's that which is used to recognize file types.
Anyways, this discussion has gone on for too long I think, time to get back to the topic?
Anyways, you wouldn't be able to do anything with those files anyways without +x (for example: execute them) besides copying them, of course. And I usually, when I put binaries somewhere, don't mix them with other files, so even copying them wouldn't be a problem. That's just me.
You could still go with "case file -i $file in; "mimetype") echo $file;" or something if your files indeed were mixed.
However, if you somehow find the need to store those files on a windows machine, then sure, make an extension for them. We should however, imho, follow the linux (or rather GNU) convention and go by MIME types primarily, since the Pandora uses a linux-based OS.
By the way, cool that you barely use X at all; I'd like to try that sometime. Accessing the WWW could prove difficult for me, however, since "links" or "lynx" both are insufficient for my needs.
Ah, and as mentioned, if you want to make any kind of file manager or something that uses file associations (hint, hint
), look at libmagic (now I remembered, and someone mentioned it before). It's that which is used to recognize file types.Anyways, this discussion has gone on for too long I think, time to get back to the topic?
Last edited by a moderator:
'dflemstr' said:By the way, cool that you barely use X at all; I'd like to try that sometime. Accessing the WWW could prove difficult for me, however, since "links" or "lynx" both are insufficient for my needs.
Try elinks
Last edited by a moderator:
skeezix
Internal Development
The "MIME type" is nothing to do with MIME per se; you're just talking about _file extension_ to _type_ mapping, and thats done differently in every system. (Though you are right, some systems like KDE do in fact use somethign like MIME types, since.. they bloody well should So anyway, it is not really any form of standard, but we're all glad they're doing something.
(I doubt they use libpmagic live; magic is not really slow, but its never been really fast either; most, including KDE, just go by filename IIRC. But I coudl be wrong, as these things change.. they mght have made a backfiller, that goes by name and for unknown types then goes in backgrond to magic the files and see. But we digress even too much for us
If someone wants to make a naming convention for ELF bins as an option, I suppose they could; it doesn't hurt not harm, its just there. the PXML.xml doesn't care.. its 'Exec' like is to be trusted, regardless what file it points to. If someone wants to have a FAT filesystem on SD with a foo.pnx or whatever, it doesn't hurt.
I think in practice, most people will use .pnd files, and a few the unpacked directory kind. During development, devs wil use unpacked kind to avoid an extra make-step .. just have the make file drop out a file "foo" with a 5 line PXML.xml empty file that just says 'exec is foo', and good to go. So a file extension doesn't really help here.
So I don't care either way, but strikes me as we don't need it; gpe/gpu was only needed since there was _no_ packaging type for those machines.
jeff
So anyway, it is not really any form of standard, but we're all glad they're doing something.(I doubt they use libpmagic live; magic is not really slow, but its never been really fast either; most, including KDE, just go by filename IIRC. But I coudl be wrong, as these things change.. they mght have made a backfiller, that goes by name and for unknown types then goes in backgrond to magic the files and see. But we digress even too much for us
If someone wants to make a naming convention for ELF bins as an option, I suppose they could; it doesn't hurt not harm, its just there. the PXML.xml doesn't care.. its 'Exec' like is to be trusted, regardless what file it points to. If someone wants to have a FAT filesystem on SD with a foo.pnx or whatever, it doesn't hurt.
I think in practice, most people will use .pnd files, and a few the unpacked directory kind. During development, devs wil use unpacked kind to avoid an extra make-step .. just have the make file drop out a file "foo" with a 5 line PXML.xml empty file that just says 'exec is foo', and good to go. So a file extension doesn't really help here.
So I don't care either way, but strikes me as we don't need it; gpe/gpu was only needed since there was _no_ packaging type for those machines.
jeff
Last edited by a moderator:
