[ On Tuesday, May 9, 2000 at 09:11:02 (-0700), Tom Tromey wrote: ]
> Subject: Re: Possible bug involving ':' in directory names
>
> And once you get past the autoconf problems, you still have to contend
> with make. If a ":" ends up in your Makefile, you are doomed (more or
> less). This sucks, but it is basically unavoidable given make's
> extreme lameness.
I don't think it's fair to blame make for a design limitation it places
on acceptable filenames. You can blame it for being the wrong tool for
being the wrong tool for job, but that's a much different sort of thing.
If anyone really and truly believes that it should be possible to
include any character except perhaps '/' and '\0' in a filename then I
would invite them to first implement a set of tools that provide all of
the functionality one might require for software development but yet
face none of the limitations w.r.t. filename syntax our current tools
face. I would then be interested in seeing just how much harder to use
these new tools are as a result of all the new syntax limitations that
would no doubt result. Unix tools have already gone to great lengths to
hide conflicts between configuration and script syntax, and filename
syntax, though of course some tools go much further than others to this
end (eg. sh vs. make) and usually in direct proportion to the generality
of the tool, though sometimes in proportion to the complexity of syntax
they support.
Personally I would rather see people accept reasonable the limitations
on filename syntax and to that end that tool authors and maintainers
need to take the care and time to clearly document the limitations their
tools might place on acceptable filename syntax. Systems programmers
and tool designers often seem to assume that the limitations imposed by
their syntax design will be self-evident, but this is not always so.
We also need to take a great deal of care to not make assumptions about
what limitations the supporting system might place on things like
filename syntax and we need to include defensive code that will prevent
bad things from happening when an unsuspecing user violates any imposed
limitations, and even more importantly to have our tools produce consise
and meaningful warnings when such situations are encountered! This goes
double for systems programmers dealing with security sensitive tools of
course, but even software development tools can cause harm too!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
