Re: Use of uninitialized values in mail checking
On 6/21/12 11:47 AM, szymon.kal...@uj.edu.pl wrote: > Bash Version: 4.2 > Patch Level: 29 > Release Status: release > > > I found that behavior of bash depends on uninitialized values in memory. > In function file_mod_date_changed (mailcheck.c), if mailstat returns a > non-zero > value, we are checking condition finfo.st_size == 0, where finfo.st_size is > uninitialized. In those rare cases when finfo.st_size is zero and > mailfiles[i]->file_size > 0 we update mailfiles array with some random values > (while the file may even not exist). Thanks for the report. This will be fixed in the next version of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Unicode collation for readline completion in bash
On 6/20/12 7:27 AM, Rob Hoelz wrote: > So, I have a number of files with diacritics in the name, like this: > > $ ls > Sigur Rós - Dauðalogn.ogg Sigur Rós - Ég Anda.ogg Sigur Rós - > Rembihnútur.ogg Sigur Rós - Varúð.ogg > Sigur Rós - Ekki Múkk.ogg Sigur Rós - Fjögur Píanó.ogg Sigur Rós - > Valtari.ogg Sigur Rós - Varðeldur.ogg > > I'd like diacritics to be ignored when performing tab completion, so if > I type "Sigur Ros - Eg" and hit tab, "Sigur Rós - Ég Anda.ogg" is filled in. > > I've done some research, and it seems that this feature has yet to be > implemented. Does anyone know of an implementation for this, and if not, > would > this be acceptable as an addition to bash, or better yet, GNU readline? I would be willing to take a look at such an addition to readline, but I have no plans to do it myself. You should be able to get a long way by simply using strcoll(3) to perform string comparison when comparing filenames against what the user typed, but that interface is pretty limited, and it's not clear how you would accommodate case-insensitive or case-mapping comparisons. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Brace expansion infinite loop, memory corruption, and other bugs.
> On 6/5/12 12:14 AM, Scott McMillan wrote: > > A week or so ago I submitted a bug report using the bashbug command > > that involved some > > overflow issues with braces.c on OpenSUSE12.1 X86_64. Browsing the > > patches, I got > > the impression that braces.c hasn't been modified since the original > > 4.2 release, so the > > same bugs should exist in the most recent version. > > Thanks for the report. I'll take a look at your patches. Your original > report did not hit the mailing list. The patches look good, and will be in the next release of bash. Thanks for your help. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
cd // produces unexpected results
By accident I keyed in : cd // and noticed that my prompt included both slashes. Further testing, I think, reveals a minor issue: root@billlaptop ~# pwd; cd //; echo PWD=$PWD; cd /root; echo OLDPWD=$OLDPWD /root PWD=// OLDPWD=// I don't believe PWD and OLDPWD should contain double slashes as they're supposed to be the canonical path. -- Bill Gradwohl
Re: cd // produces unexpected results
> By accident I keyed in : > > cd // > > and noticed that my prompt included both slashes. Posix says shells have to leave two leading slashes in a pathname alone. Three or more can be collapsed to one, but two have to stay unchanged. This has come up multiple times in the past. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: cd // produces unexpected results
On 06/22/2012 09:47 PM, Chet Ramey wrote: >> By accident I keyed in : >> >> cd // >> >> and noticed that my prompt included both slashes. > > Posix says shells have to leave two leading slashes in a pathname alone. > Three or more can be collapsed to one, but two have to stay unchanged. > This has come up multiple times in the past. > A little more info, quoting from the Autoconf manual: POSIX lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants treat // like /. However, some treat // as a "super-root" that can provide access to files that are not otherwise reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it. HTH, Stefano
Re: Unicode collation for readline completion in bash
Rob Hoelz wrote: Hello, I have an idea for a new feature for bash/readline, and I wanted to get the community's feedback before I go about implementing it. --- Have you looked at the Unicode collation algorithm? They have one published with each released. You say you want to ignore diacritics...ok... but what order would you put them in? How about upper/lower case? Unicode has a specified ordering that that most OS implementations don't follow. Bash doesn't follow the Unicode ordering saying, well if POSIX doesn't say I have to, then I won't. POSIX is a mostly provincial standard based on ascii standard C -- with their official locale being called the C-locale until recently, when they realize how provincial it made their standard look. A standard that only supports 127 (or less if the anti-invisi-char freaks get their way) chars? I would see no problem with implementing a switch that toggles ignoring diacritics on or off... MS has a similar option in its OS search function -- for searches, "should" it ignore diacritics or not. But I'd also like to see unicode ordering, as it's yet another worldwide standard that the US isn't participating in (we got POSIX and the antiquated English measurement system...)... http://unicode.org/reports/tr10/ - Unicode Collation Algorithm, Unicode Technical standard #10 http://unicode.org/charts/uca/ - charts to show you the effect of the algorithm... Note A-Z occur before a-z... unlike in most implementations of en_US.UTF-8...where they are intermixed...
