Re: 'fc' outputing text of DEBUG trap
On 2017-10-28 15:40, Chet Ramey wrote: > On 10/27/17 10:53 AM, Eduardo Bustamante wrote: > > On Fri, Oct 27, 2017 at 1:21 AM, Boruch Baum wrote: > >> In Debian, using Bash version 4.4, path level 12, I've set a DEBUG trap > >> in my .bashrc and tried running the following command, with the > >> following output resulting. The five lines between the command being run > >> by fc and that command's output, is the text of the DEBUG trap. > > > > Here's a short reproducer: @Eduardo: thanks. > Bash enables the verbose option while running the commands `fc' specifies > for executiont, since the historical practice is to echo the commands before > they get executed. Bash doesn't turn off the verbose option while running > trap commands (though it could; ksh93 does), so the trap commands get > echoed as well. @Chet: Is there a way to optionally turn off the verbose option for traps when running 'fc'? Toggling the verbose option from the command line only makes things more verbose for me (it echoes $PROMPT_COMMAND). For me, the desirable behavior would be for the default to inherit the behavior from outside the 'fc' command, with the exception that the actual lines being executed by 'fc' be always echoed. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: Documentation issue
On Mon, Oct 30, 2017 at 12:05:51AM -0400, Eli Barzilay wrote: > Again, `unset` has different expectations, because it seems like it > would be a special construct Only to you, and only because you brought in some expectations from a different language. > -- since it's dealing with *lvalues*. wooledg:~$ man bash | grep -i lvalue wooledg:~$ Concepts from other languages do not work the same way in bash. Here's a paragraph from bash(1): The unset builtin is used to destroy arrays. unset name[subscript] destroys the array element at index subscript. Negative subscripts to indexed arrays are interpreted as described above. Care must be taken to avoid unwanted side effects caused by pathname expansion. unset name, where name is an array, or unset name[subscript], where subscript is * or @, removes the entire array. This has two unquoted instances of name[subscript]. You could put quotes around those to provide better examples. (The man page as a whole is quite short on examples.)
Re: remove empty '' in ${var@Q} result?
On Mon, Oct 30, 2017 at 10:34:47AM +0800, Clark Wang wrote:
> See following example:
>
> [STEP 100] # echo $BASH_VERSION
> 4.4.12(2)-release
> [STEP 101] # v=\'\'
> [STEP 102] # printf '%q\n' "$v"
> \'\'
> [STEP 103] # printf '%s\n' "${v@Q}"
> ''\'''\'''
> [STEP 104] #
What's the bug? They are equivalent.
If you mean "I would like bash to perform a second optimization pass
over the result of ${var@Q} so that it's prettier in my degenerate edge
cases", I suspect there are better uses of Chet's time, but it's his call.
Re: 'fc' outputing text of DEBUG trap
On 10/30/17 8:06 AM, Boruch Baum wrote: > Is there a way to optionally turn off the verbose option for traps when > running 'fc'? Toggling the verbose option from the command line only > makes things more verbose for me (it echoes $PROMPT_COMMAND). > > For me, the desirable behavior would be for the default to inherit the > behavior from outside the 'fc' command, with the exception that the > actual lines being executed by 'fc' be always echoed. Well, there's the rub. The way to get the lines executed by fc is to turn on verbose mode. The way to get around it is to turn off verbose mode when executing traps, or at least the DEBUG trap, as ksh93 does, for instance. I don't know how many people, if any, are relying on the current behavior. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ${var@Q}: don't quote unless necessary?
On 10/29/17 10:48 PM, Clark Wang wrote:
> See following example:
>
> [STEP 100] # echo $BASH_VERSION
> 4.4.12(2)-release
> [STEP 101] # v=abc
> [STEP 102] # printf '%q\n' $v
> abc
> [STEP 103] # printf '%s\n' "${v@Q}"
> 'abc'
> [STEP 104] #
>
> Is it possible to not quote the result since there's no special chars in
> the string? I would expect ${var@Q} to produce more concise result compared
> to `printf %q' since it's the new syntax. :)
The ${var@Q} syntax always quotes; that's why it exists in the first place.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: remove empty '' in ${var@Q} result?
On 10/29/17 10:34 PM, Clark Wang wrote:
> See following example:
>
> [STEP 100] # echo $BASH_VERSION
> 4.4.12(2)-release
> [STEP 101] # v=\'\'
> [STEP 102] # printf '%q\n' "$v"
> \'\'
> [STEP 103] # printf '%s\n' "${v@Q}"
> ''\'''\'''
> [STEP 104] #
This is an effect of using single quotes in the @Q operator. If you want
to single-quote a string containing single quotes, this is how you do it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Unexpanded tilde in DIRSTACK[0]
On 10/29/17 8:05 PM, Steve Jones wrote:
> While writing a function to save the directory stack as a script, I
> noticed that ${DIRSTACK[0]}, the current directory always has the tilde
> unexpanded.
>
> This is the same with bash-4.4.12 and bash-4.3.11.
>
> I was wondering if this is an oversight since DIRSTACK[0] is the same as
> PWD, or intentional.
It's an oversight. It should be expanded, because otherwise the tilde
won't be expanded in something like `cd ${DIRSTACK[0]}', causing it to
fail. I'll fix it. Thanks for pointing this out.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Can't get debug info for functions with '[' in the name
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-musl
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-musl' -DCONF_MACHTYPE='x86_64-pc-linux-musl'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale'
-DPACKAGE='bash' -DSHELL
uname output: Linux 2275e25ecf5a 4.11.12-200.fc25.x86_64 #1 SMP Fri
Jul 21 16:41:43 UTC 2017 x86_64 Linux
Machine Type: x86_64-pc-linux-musl
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
declare -F fails if function name contains '[', even if it exists.
This makes it impossible to get the line number and file for such
functions, as it is only available via declare -F (*without* -p).
This bug appears to be in all versions of bash that have arrays
enabled; in 3.2 it just fails silently, without an error message.
Repeat-By:
shopt -s extdebug; declare -F some[name]
Fix:
In builtins/declare.def, the strchr('[') should be &&'d with (flags_on
& att_function) == 0
Re: Can't get debug info for functions with '[' in the name
On 10/30/17 2:56 PM, PJ Eby wrote:
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
> declare -F fails if function name contains '[', even if it exists.
> This makes it impossible to get the line number and file for such
> functions, as it is only available via declare -F (*without* -p).
> This bug appears to be in all versions of bash that have arrays
> enabled; in 3.2 it just fails silently, without an error message.
>
> Repeat-By:
> shopt -s extdebug; declare -F some[name]
>
> Fix:
> In builtins/declare.def, the strchr('[') should be &&'d with (flags_on
> & att_function) == 0
Thanks for the report; good catch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
