Incorrect handling of echo in POSIX mode

bar bash-5.2$ bash --posix -O xpg_echo -c 'echo -e foo\\nbar' -e foo bar -- Clint Hepner

Re: read and inconsistent handling of trailing null field?

> On 2020 Jan 29 , at 10:30 a, Chet Ramey wrote: > > On 1/29/20 10:19 AM, Clint Hepner wrote: > >> Bash Version: 5.0 >> Patch Level: 11 >> Release Status: release >> >> Description: >> >> read seems to incorrectly drop a null field w

read and inconsistent handling of trailing null field?

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin19.2.0 Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin hemma.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019;

Re: Two states of empty arrays

On Thu, Dec 12, 2019 at 1:10 PM Léa Gris wrote: > Hello, > > Depending on how an empty array is declared, it is not stored with the > same state. > > # Empty array declared without parenthesis > unset myArr > declare -a myArr > typeset -p myArr > echo "${#myArr[@]}" > > output: > declare -a

Re: man bash does not list 'in' as a builtin command

> On 2019 Nov 25 , at 4:43 p, Peter Benjamin wrote: > > > Description: > 'in' is a builtin command and is not listed in the man page as such. > > Repeat-By: > > type at the bash command line: > > $ in > bash: syntax error near unexpected token `in' This should be a big hint that it is

Re: [FR] save command times and exit status in history automatically

> On 2019 Nov 7 , at 3:18 p, Daniel Colascione wrote: > > On Thu, Nov 7, 2019 at 12:09 PM Chet Ramey wrote: >> >> On 11/5/19 12:49 PM, Daniel Colascione wrote: >>> Right now, bash history saves only the command line actually executed. >> >> This isn't quite the case. What it saves is the

Re: x[

> On 2019 Jul 29 , at 12:55 p, Isabella Bosia wrote: > > haven't really looked into why this happens but x[ seems to trigger some > funny parser behavior > > x[ newline should not prompt with PS2 > > it can't be defined as a normal sh function, but it can be defined with the > function

Re: Add sleep builtin

> On Aug 19, 2018, at 10:25 AM, konsolebox wrote: > > Hi Chet, > > The sleep command is often used in loops and using the external sleep > is expensive. Expensive is relative, as the time spent actually sleeping probably dwarfs the startup time. If not, you probably want to find an

Re: Tilde expansion in assignment-like context

> 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

Tilde expansion in assignment-like context

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' \

Re: [1] 69728 segmentation fault bash

lve the problem. See https://lists.gnu.org/archive/html/bug-bash/2017-09/msg00048.html. > > > freely, > Guillaume Madec > (+33)6 46 01 00 79 > > 2018-07-20 16:17 GMT+02:00 Clint Hepner : > > > On 2018 Jul 20 , at 9:27 a, Mr Guiguilebreton wrote: > > > >

Re: [1] 69728 segmentation fault bash

> On 2018 Jul 20 , at 9:27 a, Mr Guiguilebreton wrote: > > Hello, check this command in GNU bash, version 3.2.57(1)-release > (x86_64-apple-darwin17): > > ls () { ls -lG;}; ls You wrote a recursive function with no base case. Don't do that. ls () { command ls -lG; }; ls or use an alias

Re: Number with sign is read as octal despite a leading 10#

The + is a unary operator, not part of the literal. Write $((+10#0034)) instead. -- Clint On Jul 9, 2018, 9:24 PM -0400, Isaac Marcos , wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS:

Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal

> On 2018 Mar 23 , at 8:26 a, Greg Wooledge wrote: > > On Fri, Mar 23, 2018 at 12:36:22AM +0200, Ilkka Virta wrote: >> I get the same with '4.4.12(1)-release' too, but it doesn't seem related to >> Bash or the prompt. I can get it with just a printf, the colored part just

Re: Unset array doesn't work

> On 2018 Feb 26 , at 4:31 a, Robert Elz wrote: > >Date:Mon, 12 Feb 2018 09:26:37 -0500 >From:Chet Ramey >Message-ID: <790ade74-690f-541c-9ab4-635991744...@case.edu> > > | This is bash's dynamic scoping. The visibility of

Re: Enabling History Expansion with `set -H'.

> On 2018 Jan 21 , at 7:13 a, Ralph Corderoy wrote: > > Hi, > > Please keep me CC'd. > > bash package 4.4.012-2 on Arch Linux, > `version 4.4.12(1)-release (x86_64-unknown-linux-gnu)'. > > I'm trying to enable history expansion in a non-interactive bash with > `set

Re: Spaces trimmed from $* when assigned while IFS is unset [was: Unexpected word splitting on $* ...]

On Wed, Sep 27, 2017 at 9:10 AM, Martijn Dekker wrote: > Op 27-09-17 om 14:44 schreef Greg Wooledge: > > I'm just going to chalk this up as yet another example of unquoted $* > > or $@ being Completely Wrong. > > Nonsense. This is a bug in bash and it should be fixed, not

Execution of code by ${...@P}

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin16.0.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin16.0.0' -DCONF_MACHTYPE='x86_64-apple-darwin16.0.0' -DCONF_VENDOR='apple'

Word-splitting with here document?

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin13.4.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin13.4.0' -DCONF_MACHTYPE='x86_64-apple-darwin13.4.0' -DCONF_VENDOR='apple'

Inconsistent arithmetic evaluation of parameters

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin14.5.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin14.5.0' -DCONF_MACHTYPE='x86_64-apple-darwin14.5.0' -DCONF_VENDOR='apple'

Documentation for declare/typeset does not address +=

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin13.0.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin13.0.0' -DCONF_MACHTYPE='i386-apple-darwin13.0.0' -DCONF_VENDOR='apple'

read with parameter expansion in here string

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin13.0.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin13.0.0' -DCONF_MACHTYPE='i386-apple-darwin13.0\ .0' -DCONF_VENDOR='apple'

Re: read with parameter expansion in here string

On Nov 22, 2013, at 10:04 AM, Pierre Gaston pierre.gas...@gmail.com wrote: On Fri, Nov 22, 2013 at 4:22 PM, Clint Hepner cl...@renesys.com wrote: Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin13.0.0 Compiler: clang Compilation CFLAGS