Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <41828674.6090507@x-ray.at> Date: Fri, 29 Oct 2004 20:05:40 +0200 From: Reini Urban User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: coreutils rm nul References: <41827684 DOT 7040007 AT x-ray DOT at> <20041029172609 DOT GC5890 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20041029172609.GC5890@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Christopher Faylor schrieb: > On Fri, Oct 29, 2004 at 06:57:40PM +0200, Reini Urban wrote: >>Would it be appreciated if coreutils rm would be able to >>remove special windows files, like nul, aux, com and such, if it's >>really a file and no device? >> >>I'm working on such a coreutils patch for rm(1) only, not mv(1), ln(1) >>or unlink(3) from cygwin1.dll. >>Should it go to unlink(3) instead? >> >>If the original proposer of the coreutils package, Mark, will not revive >>in the next months I might be persuaded to maintain it then. > > Given the number of times I've mentioned the fact that we need coreutils > with no response, I think it is safe to assume that it is still > unmaintained. > > Unless there are objections in the next several hours this package is > yours. The problem is if I really want to maintain such a beast. Having maintained a patched sh-utils at my company (restricted password-less su and sudo extensions, centralized logging) I know what will happen... > FWIW, I think that fixing unlink so that it can remove these kinds of > files makes more sense than patching coreutils. But, here again, Red > Hat would probably need an assignment from you for this type of work. unlink nul: since only/mostly coreutils (echo > nul) create such files, I thought is better to safe some cycles in cygwin1.dll for every unlink call - it's far too slow anyway, but that's not our fault. The assignment is already on the way. But we have weekend and our post does nothing until monday. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/