On 10/27/2011 6:04 PM, Hans Witvliet wrote:
On Thu, 2011-10-27 at 13:21 -0400, Brian K. White wrote:
Except, http://foo.foo.com/blah is a perfectly valid local filesystem path. You can have a directory named "http:", you can have two "/" next to each other and it means the same as just one, for a reason (think building paths out of variables and one variable may be empty sometimes and sometimes not), even the ?'s and @'s and %'s in a query string are all valid filesystem characters.
That is really sick ;[)) Actually, i think you ought to make a "http://" directory, not "http:" as you run into problems with making "//" dirs.
Anyway, contraptions like these are fun to humor novice sysadmins (and break sloppy scripts), just like dirs/files beginnibg with a space....
hw
Yep. Basically it's just not the low level building block tools place to tell the user and the high level tools what use to make of a low level facility like the filesystem. The filesystems job is just to make as many things possible, as possible. What the user does with filenames is not the kernel or libc developers business. There are a very few unavoidable technical limits, and even those are really not limits just, things that would be silly and inconvenient to do very much, like embedding an escape code or a form feed in a file name. It's not convenient to type, and breaks a lot of common expectations and will break all but the most well coded programs, but there are also any number of unpredictable reasons why you might actually want to do it. There is nothing wrong, at that level, with naming a file or a directory with characters that just happen to be similar to what url's look like, any more than there is anything wrong with making file/directory names that happen to look like any other kinds of strings that are found in other contexts. In fact practically every file or directory name looks like something else that is not a file or directory. Your home directory is your name, the directory it lives in is the english word home, etc.. most names have some sort of meaning. A path that looks like a url is exactly like that, and support for that is specifically provided on purpose not by accident. What I'm trying, poorly, to get across is it's wrong to think in terms of what is commonly done, today, in ones own limited experience. Things like the shell and the filesystem and the libc and kernel functions that use them, these are all low level building blocks that everything else is built on and made out of. Low level pieces like that have no idea what high level uses will be made of them, and if they are to be useful, they need to have as few built in assumptions and limitations as possible. So that's why if an app wants to specially recognize urls and treat them differently, and give up the ability to handle a real local file that had the same characters, the app is free to do that because it's only the app that will be hurt by the short sightedness. The kernel, libc, other core libs, shell, and other core utils, all have to be a lot better than that and make no such assumptions. I think I just said the same thing 3 times with hardly enough variation to be helpful, sorry. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org