Re: patch failures/offsets through bash32-039
grarpamp wrote: Hi. Here's a logfile of patch failures/offsets through bash32-039. Untar, cd, for i in patch ; patch < $i The sigs on bash-3.2.tar.gz and all the patches check out ok. The patches are supposed to be applied with `patch -p0'. When I use this on my development platform, I don't get any failed patches. I do get the line offsets, which, since the patches apply correctly, are not really a problem. Please try it again with `patch -p0' and let me know what platform it fails on, if any. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Unicode Normalization on Mac OS X (HFS+ filesystem)
Stephan Kleisinger wrote: Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin9.3.0 Compiler: /usr/bin/gcc-4.0 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin9.3.0' -DCONF_MACHTYPE='i386-apple-darwin9.3.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I/opt/local/include -O2 uname output: Darwin cicero.lan 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386 Machine Type: i386-apple-darwin9.3.0 Bash Version: 3.2 Patch Level: 39 Release Status: release Description: The Mac OS X Filesystem HFS+ reports filenames in Unicode NFD Normalization form. As arguments (e.g. open()) all normalization forms are accepted. Input for the bash from the Terminal.app is usually in NFC. This results in problems. The German Direcory name "Bücher" (Buecher/Books): 1. Bash completion does not work Bü -> Nothing Bu -> Works (glob and Bu* work in the same way) 2. if \w is included in $PS1 the display length is calculated wrong so when using the arrow-keys to recall the history the display is disrupted 3. when an argument is Completeted (Bu -> Bücher) the argument is in NFD. Deleting the argument results in wrong cursor position The problem is that there is no way using standard interfaces to distinguish or convert between the two forms on Mac OS X, at least none that I have found (and I've been looking at this for some time). I'm not particularly interested in using Mac OS-specific APIs; I have no experience with them. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Bash crashes on wildcards
[EMAIL PROTECTED] wrote:
Configuration Information [Automatically generated, do not change]:
Machine: alpha
OS: netbsd
Compiler: cc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='alpha'
-DCONF_OSTYPE='netbsd' -DCONF_MACHTYPE='alpha--netbsd' -DCONF_VENDOR=''
-DLOCALEDIR='/usr/pkg/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H
-I. -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE=/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin -I/usr/include
-O2 -mieee -I/usr/include
uname output: NetBSD faeroes 3.1.1_PATCH NetBSD 3.1.1_PATCH (sdf) #0: Mon Jul
2 15:57:43 UTC 2007 [EMAIL PROTECTED]:/var/netbsd/arch/alpha/compile/sdf alpha
Machine Type: alpha--netbsd
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
On newer versions of NetBSD (seemingly anything v.3 or above), attempts
to use any of the wildcards '*', '?', and '[' ... ']' (though not '{' ... '}')
result in bash suddenly terminating & creating a core image, having received
"signal 12." This happens regardless of the number of matches and regardless
of whether there are any matches at all. Interestingly, if the 'failglob'
option is set, bash prints a message about being unable to find any matches
(even if there were matches) before terminating. This bug has only been
observed in the version of bash specified above.
Sorry, I can't reproduce this on any of my systems.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: tab completion at empty prompt and vi mode
blehamiga wrote: With 'set autolist=ambiguous' in tcsh, if I'm at an empty prompt and I hit tab, it essentially does an ls on the directory. If I hit tab at an empty prompt in bash, it tries to complete all available commands instead. I've set up these already: That's how bash through bash-3.2 behaves. The next version will have a facility to set the completion for `empty' commands. Secondly, I prefer bindkey -v in tcsh, or set -o vi (and editing-mode/keymap) in bash. There's a difference though in that if I scroll through history, tcsh defaults to command mode, and bash defaults to insert mode. Not a major problem but I'm wondering if there's something I missed that would get bash to default to command mode so I don't have to re-learn habits. I assume you mean using the arrow keys. If you start in insert mode when using the arrow keys to go forward and backward in the history list, bash leaves you there. If you're in command mode, you stay in command mode. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
