- 179comments
- 572comments
- 10comments
- 201comments
- 87comments
- 57comments
- 60comments
- 603comments
- 26comments
- —discuss
- 14comments
- —discuss
- 1comments
- 149comments
- 134comments
- 44comments
- 303comments
- 366comments
- 214comments
- 150comments
- 29comments
- 97comments
- 124comments
- 23comments
- 26comments
- 51comments
- 22comments
- 59comments
- 130comments
- 55comments
The tracked and actually fixed bug is: https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
I usually rely on LibreOffice, but I was tempted to get OpenOffice back on my machine just to try out the bug.
Anyway, thank you for the link.
It's interesting to follow some of abrianb's comments by date:
"When I click print I get nothing." -Tuesday, August 5, 2008
"I downloaded those updates and Open Office Still prints." -Friday, August 8, 2008
"Open Office stopped printing today." -Tuesday, August 12, 2008
"I just updated and still print." -Monday, August 18, 2008
"I stand corrected, after a boot cycle Open Office failed to print." -Tuesday, August 19, 2008
My girlfriend just stated, sitting desk to desk: "Every time I remove HN icon from bookmarks bar, it keeps reapearing". My answer, while reading this thread: "Must be a bug, file it." (of course she knows why)
To be fair, if that bug happened to me, even with 10-20 data points I don't think I would have figured out it was a Tuesday bug.
In the end the error was in the program "file", which erroneously was detecting the postscript file as an Erlang JAM file
(see https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619)
file is funny, i just did file on standard JS file
Why does file always passive aggressively note the fact that you're using 'very long lines'? I'm not sure it's relevant to the format of the file.
`file` does more than identify the file format; it also looks for properties. It can detect sizes and color properties for most image and video formats, various audio properties for audio formats etc.
"Very long lines" is sort of a property of text files. It means it's unlikely to have been written by hand for one thing.
Hmmm... I'm cynically inclined to believe it's there as a condescending remark about people the authors of file think aren't real hackers because they're not wrapping their lines to 80 characters.
I'm cynically inclined to believe it's there to identify people who can't read the source to discover the cutoff is 300 characters.
But it also has this warning for plain text files - so it's not just about source code where 300 lines is indeed quite long. However 300 characters is very short for a paragraph of text, if you aren't manually wrapping your plain text.
eh, still useful for checking if plaintext or not for those who live in the terminal
Speaking as someone who has worked a lot on mime types: Do not ever use `file` as a means to identify a file type. Use the shared-mime-info database.
http://standards.freedesktop.org/shared-mime-info-spec/share...
File has its own internal database. It can do more than the mime type db and is great for quickly identifying and getting lots of info about various file types, but it is AWFUL when used within other apps. Please, don't use it like so.
nice!
Yeah, I'm not sure about that. According to the xdg-mime(1) man page:
"The query option is for use inside a desktop session only."
Why wouldn't it work from a console session? Or even a non-login session (e.g. cron job)? I'm not sure I want to trust a command-line program that only works as part of a desktop session. It sounds like the sort of fragile doodad that makes weird assumptions about its environment, which might one day no longer be true even in that environment, to me.
Can anyone shed any further light on that crazy usage restriction?
What it actually means is that it needs the various XDG basedir variables to be set, which they sometimes aren't in a non-desktop session (this is becoming less common).
http://standards.freedesktop.org/basedir-spec/basedir-spec-l...
xdg-mime merely looks at the shared-mime-info db, processes files accordingly and spits out the result.
Also, I did not actually say you should use xdg-mime; I said you should use the shared-mime-info database. xdg-mime is a (very crappy) interface for it, but using an xdg library is a lot, lot more efficient.
Thanks for the reply.
If not xdg-mime(1) then, do you know of another file(1)-like command-line app which does use the shared-mime-info database?
For use on the command line, feel free to use xdg-mime (it does not just do mime types, it also does associations with them which means you can view and change associations between file types from it). I don't know of any other tool like it although I was working on one in python (but it's not production ready).
Crazy... wouldn't it make sense to combine both DBs?
No, the databases are very different. `file` can do some very advanced file processing, while xdg-mime has a regex-ish syntax for scanning part of the file.
More to the point though, the xdg database is extensible. While `file` requires playing with the source.
But then one could combine the good parts of both? Very advanced file processing + extensible database, sounds awesome. ;)
I mean seriously, once I wrote a simple web app in Go and the content-type for static serving was determined via file. (It's just so easy.) But nobody in the world wants to have Desktop stuff installed on her server.
The databases are not combinable, that doesn't mean they don't look at each others' improvements. File keeps an eye on new formats in s-m-i and vice versa.
That's the least one can do when working with Copy&Paste ;)
Not sure I agree with this recommendation... shared-mime-info database usually trails file(1) database by several years. Case in point: pcap-ng file format was added to file(1) in 2011; was added to mime-info database in 2013.
Also, file --mime FILENAME gets you the mime type.
The file database is not extensible. This means it will not recognize file formats specific to your setup, etc. With the shared-mime-info database, you can have user-wide and system-wide extensions to the database, so installed programs can (and do) install their own mime types. If you need to deal with, for example, a custom image or archive format you can also set that up.
Additionally, the shared-mime-info database is much better curated than the file mime database; file has a lot of wrong mime types (I have gotten a dozen or so fixed so far). If there are file types that are missing from shared-mime-info, please report them on https://bugs.freedesktop.org/ (there are guidelines for good mime type reports, follow those and you can get a fix merged in very fast).
This reminds me of the case of the 500-mile email: http://www.ibiblio.org/harris/500milemail.html
This is great :-)
Also the printer that would jam when printing one file: http://nedbatchelder.com/blog/200811/print_this_file_your_pr...
That one is amazing.
Just because a bug seems impossible doesn't mean it is.
This comment reminds me of the magic switch (story [0], light HN discussion [1]).
[0]: http://catb.org/jargon/html/magic-story.html [1]: https://news.ycombinator.com/item?id=181045
This one's great! Thanks for sharing. Makes you wish there was a real cause though instead of speculation.
Reminds me of the photocopier that altered numbers in documents: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...
Whoa that's pretty crazy. It seems the pattern is a 6 being mistaken for an 8 but surprised Xerox didn't release the upgrade when they discovered the issue. Why wait for someone else to call you out on it?
I used to have a very simple HTML email that would cause Outlook 97 to corrupt its PST and need manual rebuilding.
This reminds me to a a bug in pdftk that appeared only between April and December when Austria's localization is used: https://bugs.launchpad.net/ubuntu/+source/pdftk/+bug/779908/...
This made me smile! :)
Tuesday is no print day. Save paper ;-)