* [9fans] frogs and osx @ 2008-01-03 19:46 Steve Simon 2008-01-04 2:29 ` Russ Cox 0 siblings, 1 reply; 13+ messages in thread From: Steve Simon @ 2008-01-03 19:46 UTC (permalink / raw) To: 9fans Hi, Using u9fs to access my mac I find I cannot see directories (folders) that have their own specific icon. This turns out to be because these directories contain a file Icon<cr> whiel <cr> is ASCII 13, and /sys/src/9/port/chan.c:1656 defines the frogs illegal in filenames to include carriage return. Why does frogs contain these latters, My feeling is that only <nul> should be illegal, perhaps these are a hangover from pre utf-8 days? Perhaps there is a good reason for not allowing such characters, I can see that creating such files should be discouraged but failing a read(2) of a directory containing such files seems extreme. Is it historic or there for a very good reason™ ? -Steve ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-03 19:46 [9fans] frogs and osx Steve Simon @ 2008-01-04 2:29 ` Russ Cox 2008-01-04 6:35 ` Bruce Ellis 2008-01-04 7:24 ` Lyndon Nerenberg 0 siblings, 2 replies; 13+ messages in thread From: Russ Cox @ 2008-01-04 2:29 UTC (permalink / raw) To: 9fans > Using u9fs to access my mac I find I cannot see directories (folders) > that have their own specific icon. > > This turns out to be because these directories contain a file > Icon<cr> whiel <cr> is ASCII 13, and /sys/src/9/port/chan.c:1656 > defines the frogs illegal in filenames to include carriage return. > > Why does frogs contain these latters, My feeling is that only <nul> > should be illegal, perhaps these are a hangover from pre utf-8 > days? > > Perhaps there is a good reason for not allowing such characters, > I can see that creating such files should be discouraged but > failing a read(2) of a directory containing such files seems extreme. > > Is it historic or there for a very good reason™ ? In addition to NUL, surely / should be illegal! I certainly wouldn't want \n in file names; \r seems just too close. In general, I'm quite happy that file names are guaranteed not to contain such difficult characters. There's very little benefit to be had by allowing them, and they complicate many things (witness xargs -0 on Unix). A better workaround for this particular problem would be for u9fs to rewrite the name or omit that entry entirely. Russ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 2:29 ` Russ Cox @ 2008-01-04 6:35 ` Bruce Ellis 2008-01-04 7:24 ` Lyndon Nerenberg 1 sibling, 0 replies; 13+ messages in thread From: Bruce Ellis @ 2008-01-04 6:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs my recollection is frogs was for files created by mistake. nothing to do with UTF-8. as for ICON\r ... can we call that consistency by obscurity. after all it is not to hard at all to subvert but a user won't, click click click nuh. also, i remember well when ' ' was snuck out to see if anyone noticed. it stuck. brucee On Jan 4, 2008 1:29 PM, Russ Cox <rsc@swtch.com> wrote: > > Using u9fs to access my mac I find I cannot see directories (folders) > > that have their own specific icon. > > > > This turns out to be because these directories contain a file > > Icon<cr> whiel <cr> is ASCII 13, and /sys/src/9/port/chan.c:1656 > > defines the frogs illegal in filenames to include carriage return. > > > > Why does frogs contain these latters, My feeling is that only <nul> > > should be illegal, perhaps these are a hangover from pre utf-8 > > days? > > > > Perhaps there is a good reason for not allowing such characters, > > I can see that creating such files should be discouraged but > > failing a read(2) of a directory containing such files seems extreme. > > > > Is it historic or there for a very good reason™ ? > > In addition to NUL, surely / should be illegal! > I certainly wouldn't want \n in file names; \r seems just too close. > In general, I'm quite happy that file names are guaranteed > not to contain such difficult characters. There's very little > benefit to be had by allowing them, and they complicate many > things (witness xargs -0 on Unix). > > A better workaround for this particular problem would be > for u9fs to rewrite the name or omit that entry entirely. > > Russ > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 2:29 ` Russ Cox 2008-01-04 6:35 ` Bruce Ellis @ 2008-01-04 7:24 ` Lyndon Nerenberg 2008-01-04 7:31 ` Bruce Ellis 2008-01-04 11:22 ` Pietro Gagliardi 1 sibling, 2 replies; 13+ messages in thread From: Lyndon Nerenberg @ 2008-01-04 7:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:24 ` Lyndon Nerenberg @ 2008-01-04 7:31 ` Bruce Ellis 2008-01-04 7:37 ` Lyndon Nerenberg 2008-01-04 7:45 ` Lyndon Nerenberg 2008-01-04 11:22 ` Pietro Gagliardi 1 sibling, 2 replies; 13+ messages in thread From: Bruce Ellis @ 2008-01-04 7:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs not at all, pragmatic.excluding crap from filenames was and still is good. if you want to vote '\r' as "not a mistake" you can. but filenames created from buggy stuff die dead, as they should. brucee On Jan 4, 2008 6:24 PM, Lyndon Nerenberg <lyndon@orthanc.ca> 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 ... > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:31 ` Bruce Ellis @ 2008-01-04 7:37 ` Lyndon Nerenberg 2008-01-04 7:45 ` Bruce Ellis 2008-01-04 7:45 ` Lyndon Nerenberg 1 sibling, 1 reply; 13+ messages in thread From: Lyndon Nerenberg @ 2008-01-04 7:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 2008-Jan-4, at 00:31 , Bruce Ellis wrote: > but filenames created > from buggy stuff die dead, as they should. what's buggy? '/' had merit. what else? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:37 ` Lyndon Nerenberg @ 2008-01-04 7:45 ` Bruce Ellis 0 siblings, 0 replies; 13+ messages in thread From: Bruce Ellis @ 2008-01-04 7:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs buggy is writing crap to a buffer ... like 0x80740378. nuke it. On Jan 4, 2008 6:37 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote: > > On 2008-Jan-4, at 00:31 , Bruce Ellis wrote: > > > but filenames created > > from buggy stuff die dead, as they should. > > what's buggy? '/' had merit. what else? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:31 ` Bruce Ellis 2008-01-04 7:37 ` Lyndon Nerenberg @ 2008-01-04 7:45 ` Lyndon Nerenberg 2008-01-04 9:52 ` Bruce Ellis 1 sibling, 1 reply; 13+ messages in thread From: Lyndon Nerenberg @ 2008-01-04 7:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 2008-Jan-4, at 00:31 , Bruce Ellis wrote: > not at all, pragmatic.excluding crap from filenames was and still is > good. > if you want to vote '\r' as "not a mistake" you can. but filenames > created > from buggy stuff die dead, as they should. We are arguing different things. EOL conventions are religion. Kernel delimiters are just code. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:45 ` Lyndon Nerenberg @ 2008-01-04 9:52 ` Bruce Ellis 2008-01-04 10:17 ` Steve Simon 0 siblings, 1 reply; 13+ messages in thread From: Bruce Ellis @ 2008-01-04 9:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs NO! a frog is a mistake. '\n' and '\r' are both frogs so where did you get the EOL thing from. i want neither in my filenames. if you do then change your copy of the code. or make up a new reason not to. make your own island of tranquility. brucee On Jan 4, 2008 6:45 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote: > > On 2008-Jan-4, at 00:31 , Bruce Ellis wrote: > > > not at all, pragmatic.excluding crap from filenames was and still is > > good. > > if you want to vote '\r' as "not a mistake" you can. but filenames > > created > > from buggy stuff die dead, as they should. > > We are arguing different things. EOL conventions are religion. Kernel > delimiters are just code. > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 9:52 ` Bruce Ellis @ 2008-01-04 10:17 ` Steve Simon 2008-01-04 10:26 ` Bruce Ellis 0 siblings, 1 reply; 13+ messages in thread From: Steve Simon @ 2008-01-04 10:17 UTC (permalink / raw) To: 9fans I take onboard all the commeonst made, and I am happy to code my own island of mutant frogs, however I wonder if there is a middle ground. Firstly I don't understand why the frogs are such a big problem, on plan9 at least a file with a \r in it appears as a , and this is a visible and easily typeable character, its true things where more awkward on ADM3As, but that was then. My biggest objection to the current code is a read of a directory balks at the \r and fails. Would it be better to hack the kernel to allow a read of directories containing \r and walks through them, but not allow read/write/stat/wstat. This would mean that such files are off limits but you can still access other files in the directory and those below - this feels rather non-othogonal maybe its a reasonable compromise. I could indeed hack u9fs but what to change the to, \r perhaps, but that feels pretty horrid too. Is there a palatable solution? -Steve ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 10:17 ` Steve Simon @ 2008-01-04 10:26 ` Bruce Ellis 0 siblings, 0 replies; 13+ messages in thread From: Bruce Ellis @ 2008-01-04 10:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Sure, I think it's a mistake for a server to throw you frogs. But no reason (within reason) for the library to up-chuck on one. But take care where you walk. If every protocol "violation" had to be treated as "shit happens" then the world falls apart. brucee On Jan 4, 2008 9:17 PM, Steve Simon <steve@quintile.net> wrote: > I take onboard all the commeonst made, and I am happy to > code my own island of mutant frogs, however I wonder if there > is a middle ground. > > Firstly I don't understand why the frogs are such a big problem, > on plan9 at least a file with a \r in it appears as a > , and this > is a visible and easily typeable character, its true things where > more awkward on ADM3As, but that was then. > > My biggest objection to the current code is a read of a directory balks > at the \r and fails. Would it be better to hack the kernel to allow a > read of directories containing \r and walks through them, but not > allow read/write/stat/wstat. > > This would mean that such files are off limits but you can still access > other files in the directory and those below - this feels rather > non-othogonal maybe its a reasonable compromise. > > I could indeed hack u9fs but what to change the > to, \r perhaps, but > that feels pretty horrid too. > > Is there a palatable solution? > > -Steve > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 7:24 ` Lyndon Nerenberg 2008-01-04 7:31 ` Bruce Ellis @ 2008-01-04 11:22 ` Pietro Gagliardi 2008-02-06 13:51 ` underspecified 1 sibling, 1 reply; 13+ messages in thread From: Pietro Gagliardi @ 2008-01-04 11:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] frogs and osx 2008-01-04 11:22 ` Pietro Gagliardi @ 2008-02-06 13:51 ` underspecified 0 siblings, 0 replies; 13+ messages in thread From: underspecified @ 2008-02-06 13:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ... > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-02-06 13:51 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-01-03 19:46 [9fans] frogs and osx Steve Simon 2008-01-04 2:29 ` Russ Cox 2008-01-04 6:35 ` Bruce Ellis 2008-01-04 7:24 ` Lyndon Nerenberg 2008-01-04 7:31 ` Bruce Ellis 2008-01-04 7:37 ` Lyndon Nerenberg 2008-01-04 7:45 ` Bruce Ellis 2008-01-04 7:45 ` Lyndon Nerenberg 2008-01-04 9:52 ` Bruce Ellis 2008-01-04 10:17 ` Steve Simon 2008-01-04 10:26 ` Bruce Ellis 2008-01-04 11:22 ` Pietro Gagliardi 2008-02-06 13:51 ` underspecified
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).