> On Sun, Jan 27, 2019 at 6:14 PM Chet Ramey wrote:
>
> > I prefer this behavior, at least to the extent that the function name
> argument to -F can't contain any shell metacharacters.
>
But it can, and that's the problem. E.g.:
$ complete -F 'meta;char' -- cmd
yields no errors. `complete` is
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local
/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bi
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'
conclude that FUNCNAME[0] is empty and other times that
FUNCNAME[*] is empty, under seemingly arbitrary circumstances? I can't
figure out what could be causing that.
On Thu, Nov 8, 2018 at 9:57 AM Chet Ramey wrote:
> On 11/8/18 1:15 AM, Great Big Dot wrote:
>
> > Bash Version: 4.4
&
nsistency is still there!
On Thu, Nov 8, 2018 at 8:28 AM Greg Wooledge wrote:
> On Thu, Nov 08, 2018 at 01:15:56AM -0500, Great Big Dot wrote:
> > Description:
> > The builtin array variable FUNCNAME (which provides a way to trace the
> > stack of functions called so
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'
Crap, looks like I accidentally just replied to a single person instead of
the whole list. Here it is (and sorry if I'm uselessly cluttering up
everyone's inboxes!):
-- Forwarded message -----
From: Great Big Dot
Date: Tue, Nov 6, 2018 at 5:45 PM
Subject: Re: Indice
On 11/5/18 8:44 PM, Great Big Dot wrote:
> > What's actually happening here is that the *indirection* expansion
> > "${!foo}", and not the *indices* expansion "${!foo[@]}", is what is being
> > preformed on something like "${!array[@]-}". Bo
> On Mon, Nov 5, 2018 at 4:56 PM Great Big Dot
wrote:
> [... A]ccessing the index list of multiple-element arrays
> fails when you append the unset expansion. With single-element
> arrays, it fails iff the element in question contains any special
> characters or whitespace, and t
On Mon, Nov 5, 2018 at 4:56 PM Great Big Dot wrote:
> The parameter expansion "${!var[@]}" expands to the indices of an array
(whether linear or associative).
Hold up... when I view this email on the public archives, all of my
"${array[@]}"'s (that is, "${ar
uname output: Linux ArchBox0 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20
22:06:45 UTC 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 23
Release Status: release
--text follows this line--
Description:
The parameter expansion "${!var[@]}" expan
11 matches
Mail list logo
