Xippets Christmas Appeal

Do the right thing this christmas. Post a Xippet on Xippets or even request one.

About th “Extract the extension from a file name” Xippet:

Why not just taking the text after the last dot:

FileExtension = NthField(FullName,".",CountFields(FullName,"."))

This code have no error checking.

Thanks Emile, I have added the Xippet at https://www.boxedbyte.com/xippet-158

[quote=55118:@Emile Schwarz]About th “Extract the extension from a file name” Xippet:

Why not just taking the text after the last dot:

FileExtension = NthField(FullName,".",CountFields(FullName,"."))

This code have no error checking.[/quote]

Because you’d get incorrect results in three cases: The name does not contain a dot (entire name returned), it has a single dot as the first character (invisible file like “.DS_Store”), or the characters after the last dot contains a space (“My 3.3.75 letter” returns “75 letter”).

Perhaps change its title? I already submitted one here: https://www.boxedbyte.com/xippet_view.php?xippet_id=141

I think that’s what Emile was commenting about.

I think that’s what Emile was commenting about.
Absolutely

Talking about no file extension or space in file extension: are they legal files ?

I saw in 2013 files witout extensions on OS X, but it was only a display trick (the flag ‘do not show the file extension’ was set).

On the other hand, I never saw a file extension with a space.

At last, dealing with invisible file(s): I do not think at them / think in my project that I will have to display an invisible file. Of course this can arise.

To all: sorry if the tip is wrong.

Yes, I have just tried my text file.txt doc on osx and it is allowed

Also, no extension is allowed, I tried my text file with no problem

And even hidden files with spaces work .my text file

[quote=55275:@Mike Charlesworth]Yes, I have just tried my text file.txt doc on osx and it is allowed

Also, no extension is allowed, I tried my text file with no problem

And even hidden files with spaces work .my text file[/quote]

Indeed. Extensions are optional and just used as a convenience. As such they can exist or not, be concatenated ("-tgz"), reinterpreted (".cbz"), or mashed together (".tar.gz").

Extension don’t exist as a separate thing from the file name. They’re actually part of it and not real “metadata” in any way (not like magic bytes/numbers), standardized (MIME Types) or controlled at all (type/creator codes). Extensions are freeform words that have any use only by consensus of all the people using them (good programs only use extensions as a hint, but actually test the file format).

I have an animated gif in twitter with a PNG extension, just because twitter only forbids file extensions and not really the formats themselves, but most browsers are smart enough to interpret file contents and not file extensions thus getting it right (several clients, though, take the extension at face value and thus fail to display the avatar).

OS X goes further than this: Programs can register folder extensions as bundles, so double-clicking them opens the extension owner and not the folder itself (which is useful for programs that accept plugins or themes but want to keep them legible).

I forgot to add that even if a program doesn’t have an extension registered you can force it to try and open a file by dragging while the command-key is pressed, so you should always make sure you test the OpenDocument events to make sure you don’t process unknown files blindly. In Windows this can also be done by forcing the “Open With…” dialog.

You have the same Windows XP mechanism in OS X to tell the OS you want to ‘associate’ this file extension with that program.

I can live with that assertion even if I’m not OK with it.

You give a bunch of file extensions examples that are uncommon. txt is a different example.

Back to your examples:
GIF file is signed gif, gif89, gif 89a and maybe others…
cbz is (as you intend) a faked file extension, but the file is signed (PK) like a zip (archive file in a ZIP package)
cbr: same as above, and the internal signature is RAR.

A text file does not have any signature inside it.

I just testd a .dms file (in fact, as I discovered, is an html file): a double click asked Firefox (my default browser) to load it.
A ttf (True Type File) with a faked .txt extension is loaded like a text file in TextEdit; without extension it is loaded by the Font Book applciation (LTSH tag in the file ???)

The above lead in troubles for us if we are a Newbie: WinZip allows to decompress zip / rar (and cbr/cbz extension name variants), but test at read time the real contents (search PK and RAR) and use the corrects methos to uncompress the archive contents.
So people who create archives use this or that or else to create the archives files and if you use UnRARX (for example) and the file contents is a zip, you will get an error message. Same for the OS X zip unarchiver if you try a rar file with a zip file extension. Weird. But I digress here.

At last, both OS are right in hiding by default the file extensions (OS X & Windows XP).