Re: "tla build-config" question and suggestion

Andrew Suffield wrote:
> There is something to be said for passing the paths through a
> canonifying function (remove all /./ and /foo/../ from the path). That
> retains the security benefits and avoids issues with no-ops. This one
> falls under 'liberal in what you receive', it's quite plausible that
> configs could be generated by some other code and thusly be in
> non-canonical form.
>   
Removing `.' elements is fine.  (I guess I was just lazy about that.)

Removing `foo/..' is problematic.   That's HTTP, not Unix.   Now if you want
to tell me that symbolic links are a daemonic work, well, that's true.   
We would
have been better off with weak-referencing hard links to files and synthetic
cloning links to directories.   The latter would have been impractical 
on the
systems of the 80s.  Symlinks are, as much as anything, the workaround that
arose to work around that impracticality.

As for auto-generated names:  I'd be all for eliminating `.' elements and
doubled slashes.    For reasons discussed, even an auto-generated name
shouldn't contain `..' so, rather than trying to guess what was meant,
it's better for Arch to continue to flag such as an error.

> In the real world, /./ happens because one piece of software wanted a
> directory there, but the user didn't, so they supplied a periot
> instead. Consider './configure --prefix=.' - you can't use the empty
> string, because '/foo' and './foo' are different. That's more or less
> why unix has the '.' directory name: it's a *useful* no-op for
> connecting pieces of software together.
>   
I *suspect* your "just so" story about the history of `.' is not *quite* 
correct.
If that's all it were, "--prefix=`pwd`" would be (user space, not file 
system)
solution enough.

A better "just so" theory might be that `getcwd(3)' started out life as a
user-space function (in the days before symlinks, no less).   How is that
function to be implemented if not by using `.'?  (Remember that the cwd
of a process is an open inode, not a symbolic path!)

That said, yes, the `.' and `..' hacks are serendipitously useful when
typing paths.

-t