From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <93BF5AB7-A0A7-441E-8FF3-4429A05213F5@gmail.com> From: underspecified@gmail.com To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [9fans] frogs and osx Date: Wed, 6 Feb 2008 22:51:28 +0900 References: <20080104022953.CE1461E8C1F@holo.morphisms.net> Topicbox-Message-UUID: 49553834-ead3-11e9-9d60-3106f5b1d025 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 ... >