(Sorry the previous message lacked the declaration of var, it was an
asterisk obviously)
$ var=*
$ declare -A arr=([a]=b)
$ [[ -v arr['$var'] ]]; echo $?
1
$ declare -A arr=(['*']=x)
$ [[ -v arr['$var'] ]]; echo $?
0
---
xoxo iza
On 4/18/15, isabella parakiss wrote:
> On 4/17/15, Chet Ramey
On 4/17/15, Chet Ramey wrote:
> On 4/17/15 5:12 AM, isabella parakiss wrote:
>> I need to check if an element in an associative array is set. What's the
>> correct way to test it?
>
> If *any* element is set, or if a particular element is set?
>
>>
>>
>> $ declare -A arr=([x]=y); var=*
>> $ [[ -v
Hey Linda. I do remember that thread, and I apologize for my words.
I honestly try my best here. But it seems that I cannot reply to you without
offending you, so, to avoid further offenses I will not reply to any further
email from you in the future.
I'm sorry that I offended you, it was not my
Eduardo A. Bustamante López wrote:
Well, if your scripts are so simple, why use local functions at all?
---
Cleanliness, Hygiene...
You're
claiming we invent stuff to make your examples fail, but I don't know anyone
that writes such complex code for very simple tasks that can even b
Based on an idea from Dan Colascione:
https://sourceware.org/ml/cygwin/2010-11/msg00022.html
Usage: add this to your shell startup:
EXECIGNORE='*.so:*.so.*'
to cause TAB completion to ignore shared library files when crawling
the file system to look for executables.
Cygwin has been using a vari
Well, if your scripts are so simple, why use local functions at all? You're
claiming we invent stuff to make your examples fail, but I don't know anyone
that writes such complex code for very simple tasks that can even be done
without functions. So, the burden to prove these convoluted approaches a
Did some benchmarks, for the while true; do (:) & (:); done simple example
this goes from 215 to 313 iterations/s, and changes sys+user CPU from 152%
to 45%
Any long running bash script will tend to exhibit this issue --
On 4/15/15, 5:59 PM, "John Fremlin" wrote:
>Over time, a long running bash
Greg Wooledge wrote:
The problem is, ALL function definitions (and un-definitions) are global.
---
yeah...
If there was a "func" defined at the global scope, you've obliterated it.
I don't understand why you don't understand this.
---
I don't understand why you think I don't understa
On Fri, Apr 17, 2015 at 04:26:08PM -0400, Mike Frysinger wrote:
> please post patches inline and as a series rather than attaching a binary
> tarball. it makes review much harder when you do this.
>
> in fact, `git send-email` takes care of all of this for you.
> -mike
Makes sense, thanks! I'll
please post patches inline and as a series rather than attaching a binary
tarball. it makes review much harder when you do this.
in fact, `git send-email` takes care of all of this for you.
-mike
signature.asc
Description: Digital signature
On 02/06/2015 02:13 PM, Eric Blake wrote:
> Chet,
>
> I've noticed that your 'devel' branch in bash.git is rather messy;
> basically lots of commits that snapshot the state of a directory, then a
> followup commit that removes leftovers and stray files. If you were to
> set your .gitignore file (
On Fri, Apr 17, 2015 at 11:58:15AM -0700, Linda Walsh wrote:
> >outerfunc() {
> > func() { ...; }
> > func args
> > unset -f func
> >}
> >outerfunc
The problem is, ALL function definitions (and un-definitions) are global.
If there was a "func" defined at the global scope, you've obliterated it.
I
Eduardo A. Bustamante López wrote:
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
[...]
AFAIK, _exec_gvim, can only be called from within "function gvim", no?
No. Doing this:
outerfunc() {
func() { ...; }
func args
unset -f func
}
outerfunc
Doesn't guarantee that `func' wi
Greg Wooledge wrote:
AFAIK, _exec_gvim, can only be called from within "function gvim", no?
That is not correct. In bash, all function definitions are global.
imadev:~$ f1() { f2() { echo "I'm f2"; }; }; f1; f2
I'm f2
You left out a few important parts, like f2 being called inside f1
In the BSDs, doing a read on a directory doesn't return a negative value.
Bash assumes that you can't do reads on directories here:
1501 /* Only do this with non-tty file descriptors we can seek on. */
1502 if (fd_is_tty == 0 && (lseek (fd, 0L, 1) != -1))
1503 {
1504 /* Check to see
0001-Fix-spacing-issues-in-tests-to-make-it-easier-to-tra.patch
This one attempts to remove the false positives that the different spacing
output between od's causes. There's also a change for one of the unicode
tests, but I'm not sure about that one.
0002-Fix-unclosed-double-quote.patch
This
On 04/17/2015 11:42 AM, Eric Blake wrote:
> On 04/17/2015 11:38 AM, Eric Blake wrote:
>> On 04/17/2015 11:01 AM, Chet Ramey wrote:
>>> On 4/17/15 10:26 AM, Eric Blake wrote:
gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-unknown-li
On 04/17/2015 11:46 AM, Chet Ramey wrote:
> On 4/17/15 10:47 AM, Eric Blake wrote:
>> gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
>> -L./lib/tilde -L./lib/malloc -L./lib/sh -rdynamic -g -O2 -Wno-parentheses
>> -Wno-format-security -o bash shell.o eval.o y.tab.o general.o mak
On 04/17/2015 11:38 AM, Eric Blake wrote:
> On 04/17/2015 11:01 AM, Chet Ramey wrote:
>> On 4/17/15 10:26 AM, Eric Blake wrote:
>>> gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
>>> -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"'
>>> -DCONF_VENDOR='"unknown"' -DLOCAL
On 4/17/15 10:47 AM, Eric Blake wrote:
> gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde
> -L./lib/malloc -L./lib/sh -rdynamic -g -O2 -Wno-parentheses
> -Wno-format-security -o bash shell.o eval.o y.tab.o general.o make_cmd.o
> print_cmd.o dispose_cmd.o execute_c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/17/15 1:38 PM, Eric Blake wrote:
> On 04/17/2015 11:01 AM, Chet Ramey wrote:
>> On 4/17/15 10:26 AM, Eric Blake wrote:
>>> gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
>>> -DCONF_OSTYPE='"linux-gnu"'
>>> -DCONF_MACHTYPE='"x86_64-unknown-linu
On 04/17/2015 11:01 AM, Chet Ramey wrote:
> On 4/17/15 10:26 AM, Eric Blake wrote:
>> gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
>> -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"'
>> -DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/usr/local/share/locale"'
>> -DPACKAGE='
On 4/17/15 10:26 AM, Eric Blake wrote:
> gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
> -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"'
> -DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/usr/local/share/locale"'
> -DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H -DDEBUG -DMALLOC
On 4/17/15 9:10 AM, isabella parakiss wrote:
>
> Ok that kind of makes test -v useless, doesn't it?
No, not really.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.c
On 4/17/15 5:12 AM, isabella parakiss wrote:
> I need to check if an element in an associative array is set. What's the
> correct way to test it?
If *any* element is set, or if a particular element is set?
>
>
> $ declare -A arr=([x]=y); var=*
> $ [[ -v arr["$var"] ]]; echo $?
> 0
> $ [[ ${arr
I agree 100% with you here. I don't see the point of optimizing bash for
unrealistic cases.
--
Eduardo Bustamante
https://dualbus.me/
On 4/16/15 12:48 PM, Eduardo A. Bustamante López wrote:
> On Thu, Apr 16, 2015 at 11:07:34AM -0400, Chet Ramey wrote:
> [...]
>> I knew that rang a bell somewhere. mt_hash is a function in the bash
>> malloc library that keeps track of all allocations and deallocations in
>> a table. It's part of
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde
-L./lib/malloc -L./lib/sh -rdynamic -g -O2 -Wno-parentheses
-Wno-format-security -o bash shell.o eval.o y.tab.o general.o make_cmd.o
print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o
fla
gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"' -DCONF_OSTYPE='"linux-gnu"'
-DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"' -DCONF_VENDOR='"unknown"'
-DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I. -I. -I./include -I./lib -g -O2
-
On Fri, Apr 17, 2015 at 8:55 AM, Eduardo A. Bustamante López <
dual...@gmail.com> wrote:
> > Always quote your variables. The problem comes from
> >
> > echo $INPUT
> >
> > which should be
> >
> > echo $INPUT
>
> Someone derped. It *should* be
>
> echo "$INPUT"
>
> --
> Eduardo Bustamante
> https
> Always quote your variables. The problem comes from
>
> echo $INPUT
>
> which should be
>
> echo $INPUT
Someone derped. It *should* be
echo "$INPUT"
--
Eduardo Bustamante
https://dualbus.me/
This is not a bug.
This is due to not understanding two aspects of bash:
1) $arrname is the same as ${arrname[0]} (not the "first" element, as what you
seem to imply). Bash arrays are sparse, so you can define the element at
index 1, without having an element at 0.
2) unset and empty is not
> Ok that kind of makes test -v useless, doesn't it?
You might want to read:
https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
--
Eduardo Bustamante
https://dualbus.me/
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/b/home/share/locale' -DPACKAGE=
On Thu, Apr 16, 2015 at 6:51 PM, Guillermo Buritica Tobon <
gburitic...@gmail.com> wrote:
> Hi All.
>
> H have the next bash script code.:
>
> #!/bin/sh
> # Pring OK on empty input,
> # Print input on non-empty input
>
> read INPUT
> if [ -z "$INPUT" ]; then
> echo OK
> else
> echo
On 4/17/15, Eduardo A. Bustamante López wrote:
> On Fri, Apr 17, 2015 at 11:12:50AM +0200, isabella parakiss wrote:
>> I need to check if an element in an associative array is set. What's the
>> correct way to test it?
>
> dualbus@yaqui ~ % export key; for key in \* x y; do bash -c 'declare -A
>
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
[...]
> AFAIK, _exec_gvim, can only be called from within "function gvim", no?
No. Doing this:
outerfunc() {
func() { ...; }
func args
unset -f func
}
outerfunc
Doesn't guarantee that `func' will be only called from outerfunc. If yo
On Fri, Apr 17, 2015 at 11:12:50AM +0200, isabella parakiss wrote:
> I need to check if an element in an associative array is set. What's the
> correct way to test it?
dualbus@yaqui ~ % export key; for key in \* x y; do bash -c 'declare -A
a=([x]=y [y]=); echo "$key" ${a[$key]+inarray}; declare
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
> It's a trite example, but I do something like:
>
>
> sub gvim () {
> array orig_args=($@) gv_files=() gv_ops=()
> int use_tab=0 look_for_ops=1
>
>sub _exec_gvim() {
> array args
> ((use_tab)) && args=("-p")
> (
On Fri, Apr 17, 2015 at 09:51:04AM +1000, Guillermo Buritica Tobon wrote:
> H have the next bash script code.:
>
> #!/bin/sh
This is not bash. This is sh.
> read INPUT
Avoid using ALL-CAPS variable names. All-caps names are reserved for
internal shell variables, and environment variables like
I need to check if an element in an associative array is set. What's the
correct way to test it?
$ declare -A arr=([x]=y); var=*
$ [[ -v arr["$var"] ]]; echo $?
0
$ [[ ${arr["$var"]} ]]; echo $?
1
The former seems wrong, the glob is expanded even if "$var" is quoted.
The latter works but it do
41 matches
Mail list logo
