Just to add my two cents, I had a bit of fun trying to identify the
cause of some strange behavior in Acme SAC for OS X.
The home directory started refusing to display the contents of my home
directory. The culprit? An icon file had snuck in
and its carriage return was giving Acme SAC a headache. I agree that
OS X probably shouldn't store icons in that manner
(even the applications aren't silly enough to do that), but this is
something we might just have to work around. Not being
able to access directories with icons is a large price to pay to take
the high ground ...
--underspecified
On Jan 4, 2008, at 8:22 PM, Pietro Gagliardi wrote:
It's also a pity that you'll need to rewrite your code to handle two
different types of delimiters then, or add a dellim argument like in
Brdstr. The UNIX philosophy says to do what's smaller and faster,
not what's better (which is why I don't like it).
I haven't seen a reason to use the format "icon\rname" in an OS X
directory. Why not just store the information in the
folder's .DS_store file (which has every other Finder credential)?
Ahh, the mysteries of my iMac...
On Jan 4, 2008, at 2:24 AM, Lyndon Nerenberg wrote:
On 2008-Jan-3, at 19:29 , Russ Cox wrote:
In addition to NUL, surely / should be illegal!
I certainly wouldn't want \n in file names; \r seems just too close.
Pathological egregiousness?
There is only one true separator, and that is '/'. In the context
of pathnames, '/' is NUL as per C strings. NUL in pathnames is
silly, but allowed, as per pathnames.
It makes no sense, but if you can push a NUL into a pathname, you
should deal with the result. It's a pity the intermediate code has
to do so as well ...
