X-Spam-Check-By: sourceware.org Message-ID: <4384FEEF.A3B7490D@dessent.net> Date: Wed, 23 Nov 2005 15:44:47 -0800 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: basename(1) defect References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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 Stan Tsu wrote: > This is a bug with basename 5.3.0 found in the latest Cygwin 1.5.15.1. 1.5.15 was three releases ago, it's most certainly not the latest. But that's not really relevant to your question, I don't think. > $ basename NA A > N > $ basename N/A A > A <====== should return 'N/' > > Even with quoting: > > $ basename 'NA' A > N > $ basename 'N/A' A > A <====== should return 'N/' The purpose of basename is to "remove any leading directory components from NAME." (from "info basename".) So I don't see any conceivable scenario where returning N/ (a leading directory component) could ever be considered correct behavior, regardless of past behavior. Maybe you are trying to use basename to do general-purpose string processing, but it is not designed for this. It's intended to take a filename and strip off any leading directory components, and optionally remove a trailing suffix from the resulting filename. If you just want to remove a trailing string I suggest you just use bash's built in parameter expansion: $ FCF="N/A"; Z=${FCF:(-1)}; echo ${FCF%$Z} Brian -- 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/