From owner-freebsd-questions Fri Jan 5 6:38:17 2001 From owner-freebsd-questions@FreeBSD.ORG Fri Jan 5 06:38:13 2001 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 7EF4537B404 for ; Fri, 5 Jan 2001 06:38:13 -0800 (PST) Received: (qmail 66847 invoked by uid 100); 5 Jan 2001 14:38:12 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14933.56404.946443.58230@guru.mired.org> Date: Fri, 5 Jan 2001 08:38:12 -0600 (CST) To: groggy@iname.com Cc: questions@freebsd.org Subject: Re: ln bug? In-Reply-To: <200101051432.OAA20806@en26.groggy.anc.acsalaska.net> References: <200101051432.OAA20806@en26.groggy.anc.acsalaska.net> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG groggy@iname.com types: > thanks for the understanting. > > i does seem to hurt the overall efficiency to make > all programs that use ln to have to do their own > work in recognizing relative paths thought ... > alot of redundant checking throughout programs. Again, it's not ln, it's symbolic links. Only shell scripts should call ln; every other programming (which excludes the simple scripting languages like awk and sed) lets you access the symlink and link system calls directly. If it really bothers you, create a patch for ln that behaves the way you want, and send-pr it. ln isn't even 250 lines long. Oh yeah - make sure you don't break the behavior that lets you create symlinks to files that don't exist yet. ... but thanks. i appreciate you shairng your knowledge. > > > > > > > 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 ... > > > > It's not ln that's special, it's symbolic links. If you make a hard > > link (leave off the -s flag to ln), you get the behavior you're > > looking for. The reason for that is because a hard link, like mv or > > cp, references a file instead of a string. None of these commands know > > anything about relative file names. The open and link system calls > > turn strings into file references, which is how relative file names > > are dealt with. The symlink system call doesn't do that translation, > > because a symlink references a string instead of a file. > > > > > 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? > > > > Actually, the current behavior *is* parallel. They all just pass > > strings to system calls where file names belong. Making ln do this > > would involve making ln recognize relative file names and do path > > translation for symlinks, which would make it not parallel the other > > utilities. > > > > > -- > > Mike Meyer http://www.mired.org/home/mwm/ > > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. > -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message