From owner-freebsd-commit  Sat Aug  5 16:43:53 1995
Return-Path: commit-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id QAA06558
          for commit-outgoing; Sat, 5 Aug 1995 16:43:53 -0700
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id QAA06505
          for cvs-usrbin-outgoing; Sat, 5 Aug 1995 16:42:30 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id QAA06483
          ; Sat, 5 Aug 1995 16:42:19 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id QAA03188; Sat, 5 Aug 1995 16:41:37 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199508052341.QAA03188@gndrsh.aac.dev.com>
Subject: Re: cvs commit: src/usr.bin/xinstall xinstall.c
To: bde@zeta.org.au (Bruce Evans)
Date: Sat, 5 Aug 1995 16:41:37 -0700 (PDT)
Cc: joerg@freefall.cdrom.com, CVS-commiters@freefall.cdrom.com,
        cvs-usrbin@freefall.cdrom.com
In-Reply-To: <199508050116.LAA26907@godzilla.zeta.org.au> from "Bruce Evans" at Aug 5, 95 11:16:38 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1230      
Sender: commit-owner@FreeBSD.org
Precedence: bulk

> 
> >>   Modified:    usr.bin/xinstall  xinstall.c
> >>   Log:
> >>   Make install not remove the target file if -s has been specified but
> >>   stripping failed (since the file has been a shell script, for
> >>   example).
> 
> >Ignoring error conditions from strip is not a good idea.  Using -s option
> >to install non binary files is a usage error.  
> 
> I thought the patch in the PR was so obviously wrong that it wouldn't be
> applied.

Me too.  Next time I know, I will state that this is the wrong thing to
do when I see these PR's like this :-(.

> >Removing the file if strip failed is probably not the right thing to
> 
> `install' has already unlinked the original file so there's nothing better
> to do than to remove the results of the usage error.

Humm.. can install open the file before it is unlinked, unlink it, try
the install and if it fails some how relink the open file?  [I am not
much on this type of user land operation, so I am not sure if you can
do that :-)]

> 
> >do, but being silent about strip errors is not a good idea.
> 
> Yes.

:-)


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD