Compelling reason not to have : in filenames?
I was wondering, cuz I sometimes feel the acute need to use one of these in a filename. If I think how short filenames could only be in OS 9, I realize I could NEVER go back, but this one, often used, character should be added to make things complete. They can keep their filenames starting with a dot.
So, anybody here can explain this to me?
So, anybody here can explain this to me?
Comments
if you were to send a fine with ":" in the filename to an OS 9 user, they woulsn't have much fun with it.
the .filename signifies a hidden file, well hidden from the ls command but not curiously from the ls -al subset. Again a bsd unix standard from way back.
; & ( ) | < >
and : isn't included. i've done a few tests on varying flavours of unix and it doesn't seem to care about a : in the filename. Although the compatability consequences mentioned above would put me off.
Characters such as the slashes '/' '\\' and ampersand '&' and brackets '<' '>' and such are all valid on HFS+.
I'm assuming OS X is doing some translation stuff on the fly.
Neat. if a little unnerving for somebody from a unix background.
Originally posted by gardnerj
How the hell does it manage this ?... i've just created a directory "<>" using finder and you can use it as usual. But if you try doing that in terminal it fails because < and > have reserved system meanings. Unless you prefix the with \\ eg mkdir \\<\\>
I'm assuming OS X is doing some translation stuff on the fly.
Neat. if a little unnerving for somebody from a unix background.
These translations are probably of the same nature as the '%20' value for a simple space you see as path whenever you open a file with a space in its path.
Originally posted by gardnerj
How the hell does it manage this ?... i've just created a directory "<>" using finder and you can use it as usual. But if you try doing that in terminal it fails because < and > have reserved system meanings. Unless you prefix the with \\ eg mkdir \\<\\>
Yes. The characters are escaped. Alternatively, you can put paths in quotes, double or single.
Ex.:
cd /Volumes/ITUNES/Unknown\\ Artist/Unknown\\ Album/04\\ Track\\ 4.mp3
cd "/Volumes/ITUNES/Unknown Artist/Unknown Album/04 Track 4.mp3"
Interestingly enough, the Terminal automagically recognizes quotes and leaves the escape characters out.
Originally posted by gardnerj
How the hell does it manage this ?... i've just created a directory "<>" using finder and you can use it as usual. But if you try doing that in terminal it fails because < and > have reserved system meanings. Unless you prefix the with \\ eg mkdir \\<\\>
I'm assuming OS X is doing some translation stuff on the fly.
Neat. if a little unnerving for somebody from a unix background.
The need for backslashes is because the < and > characters are reserved by the shell, not the system. Finder presumably communicates directly with the (virtual) filesystem, bypassing the various UNIX shells entirely.
Interestingly, files beginning with periods were reserved by HFS to identify device drivers, which led to some fascinating and catastrophic side effects for hapless UNIX users before Finder got smart enough to auto-convert a leading period to an option-8 bullet.
Originally posted by Amorph
Interestingly, files beginning with periods were reserved by HFS to identify device drivers, which led to some fascinating and catastrophic side effects for hapless UNIX users before Finder got smart enough to auto-convert a leading period to an option-8 bullet.
ooooh, I remember that. Rhapsody d2, wasn't it, when they fixed that? Or d3? Hera build days, at least.
People were *ticked*.
Originally posted by Kickaha
ooooh, I remember that. Rhapsody d2, wasn't it, when they fixed that? Or d3? Hera build days, at least.
People were *ticked*.
No, I'm thinking Mac OS, not OS X. Finder and the Open/Save dialogs started subbing in an option-8 around Mac OS 8, I believe.
I'm not surprised that OS X went a few builds before they remembered just how crucial that little patch was, though. Heh.
Carbon applications use the ":" as the delimiter, so they can use the "/" but no ":".
So when you save a file in a Cocoa/BSD application with a ":" in its name and look at the same file name from the Finder or another Carbon application, the ":" will be displayed as "/". It's the same vice-versa.
With Mac OS X 10.2 Apple tried to change this inconsistent behavior and patched Cocoa, so that the "Display Name" of a file (the one that respects your "show suffix" setting) does now show all ":"s as "/". So Cocoa applications that use the "Display Name" (e.g. TextEdit and all NSDocument-based applications) behave exactly like Carbon applications.
Standard BSD Terminal and X11 applications, however, still see the ":" instead of the "/".
And now to terminal to see just what all this "colon" business is about... Since none of you could answer my question before I posed it, I decided to find out for meself. These results are preliminary prehaps, but it seems that sh can't handle colon paths in the PATH variable. What is a posix environment to do?
Originally posted by thuh Freak
i thought no colon in paths was a posix req. like sh's PATH uses colon as a delimeter between paths. if i was to create a folder (or file) with a colon in its name, and tried adding that to my PATH, would I have to escape it out? Does sh even interpret escaped strings? Would it choke?
And now to terminal to see just what all this "colon" business is about... Since none of you could answer my question before I posed it, I decided to find out for meself. These results are preliminary prehaps, but it seems that sh can't handle colon paths in the PATH variable. What is a posix environment to do?
The colon restriction is the same as the restrictions against < and >. It's an artifact of the shell, not anything to do with the filesystem. With colons, as with any other shell metacharacter (including the space character), you escape them when you don't want them to have special meaning to the shell.
Any view of the filesystem that bypasses the shell altogether (Finder, Carbon and Cocoa file handling, etc.) can ignore the restrictions the shell imposes.