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 headach
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 fo
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 Simo
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 type
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 <[EMA
buggy is writing crap to a buffer ... like 0x80740378. nuke it.
On Jan 4, 2008 6:37 PM, Lyndon Nerenberg <[EMAIL PROTECTED]> 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 el
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
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?
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 <[EMAIL PROTECTED]> wrote:
>
> On 2008-Jan-3, at 19:29
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 str
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 n
> 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 whiel is ASCII 13, and /sys/src/9/port/chan.c:1656
> defines the frogs illegal in filenames to include carriage ret
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 whiel is ASCII 13, and /sys/src/9/port/chan.c:1656
defines the frogs illegal in filenames to include carriage return.
W
13 matches
Mail list logo
