Re: $IFS and "[EMAIL PROTECTED]:offset}"
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> The behavior is the same in ksh, but in ksh ${@:0:1} expands to
> $0 which makes it more understandable ($0 has its meaning in
> functions as well in ksh which makes it somehow consistent).
>
> In bash, ${@:0:1} and ${@:1:1} expand to the same thing ($1). Is
> all that documented (I couldn't find it via a quick scan of the
> man page)?
$@ expands to the positional parameters, which $0 is not (it is a
special parameter). Since index 0 does not exist, $1 is the first
counted parameter in the expansion.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: $IFS and "[EMAIL PROTECTED]:offset}"
On Fri, Jun 06, 2008 at 10:38:41AM +0200, Andreas Schwab wrote:
> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>
> > The behavior is the same in ksh, but in ksh ${@:0:1} expands to
> > $0 which makes it more understandable ($0 has its meaning in
> > functions as well in ksh which makes it somehow consistent).
> >
> > In bash, ${@:0:1} and ${@:1:1} expand to the same thing ($1). Is
> > all that documented (I couldn't find it via a quick scan of the
> > man page)?
>
> $@ expands to the positional parameters, which $0 is not (it is a
> special parameter). Since index 0 does not exist, $1 is the first
> counted parameter in the expansion.
[...]
You make me remember that I had forgotten that aspect of ksh and
bash arrays in that they are associative arrays (contrary to
zsh's) with keys being only positive of null integers.
${a[0]} is the element of key 0. [EMAIL PROTECTED]:0:1} is the first
element of the list of $a elements numerically sorted by their
keys. And [EMAIL PROTECTED]:1:1} is the second element.
It still doesn't explain why ${@:1:1} expands to $1 and not $2
(if we assume that $0 is not part of $@ which I agree).
--
Stéphane
Re: $IFS and "[EMAIL PROTECTED]:offset}"
On Thu, Jun 05, 2008 at 05:39:58PM +0100, Stephane Chazelas wrote:
[...]
> $ bash -c 'printf "%s\n" "${@:2}"' x 1 2 "3 4" 5
> 2
> 3 4
> 5
> $ bash -c 'IFS=a; printf "%s\n" "${@:2}"' 0 1 2 "3 4" 5
> 2 3 4 5
>
> I don't understand why $IFS would have any influence here. The
> behavior differs from ksh.
>
> It seems that you need to have " " in IFS or IFS being unset for
> it to work as I would expect.
[...]
It's the same for "${@//a/b}":
$ bash -c 'printf "<%s>\n" "${@//a/b}"' x a b c
$ bash -c 'IFS=a; printf "<%s>\n" "${@//a/b}"' x a
b c
--
Stéphane
Re: $IFS and "[EMAIL PROTECTED]:offset}"
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> It still doesn't explain why ${@:1:1} expands to $1 and not $2
For positional parameters indexing starts at 1.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: $IFS and "[EMAIL PROTECTED]:offset}"
On Fri, Jun 06, 2008 at 11:08:23AM +0200, Andreas Schwab wrote:
> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>
> > It still doesn't explain why ${@:1:1} expands to $1 and not $2
>
> For positional parameters indexing starts at 1.
[...]
Alright sorry, that was me being confused. I thought
[EMAIL PROTECTED]:n:1} was giving the (n+1)th element of the array
while it's not, it's giving the first element whose index if
greater or equal to n.
I thought
$ bash -c 'a[1664]=x a[51]=4 a[42]=1; echo "[EMAIL PROTECTED]:1:1}"'
would give "4" because in the sorted list of indexes (42, 51,
1664), 51 is the second.
While it gives "1" because "42" is the first element after "1".
Sorry for the bother,
Stéphane
Bash crashes on wildcards
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.
Repeat-By:
This bug can be observed simply by attemping to use one of the
wildcards in bash on a NetBSD system, v.3 or above. In the specific cases in
which this was observed, it happenened only on the 'faeroes' server of the SDF
Public Access UNIX System (http://sdf.lonestar.org). It is unknown whether
this problem is limited to NetBSD systems or even what exact versions it occurs
on.
eval, apparently inconsistent behavior
#!/bin/bash
a=( 1 2 3 )
b=( 4 5 6 )
x=a
eval b=( [EMAIL PROTECTED] )
echo [EMAIL PROTECTED]
#output:
#1 2 3
x=b
eval $x=( [EMAIL PROTECTED] )
#output:
#./tst: line 15: syntax error near unexpected token `('
#./tst: line 15: `eval $x=( [EMAIL PROTECTED] ) '
patch failures/offsets through bash32-039
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. Perhaps reroll the affected patches and fix any new failures/offsets introduced? Or issue patch 040 as a cumulative fix for those who never check their output? Thanks. PFILE: bash32-001 PFILE: bash32-002 PFILE: bash32-003 PFILE: bash32-004 PFILE: bash32-005 PFILE: bash32-006 PFILE: bash32-007 PFILE: bash32-008 PFILE: bash32-009 PFILE: bash32-010 PFILE: bash32-011 PFILE: bash32-012 PFILE: bash32-013 PFILE: bash32-014 PFILE: bash32-015 Hunk #1 succeeded at 4166 (offset 15 lines). Hunk #2 succeeded at 4221 (offset 15 lines). Hunk #3 succeeded at 4727 (offset 8 lines). PFILE: bash32-016 PFILE: bash32-017 PFILE: bash32-018 PFILE: bash32-019 Hunk #1 failed at 522. Hunk #2 failed at 529. Hunk #3 failed at 579. 3 out of 3 hunks failed--saving rejects to input.c.rej ERROR: 3 PFILE: bash32-020 PFILE: bash32-021 PFILE: bash32-022 PFILE: bash32-023 PFILE: bash32-024 PFILE: bash32-025 Hunk #1 failed at 134. Hunk #2 failed at 254. Hunk #3 failed at 378. 3 out of 3 hunks failed--saving rejects to input.c.rej ERROR: 3 PFILE: bash32-026 PFILE: bash32-027 PFILE: bash32-028 PFILE: bash32-029 PFILE: bash32-030 PFILE: bash32-031 Hunk #1 succeeded at 1623 (offset 4 lines). PFILE: bash32-032 Hunk #1 failed at 155. 1 out of 1 hunks failed--saving rejects to input.c.rej ERROR: 1 PFILE: bash32-033 PFILE: bash32-034 PFILE: bash32-035 PFILE: bash32-036 PFILE: bash32-037 PFILE: bash32-038 PFILE: bash32-039 Hunk #1 succeeded at 3607 (offset -454 lines).
read -d on a terminal
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux ant 2.6.24.2 #2 Tue Apr 22 09:55:40 BST 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: Hiya, is there a way to tell bash *not* to change the termios setting when using read -d when the fd is a terminal? I tried read -u0 -d x var # as in zsh's read -u0 -k 10 read -u4 -d x var 4<&0 to no avail. I think it's not that much of a useful feature given that it can be implemented more nicely (i.e. the user can still use backspace, ...) with "stty eol" and standard read or dd, so it would be nice to be able to disable it. I'm not saying "read -d" is not useful, just that one may not want the extra undocumented behavior for terminal fds. Best regards, Stephane
Unicode Normalization on Mac OS X (HFS+ filesystem)
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 Repeat-By: Use the Standard Terminal.app [EMAIL PROTECTED]:/tmp $ echo Bücher | hd 42 c3 bc 63 68 65 72 0a |Bücher.| <-NFC 0008 [EMAIL PROTECTED]:/tmp $ mkdir Bücher | hd [EMAIL PROTECTED]:/tmp $ ls -d B* | hd 42 75 cc 88 63 68 65 72 0a | Bu?.cher.| <-NFD 0009 [EMAIL PROTECTED]:/tmp $ cd Bü* bash: cd: Bü*: No such file or directory [EMAIL PROTECTED]:/tmp $ cd Bu* [EMAIL PROTECTED]:/tmp/Bücher $ using the history: [EMAIL PROTECTED]:/tmp/Bücher $ [EMAIL PROTECTED]:/tmp/Büchrenampstree -s Ter [EMAIL PROTECTED]:/tmp/Bücher $ cd .. using backspace to delete the completed Filename: cd Bu -> the Cursor is one char left of its intended position smime.p7s Description: S/MIME cryptographic signature
tab completion at empty prompt and vi mode
I had two quick questions; I'm working on moving from tcsh and trying to replicate a bit of functionality I've grown used to. 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: bind "set completion-query-items 1000" bind "set show-all-if-ambiguous on" bind "set page-completions off" But that doesn't change the behavior of trying to complete commands instead of files at an empty prompt. I'm hoping I can do this with a "complete" command but I'm not sure what that's going to look like. Typically it'd be something like complete -o default -A file It's the end part that I don't know what to put if I'm just sitting at an empty prompt and hit TAB. 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. Thanks -- View this message in context: http://www.nabble.com/tab-completion-at-empty-prompt-and-vi-mode-tp17690480p17690480.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
