On 3/4/2019 4:53 PM, Chet Ramey wrote:
> On 3/4/19 6:44 PM, L A Walsh wrote:
>
>
>>> What does `trace' mean here?
>>>
>> ---
>> from the manpage:
>> "output generated when set -x is enabled"
>>
>
> OK. We've only been talking about function tracing to this point. There
> are
The changes in [1] to parameter_brace_expand_rhs (for the fix for [2])
created (exposed?) an issue with ${var=$*} expansion when $* is
multiple nulls and IFS is unset:
$ unset -v IFS v; set -- '' ''; printf '<%q>' ${v=$*}
<$'\177'><$'\177'>
Uncommmenting the itrace lines shows:
TRACE
On 3/4/19 6:44 PM, L A Walsh wrote:
>> What does `trace' mean here?
> ---
> from the manpage:
> "output generated when set -x is enabled"
OK. We've only been talking about function tracing to this point. There
are several uses for the word, depending on context.
> FWIW, the other day, I a
On 3/4/2019 6:16 AM, Chet Ramey wrote:
> On 3/3/19 9:53 PM, L A Walsh wrote:
>
>> In bash 4.4.12, if I have some 'library' like functions that I
>> read in at login time, and then later call them -- under trace
>> or under bashdb, no source is shown, as bashdb (and for trace, bash)
>> doesn't
On 3/4/2019 5:16 AM, Greg Wooledge wrote:
> On Sat, Mar 02, 2019 at 08:47:43PM -0800, L A Walsh wrote:
>
>> hb=~law/bin (line#4)
>>
>
> Well, that's just a syntax error.
>
---
Sorry, the '(line#4)' was editorial commenting (vs. actual commenting)
>
>> if ! [[ $hb =~ $PATH ]]; then exp
Since the changes in [1], there's an issue with CTLNUL leakage in
${param=word} when word has null strings, like:
$ unset v; printf '<%q>' ${v= ''}
<$'\177'>
I think this can be addressed with:
diff --git a/subst.c b/subst.c
index 4962d2f5..58d33996 100644
--- a/subst.c
+++ b/subst.c
@@
On Sun, Mar 3, 2019 at 9:56 PM L A Walsh wrote:
> The first I will call 'lib.sh' that is sourced from my
> /etc/profile
[snip]
> declare -fxr addnums
[snip]
> ---'prog.sh'---
> #!/bin/bash
> # prog: calls addnums on each line read from stdin
> while read ln; do
> addnums $ln
> done
> ---
On 3/3/19 11:53 AM, Martin Schulte wrote:
> Hello,
>
> with "GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)" I get
> the following behaviour:
>
> + bash -c 'set -o nounset; echo $x'
> bash: x: unbound variable
> + bash -c 'set -o nounset; echo ${x}'
> bash: x: unbound variable
> + bash
On 3/2/19 11:47 PM, L A Walsh wrote:
> include 0 environment it prints the same wrong
> information
> -- as the BASH_SOURCE+LINENO
> variables.
>
> include is NOT defined in a file called 'environment' and the 1st
> line of a fi
On 3/2/19 11:47 PM, L A Walsh wrote:
>> You can get the file
>> and line number where the function is defined when extdebug is on, even if
>> you turn it on after the session has begun, and go from there.
>>
>
> Unfortunately, I can confirm that this DOES NOT WORK.
Sure it does.
>
On 3/3/19 9:53 PM, L A Walsh wrote:
> In bash 4.4.12, if I have some 'library' like functions that I
> read in at login time, and then later call them -- under trace
> or under bashdb, no source is shown, as bashdb (and for trace, bash)
> doesn't seem to be able to retrieve the original source file
On 3/4/19 8:19 AM, wer...@suse.de wrote:
> Bash Version: 5.0
> Patch Level: 2
> Release Status: release
>
> Description:
> Since patch bash50-001 there is a regession on path expansion.
> The script example below shows:
>
> bash/bash> bash tmp/bug.sh
> 5.0.2(1)-releas
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -fmessage-length=0 -grecord-gcc-switches -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection
On Sat, Mar 02, 2019 at 08:47:43PM -0800, L A Walsh wrote:
> hb=~law/bin (line#4)
Well, that's just a syntax error.
> if ! [[ $hb =~ $PATH ]]; then export PATH="$hb:$hl:$PATH"; fi
What is the logic behind that regex check? It looks completely wrong.
If the intent of this code is "check whether
14 matches
Mail list logo
