From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <00a001c41007$5b94a420$6d4a7d50@SOMA> From: "boyd, rounin" To: <9fans@cse.psu.edu> References: <877cd28f100e43ead94de82da6b4f49b@terzarima.net> Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 22 Mar 2004 13:15:19 +0100 Topicbox-Message-UUID: 3c7dd572-eacd-11e9-9e20-41e7f4b1d025 > 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. symlinks really mess things up. i think the only time i use them is to point at the current version of the file or directory and they only ever link to a 'file' in the same directory. the (revolting) output of ls make it very obvious what the link points too. i could use hard links, but sorting through inums is no fun. a case in point is the lunix sam Make.* files. i symlink the right one(s) to Makefile. i think it's a clean approach, but i don't symlinks because they add far too much complexity, another system call, more bits and in practice they are grossly abused.