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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
On Fri, Jul 27, 2018 at 12:26:06AM -0400, fr...@eec.com wrote:
> produce any output (making me think that declare(1)
> isn't being executed at all).
For the record, declare is a builtin, not an external command with a
man page in the (1) section, so writing "declare(1)" is extremely
mi
On Fri, Jul 27, 2018 at 12:26:06AM -0400, fr...@eec.com wrote:
> Repeat-By:
> $ cat <<__EOF__ >/tmp/bashbug.bash
> > function myfunc {
> > echo "Running..."
> > }
> > declare -fx myfunc
> > declare -p -F | grep "myfunc"
> > __EOF__
> $ source /tmp
On 7/27/18 7:00 AM, Hugo Gabriel Eyherabide wrote:
> Bash Version: 4.3
> Patch Level: 48
> Release Status: release
>
> Description:
> After reading the documentation in "help shopt" I attempted to set
> flags, for example, noclobber, by using "shopt -s noclobber", but got an
> error messa
Agreed. But the bash installation does create a man page for it, does it not?
So a command like, “man 1 declare” does work...? I always thought this was
somewhat incongruous.
--
Frank Edwards
Edwards & Edwards Consulting, LLC
Hours: 10A-6P ET
Phone: (813) 406-0604
Sent from my iPhone. No e
On Fri, Jul 27, 2018 at 10:44:49AM -0400, Frank wrote:
> Agreed. But the bash installation does create a man page for it, does it
> not? So a command like, “man 1 declare” does work...? I always thought this
> was somewhat incongruous.
Some Linux-based operating systems have a "builtins(1)" m
On 7/26/18 3:15 PM, Grisha Levit wrote:
> It seems that in general the array type is inherited just fine, there is an
> issue only in the case that:
>* the `A' attribute is inherited but not explicitly supplied
>* we are creating the local variable with the `declare' command
> (i.e. it
Hm. Strange. I will examine the environment for weirdness regarding BASH_ENV
or anything else that might be an issue. Given that it happens for me in both
the stock bash 4.2.46 and the locally built 4.4 (on CentOS 7.4), there must be
something common to both and thus external to the shell its
Thanks for your help; I found the problem.
It was a directory in my PATH that included another copy of the script by the
same name. I should have been using ./script_name when passing it to the
source command. I found this by placing set -x inside the script to see what
was going on and it ne
El viernes, 27 de julio de 2018, 17:20:41 (UTC+3), Chet Ramey escribió:
> On 7/27/18 7:00 AM, Hugo Gabriel Eyherabide wrote:
>
> > Bash Version: 4.3
> > Patch Level: 48
> > Release Status: release
> >
> > Description:
> > After reading the documentation in "help shopt" I attempted to set
Hi Chet,
I wonder if you can allow bash to have another syntax to allow simpler
declaration and/or definition of associative arrays. The changes
needed to have it done seem simple enough, and the only conflict it
makes is a scalar `var={...` assignment, which in my opinion is better
quoted to mak
13 matches
Mail list logo
