On 6.8. 22:45, Chet Ramey wrote:
Yes. Bash has done this since its earliest days. A word that looks like an
assignment statement has tilde expansion performed after unquoted =~ and :~
no matter where it appears on the command line.
Given that options starting with a double-dashes
A few more problematic test cases in this vein (tested against latest
devel snapshot 20180803).
f() { local -n ref=var; local -A ref=([1]=); ref=([2]=); declare -p ref var; }
unset ref var; f
# declare -An ref=()
# declare -A var=([1]="" )
declare -p ref
# declare -a ref=([2]="")
unset ref;
I don't know if this makes consistency easier or harder, but there is
currently code to handle `declare' with -[iluc] early [1]. As a result, a
combination of localvar_inherit and the use of one of those options when
declaring a local variable allows (correctly or not) for associative arrays
to
Chet Ramey wrote:
> Hi. I am considering making bash glob expansion implement rational range
> interpretation starting with bash-5.0 -- basically making globasciiranges
> the default. It looks like glibc is going to do this for version 2.28 (at
> least for a-z, A-Z, and 0-9), and other GNU
On 08/06/2018 03:07 PM, Chet Ramey wrote:
Hi. I am considering making bash glob expansion implement rational range
interpretation starting with bash-5.0 -- basically making globasciiranges
the default. It looks like glibc is going to do this for version 2.28 (at
least for a-z, A-Z, and 0-9), and
Hi. I am considering making bash glob expansion implement rational range
interpretation starting with bash-5.0 -- basically making globasciiranges
the default. It looks like glibc is going to do this for version 2.28 (at
least for a-z, A-Z, and 0-9), and other GNU utilities have done it for some
> On 2018 Aug 6 , at 3:45 p, Chet Ramey wrote:
>
> On 8/6/18 3:09 PM, Clint Hepner wrote:
>
>> Bash Version: 4.4
>> Patch Level: 19
>> Release Status: release
>>
>> Description:
>>A non-initial unquoted tilde is expanded outside of an assignment.
>> This
>>was raised as a
On 8/6/18 3:09 PM, Clint Hepner wrote:
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> A non-initial unquoted tilde is expanded outside of an assignment.
> This
> was raised as a question on Stack Overflow,
>
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin16.7.0
Compiler: clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='d\
arwin16.7.0' -DCONF_MACHTYPE='x86_64-apple-darwin16.7.0' -DCONF_VENDOR='apple' \
> Find attached details regarding bash brace issues. King regards.
What exactly is it that you think you've found?
You have assignment statements preceding a command that is one component
of a compound command.
You might have a case that in the first three statements bash should
throw an error
On 8/6/18 12:13 PM, Pierre Gaston wrote:
> On Mon, Aug 6, 2018 at 4:32 PM, martins dada
> wrote:
>
>> Find attached details regarding bash brace issues. King regards.
>>
>
> you are simply assigning (){ to a temporary environment before running the
> command
>
> $ n=(){ bash -c 'echo $n'
>
On Mon, Aug 6, 2018 at 4:32 PM, martins dada
wrote:
> Find attached details regarding bash brace issues. King regards.
>
you are simply assigning (){ to a temporary environment before running the
command
$ n=(){ bash -c 'echo $n'
(){
just like:
a=foo bash -c 'echo $a'
I'd agree that I
Find attached details regarding bash brace issues. King regards.
bash
Description: Binary data
On 8/6/18 9:37 AM, Hugo Gabriel Eyherabide wrote:
> Bash Version: 4.4
> Patch Level: 18
> Release Status: release
>
> Description:
>
> Rebinding forward-search-history through
> bind '"\er": forward-search-history'
> does trigger the function, but not incrementally as \C-s does (when pressed
>
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'
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'
On Mon, Aug 06, 2018 at 04:14:49PM +0530, anant garg wrote:
> $ mode=!
> $ [ "$mode" != "ro" -a "$mode" != "rw" ] && echo OK
> + '[' '!' '!=' ro -a '!' '!=' rw ']'
> bash: [: too many arguments
The use of -a and -o as conjunctions inside a test or [ command is to
be avoided. It's not POSIX
Hi ,
I am using the below environment.
Linux kernel :- kernel-2.6.32-504.16.2.el6.x86_64
Bash version :- bash-4.1.2-29.x86_64
In our production code, one test related to parameter validation failed as
below :-
$ mode=!
$ [ "$mode" != "ro" -a "$mode" != "rw" ] && echo OK
+ '[' '!' '!=' ro -a
Using bind -x to call cd or source a script that changes the directory
will not update the prompt to show the new directory after the script
finished:
user@host:~$ bind -x '"\C-t": "echo test;cd /"'
# I press Ctrl-T
test
user@host:~$
Prompt still shows ~ as the pwd. Once I press Return or
19 matches
Mail list logo
