basename(1) defect

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

basename(1) defect

Stan Tsu
This is a bug with basename 5.3.0 found in the latest Cygwin 1.5.15.1.
This used to work with basename in the March 2003 version.  Sorry I
don't know the version number any more because the update removed
the old version.

$ FCF=N/A
$ echo $FCF
N/A
$ Z=${FCF:(-1)}
$ echo $Z
A
$ FCG=`basename $FCF $Z`
$ echo $FCG
A                           <====== should return 'N/'

Another simpler way to see the bug:

$ 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/'


--
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/

bug.txt (644 bytes) Download Attachment
cygcheck.out (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basename(1) defect

Brian Dessent
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/

Reply | Threaded
Open this post in threaded view
|

Re: basename(1) defect

Eric Blake-2
In reply to this post by Stan Tsu
> > This is a bug with basename 5.3.0 found in the latest Cygwin 1.5.15.1.

Not a bug.

>
> 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/'

POSIX requires that basename return everything beyond
the final slash onwards, minus a partial suffix. The output
you got is REQUIRED by basename (beyond the final suffix
is "A", and "A" is a complete match rather than a partial
suffix of "A", so the result must be "A"), and any other
behavior from an older version of basename would be the
bug, not the current behavior of either basename-5.3.0
or basename-5.93.

> >
> > Even with quoting:
> >
> > $ basename 'NA' A
> > N
> > $ basename 'N/A' A
> > A                           <====== should return 'N/'

Quoting makes no difference - the shell strips quotes
before passing the arguments to /bin/basename.

>
> 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}

This could also be done by /bin/expr (if you like coreutils),
or even with awk, sed, or perl.  But Brian is correct,
shell parameter expansion is the most efficient way to
do string parsing, as it does not spawn any external
processes.

--
Eric Blake
volunteer cygwin bash/coreutils maintainer



--
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/

Reply | Threaded
Open this post in threaded view
|

RE: basename(1) defect

Buchbinder, Barry (NIH/NIAID) [E]
In reply to this post by Stan Tsu
[hidden email] wrote:

>>> This is a bug with basename 5.3.0 found in the latest Cygwin
>>> 1.5.15.1.
>
> Not a bug.
>
>>
>> 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/'
>
> POSIX requires that basename return everything beyond the final slash
> onwards, minus a partial suffix. The output you got is REQUIRED by
> basename (beyond the final suffix is "A", and "A" is a complete match
> rather than a partial suffix of "A", so the result must be "A"), and
> any other behavior from an older version of basename would be the
> bug, not the current behavior of either basename-5.3.0 or
> basename-5.93.      
>
>>>
>>> Even with quoting:
>>>
>>> $ basename 'NA' A
>>> N
>>> $ basename 'N/A' A
>>> A                           <====== should return 'N/'
>
> Quoting makes no difference - the shell strips quotes before passing
> the arguments to /bin/basename.
>
>>
>> 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}
>
> This could also be done by /bin/expr (if you like coreutils), or even
> with awk, sed, or perl.  But Brian is correct, shell parameter
> expansion is the most efficient way to do string parsing, as it does
> not spawn any external processes.  
>
> --
> Eric Blake
> volunteer cygwin bash/coreutils maintainer

Maybe you really want dirname.

/c> dirname N/A
N
/c> echo $(dirname N/A)/
N/

--
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/

Reply | Threaded
Open this post in threaded view
|

RE: basename(1) defect

Stan Tsu
Thanks.  The echo works. I haven't verified whether the latest basename(1)
behaves in the same way because I've run across a bigger problem.

Has anyone seem severe performance degradation running Cygwin on
WinME systems?  I've seen my system just get slower and slower over
the past several months. Cygwin ops that took a few seconds to run
now are running into the minutes.  Are there tools I can run to see what's
taking so long?  I've looked at the WinME side and I don't see anything
obviously wrong (SYSMON says resources okay, no viruses, defragged etc).
Any thoughts?  Help!

Stan


