Re: [9fans] frogs and osx

[underspecified@gmail.com]

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 ...
>