From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <877cd28f100e43ead94de82da6b4f49b@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c From: Charles Forsyth In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 22 Mar 2004 10:49:39 +0000 Topicbox-Message-UUID: 3c65471e-eacd-11e9-9e20-41e7f4b1d025 >>facility usually used by apps. (Consider Unix treatment of symbolic >>links; you usually want to follow them but not always, thus lstat(2) vs. >>stat(2).) it's a good example of how that approach breaks down: there isn't any way to tell from the outside how any given application will deal with symbolic links. for instance, some versions of ls follow them (unless given -L), others do not, following different reasonable rationales. if i tar up a tree, am i interested in following the links (ie, i want the tree's contents) or recording them (ie, i want the tree's structure)? it might depend on the link! fortunately tar has lots of options, but the default is to copy the structure (-h follows all symbolic links). generally, the approach seems to be for directory-traversing programs and programs such as mv do not follow the links, but programs that open files naturally follow the links. so cp follows the links. unless it's cp -R! then there are three options -H, -L, and -P to (attempt to) control handling of symbolic links, distinguishing between names on the command line that happen to be links, and names in the structure that are links. in some ways, it's rather worse with symbolic links.