>From: "Buchbinder, Barry (NIH/NIAID)" <[hidden email]>
>To: <[hidden email]>
>CC: "Stan Tsu" <[hidden email]>
>Subject: RE: basename(1) defect
>Date: Fri, 25 Nov 2005 08:33:50 -0500
>
>[hidden email] wrote:
> >>> This is a bug with basename 5.3.0 found in the latest Cygwin
> >>> 1.5.15.1.
> >
> > Not a bug.
> >
> >>
> >> 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/'
> >
> > POSIX requires that basename return everything beyond the final slash
> > onwards, minus a partial suffix. The output you got is REQUIRED by
> > basename (beyond the final suffix is "A", and "A" is a complete match
> > rather than a partial suffix of "A", so the result must be "A"), and
> > any other behavior from an older version of basename would be the
> > bug, not the current behavior of either basename-5.3.0 or
> > basename-5.93.
> >
> >>>
> >>> Even with quoting:
> >>>
> >>> $ basename 'NA' A
> >>> N
> >>> $ basename 'N/A' A
> >>> A                           <====== should return 'N/'
> >
> > Quoting makes no difference - the shell strips quotes before passing
> > the arguments to /bin/basename.
> >
> >>
> >> 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}
> >
> > This could also be done by /bin/expr (if you like coreutils), or even
> > with awk, sed, or perl.  But Brian is correct, shell parameter
> > expansion is the most efficient way to do string parsing, as it does
> > not spawn any external processes.
> >
> > --
> > Eric Blake
> > volunteer cygwin bash/coreutils maintainer
>
>Maybe you really want dirname.
>
>/c> dirname N/A
>N
>/c> echo $(dirname N/A)/
>N/

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


--
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/

Reply | Threaded
Open this post in threaded view
|

Re: basename(1) defect

Larry Hall (Cygwin)
Stan Tsu wrote:

> Thanks.  The echo works. I haven't verified whether the latest basename(1)
> behaves in the same way because I've run across a bigger problem.
>
> Has anyone seem severe performance degradation running Cygwin on
> WinME systems?  I've seen my system just get slower and slower over
> the past several months. Cygwin ops that took a few seconds to run
> now are running into the minutes.  Are there tools I can run to see what's
> taking so long?  I've looked at the WinME side and I don't see anything
> obviously wrong (SYSMON says resources okay, no viruses, defragged etc).
> Any thoughts?  Help!


First question.  Have you been changing the version of Cygwin DLL during
this time (i.e. using snapshots)?  If so, then try reinstalling the latest
release package (1.5.18) and see if that resolves the problem.  If it doesn't
or if you have been using 1.5.18 the whole time, then that points to external
forces.  You'll want to review your software installation/configuration
history.

If you really feel this is a Cygwin specific issue, then start with the
basics.  Read and follow the problem reporting guidelines found here:

> Problem reports:       http://cygwin.com/problems.html

That should help anyone here interested in evaluating your issue.

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746

--
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/

Reply | Threaded
Open this post in threaded view
|

Re: basename(1) defect

Stan Tsu
The slowdown appears to be a problem with WinME, but I'll keep digging.


>From: "Larry Hall (Cygwin)" <[hidden email]>
>Reply-To: [hidden email]
>To: Stan Tsu <[hidden email]>
>CC: [hidden email]
>Subject: Re: basename(1) defect
>Date: Thu, 29 Dec 2005 22:12:04 -0500
>
>Stan Tsu wrote:
>>Thanks.  The echo works. I haven't verified whether the latest basename(1)
>>behaves in the same way because I've run across a bigger problem.
>>
>>Has anyone seem severe performance degradation running Cygwin on
>>WinME systems?  I've seen my system just get slower and slower over
>>the past several months. Cygwin ops that took a few seconds to run
>>now are running into the minutes.  Are there tools I can run to see what's
>>taking so long?  I've looked at the WinME side and I don't see anything
>>obviously wrong (SYSMON says resources okay, no viruses, defragged etc).
>>Any thoughts?  Help!
>
>
>First question.  Have you been changing the version of Cygwin DLL during
>this time (i.e. using snapshots)?  If so, then try reinstalling the latest
>release package (1.5.18) and see if that resolves the problem.  If it
>doesn't
>or if you have been using 1.5.18 the whole time, then that points to
>external
>forces.  You'll want to review your software installation/configuration
>history.
>
>If you really feel this is a Cygwin specific issue, then start with the
>basics.  Read and follow the problem reporting guidelines found here:
>
>>Problem reports:       http://cygwin.com/problems.html
>
>That should help anyone here interested in evaluating your issue.
>
>--
>Larry Hall                              http://www.rfk.com
>RFK Partners, Inc.                      (508) 893-9779 - RFK Office
>838 Washington Street                   (508) 893-9889 - FAX
>Holliston, MA 01746

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



--
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/