Compelling reason not to have : in filenames?

Posted:
in macOS edited January 2014
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?

Comments

  • Reply 1 of 17
    pesipesi Posts: 424member
    the ":" was the directory path separator (i.e. Machintosh HD:Applications:Blah Blah Blah) pre-OS X, which now uses the Unix "/" to denote directories in paths.



    if you were to send a fine with ":" in the filename to an OS 9 user, they woulsn't have much fun with it.
  • Reply 2 of 17
    gardnerjgardnerj Posts: 167member
    i think it is a unix reserved character thing. i'm just looking around to see what its used for.



    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.
  • Reply 3 of 17
    der kopfder kopf Posts: 2,275member
    Well, pesi, I kind of suspected that, but that somehow makes me wonder why you CAN use the directory signifiers for many other directories: / and \\ are perfectly possible.
  • Reply 4 of 17
    gardnerjgardnerj Posts: 167member
    Confused myself ... not difficult. i was thinking of meta characters eg.



    ; & ( ) | < >



    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.
  • Reply 5 of 17
    gordygordy Posts: 1,004member
    Can't use it on Windows either.
  • Reply 6 of 17
    ghost_user_nameghost_user_name Posts: 22,667member
    The colon ':' is the only reserved character on Mac HFS+ filesystems because it is used, as has already been mentioned, as the path separator. If you attempt to put a colon in a filename, it will be replaced by a hyphen (though, not necessarily in the Finder). This doesn't have anything to do with Unix. It's been like this for years upon years with HFS+ and its predecessor HFS.



    Characters such as the slashes '/' '\\' and ampersand '&' and brackets '<' '>' and such are all valid on HFS+.
  • Reply 7 of 17
    buonrottobuonrotto Posts: 6,368member
    Brad beat me to it.
  • Reply 8 of 17
    der kopfder kopf Posts: 2,275member
    So do you see this changing in any OS update soon? And does this mean that, if you format your disk UFS, you WOULD be able to use the colon?
  • Reply 9 of 17
    gardnerjgardnerj Posts: 167member
    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.
  • Reply 10 of 17
    der kopfder kopf Posts: 2,275member
    Quote:

    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.
  • Reply 11 of 17
    chuckerchucker Posts: 5,089member
    Quote:

    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.
  • Reply 12 of 17
    amorphamorph Posts: 7,112member
    Quote:

    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.
  • Reply 13 of 17
    kickahakickaha Posts: 8,760member
    Quote:

    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*.
  • Reply 14 of 17
    amorphamorph Posts: 7,112member
    Quote:

    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.
  • Reply 15 of 17
    There is a difference between Carbon and Cocoa/BSD. Cocoa and BSD (X11, Terminal) applications can use the ":" in filenames, but no "/", because that's the delimiter.

    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 "/".
  • Reply 16 of 17
    thuh freakthuh freak Posts: 2,664member
    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?
  • Reply 17 of 17
    amorphamorph Posts: 7,112member
    Quote:

    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.
Sign In or Register to comment.