From owner-freebsd-questions Thu Jan 4 5:46:42 2001 From owner-freebsd-questions@FreeBSD.ORG Thu Jan 4 05:46:40 2001 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from groggy.anc.acsalaska.net (groggy.anc.acsalaska.net [198.70.228.224]) by hub.freebsd.org (Postfix) with ESMTP id 9153737B400 for ; Thu, 4 Jan 2001 05:46:38 -0800 (PST) Received: (from abc@localhost) by groggy.anc.acsalaska.net (8.9.3/8.9.3) id NAA08331; Thu, 4 Jan 2001 13:46:22 GMT (envelope-from groggy@iname.com) Date: Thu, 4 Jan 2001 13:46:22 GMT From: groggy@iname.com Message-Id: <200101041346.NAA08331@groggy.anc.acsalaska.net> X-Authentication-Warning: groggy.anc.acsalaska.net: abc set sender to groggy@iname.com using -f Subject: Re: ln bug? X-Mailer: Umail v1.6 (FreeBSD) To: cliff@raggedclown.net To: "Gonzalez, Lissette" To: "freebsd-questions" To: "Kerr, Greg" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > is this a bug in "ln"? > > > > > > if i am in a directory with a file xxx: > > > > > > ln -s xxx /tmp/xxx > > > > > > will create link /tmp/xxx, but it will point to itself in /tmp. > > > ln is not pointing the link to to xxx in the current directory > > > as specified/intended on the command line. doesn't seem right. > > > > No, that's right. When making symbolic links, the first argument is > > the _string_ that the link points to. It is better to not think of > > symbolic links pointing to a specific file. Rather, when a symbolic > > link is processed as part of a path, the string value of the link is > > substituted. > > -- > > Crist J. Clark cjclark@alum.mit.edu > > That is a neat explanation for something that can be quite difficult to explain! > It might be worth pointing out to people getting their head around this > for the first time that the "_string_" may not necessarily exist as a file, symbolic links > can "point" to thin air. This is particularly irritating for > bad typists... > > Cliff what makes "ln" so special? it's only function is to reference a file/dir just like "cp" or "mv" or "rm" or any other utility operating on files. ok - it's valid to point to nothing, but that doesn't make it logical for it to be so incongruous with the operation of other utilities with respect to treating a "string" as relative if it has no leading slash ... is this a POSIX standard of "ln" operation? i dunno ... the man page states nothing about POSIX compatibility. is there a good reason for not parallelling all other utilities that operate on files with repect to recognizing relative pathnames as such? ps - thank you, and please ditto a copy off the list :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message