Date: Sat, 10 Aug 2002 09:20:55 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Jerry McAllister <jerrymc@clunix.cl.msu.edu> Cc: Roman Neuhauser <neuhauser@bellavista.cz>, Peter Leftwich <Hostmaster@Video2Video.Com>, Matthew Seaman <m.seaman@infracaninophile.co.uk>, Jeff Jirsa <jeff@unixconsults.com>, John Bleichert <syborg@stny.rr.com>, FreeBSD LIST <FreeBSD-Questions@FreeBSD.ORG> Subject: Re: Links (was: Is simplicity despised? WAS: Message-ID: <20020809235055.GE39322@wantadilla.lemis.com> In-Reply-To: <200208091512.g79FCAN19969@clunix.cl.msu.edu> References: <20020808234634.GJ8561@wantadilla.lemis.com> <200208091512.g79FCAN19969@clunix.cl.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 9 August 2002 at 11:12:10 -0400, Jerry McAllister wrote:
>>>>>
>>>>> Because symlinks make it abundantly clear what is linked to what.
>>>>> Hard links can lead to confusion. I suppose that's not a problem
>>>>> For most of you though. But, for example, if a person doesn't know
>>>>> which is linked to which, that person wouldn't know that more is
>>>>> really less. They might think less is really more (if they discovered
>>>>> it at all).
>>>>
>>>> No, less is not hardlinked to more, nor is more hardlinked to less.
>>>> They're two names for the same file.
>>>>
>>>> So... Yes, you're right: less is really more. But at the same time,
>>>> more is less.
>>>
>>> Yup. But was that file created as less or more
>>
>> Why should you care?
>
> I care if I want to know how to change what the file is.
> Do I rebuild more or less in this case?
You still don't seem to understand. This has nothing to do with the
build process. In this particular case, I've checked, and it turns
out to be less. Take a look at the files in /usr.bin/
/usr/src/usr.bin/less/ for more details. It's equally possible that
it could have been in /usr.bin/ /usr/src/usr.bin/more/
>>> and if I want to make a change do I start with the source for less
>>> or more, etc?
>>
>> It's the same source.
>
> No, there is a source for more and a source for less -- somewhere.
No, no, no. We've been saying all along that it's one program. How
can you have two different sources for the same file?
>>> Minor maybe, but ln -s makes it clear and is not so onerrous in
>>> most situations.
>
> By onerous, I mean the extra resource and possible problems are not
> so onerous a penalty for most use.
So onerous as what? They're a penalty, and they don't bring any
advantages. Specifically, they use at least an inode (128 bytes) of
disk storage per instance, and if the name is longer than will fit in
the inode, they'll also use a disk data block, currently 16 kB.
> If the use if heavy then possibly the extra CPU and disk resource
> may mean something and a hard link is then needed.
What possible advantage can a symlink have here?
>> No, symlinks impose an order, and they don't clarify, they obfuscate.
>> If you do this, you'll end up with a broken symlink:
>>
>> $ echo foo > bar
>> $ ln -s bar baz
>> $ rm bar
>> $ cat baz
>> cat: baz: No such file or directory
>> $
>>
>> On the other hand, links are *the* basic mechanism for naming files.
>> If you do this, it will work:
>>
>> $ echo foo > bar
>> $ ln bar baz
>> $ rm bar
>> $ cat baz
>> foo
>
> Sure. and if I do:
>
> # echo joes stuff > ./home/joe.stuff
> # echo freds stuff > ./home/fred.stuff
> # ln joe ./home/jor.stuff
> # ln fred ./home/joe.stuff
What are the files fred, joe and home/jor.stuff? Unless they exist
already, this will fail. I think you mean to say
# ln ./home/joe.stuff joe
# ln ./home/joe.stuff fred
> # rm joe
> # cat fred
> joes stuff
> "Oh Oh better fix that"
> # vi fred
> c$freds stuff ESC:wq
> # cat ./home/joe.stuff
> freds stuff
>
> A user error less likely to happen with a symlink since they show
> up so obviously in an ls -l.
Links show up in ls -l first. First, you have to look there. This is
an obvious error, like the two or three in your example, which you
obviously didn't try out.
> Hard links have their place. But, symlinks needn't be so quickly
> dismissed.
Symlinks have their place. But hard links are the building stuff of
file systems. Symlinks are a relatively new addition to the file
system: ten years ago, a number of commercial UNIXes, and also Linux,
didn't have them.
The problem with symlinks is that they confuse people. You still seem
to think there's something different between /usr/bin/more and
/usr/bin/less. So people put these forests of symlinks in directories
where they just confuse things.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020809235055.GE39322>