From owner-freebsd-hackers Sun Jul 12 17:43:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13229 for freebsd-hackers-outgoing; Sun, 12 Jul 1998 17:43:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13224 for ; Sun, 12 Jul 1998 17:43:47 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id RAA13247 for ; Sun, 12 Jul 1998 17:43:23 -0700 (PDT) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id UAA23407; Sun, 12 Jul 1998 20:43:26 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id VAA28183; Sun, 12 Jul 1998 21:21:08 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id UAA15906; Sun, 12 Jul 1998 20:47:40 -0400 (EDT) Date: Sun, 12 Jul 1998 20:47:40 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807130047.UAA15906@lakes.dignus.com> To: freebsd-hackers@freefall.cdrom.com, joelh@gnu.org Subject: Re: Improvemnet of ln(1). In-Reply-To: <199807122259.RAA02889@detlev.UUCP> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >> I will personally buy a beer (so long as it's not an American beer) > >> for the first five people who can show me current existance of such a > >> script. (In other words, a script written during or after this > >> discussion doesn't count.) That said, I sincerely doubt I'll have to > >> buy a single beer. > > I don't know if this counts - > > If it's existing code that runs on BSD, whether public or private, it > counts. I don't want to break anything. > > Let me make sure I've got all the details. > > > but the source/build management system at SAS would > > break... technically, it's a program that scans the output. The > > code doesn't employ reasonable return-codes for some ungodly > > reasons, and thus, there are 'scraping scripts' that read through > > several gigs worth out shell/compiler/utility output and "decide" if > > the build was successful. > > Ugh. Believe me - that's being polite! The entire setup suffers from what I call the "bailing" problem. That is, "we're too busy bailing water to steer the ship off of the reef into a dock for repairs." > > > Changing the behaviour of ln, as you suggest, would likely break all > > of that 'log scraping' code. [Who knows how many questionable 'ln' > > commands are embedded within this spaghetti.] > > By questionable ln commands, you mean ln -s's that link to files that > don't exist at the time of the command is issued? Most assuredly... the intent is for the files to (hopefully) exist at a future time... Part of it is builds; part of it build-area management, etc... > > > Believe me; as I'm the manager of the compiler group; and I am > > expressly prohibited from changing even the smallest typo in a > > compiler message; much less adding a new one - for fear of such a > > calamity. The argument is that a broken 'script scraper' costs > > several thousands of developers a couple of days while it's > > repaired... we're talking man-years here of wasted time... I don't > > buy it myself - but that's the rule I live under. > > Okay. If it is your own belief that adding a new message would break > things, then I'll accept that. (I just want it to be your own belief, > not something handed down on high that you believe is a product of > FUD.) Actually, it's a combination of both. My own experience has caused "thundering hurds" of people to call me up; whereby we beat a hasty retreat to a previous revision of a compiler. [The appellation there was someone elses, not my own :-) ] However, I'm convinced a good percentage of the concern was simply FUD. As far as "break" something - it would inconvenience a large group of developers (which costs money.) > > If this code does these things, that is: (1) Creates a symbolic link > to a file that doesn't exist at the time, and (2) analyzes the output > of ln's stderr, and (3) would likely break on the addition of a new > line in the input of [2], then please email me with the name of your > favorite beer, and the address of the liquor store where you want to > pick it up. (Alternatively, if you live in Texas, I may be in your > area soon, and would be happy to buy you the beer in person.) However; you bring up another point. The code I'm thinking of doesn't actually run on FreeBSD, it's on HP/UX at the moment. Only a portion of the builds currently run on FreeBSD.... so, the entire discussion is moot :-) [sorry to drag it out... I didn't realize that at the start.] And, unfortunately; I'm in Raleigh NC... and can no longer drink beer... But; if you're ever in the area - look me up! - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message