Re: [PATCH] Readline not being able to handle long lines

Oh, and for lib/readline, Please Use Git Submodules. See: $ man git-tag $ man git-bisect $ man git-submodule

Could bash do what make does?

Has thought been given, over the years, to extending bash to do what make does, in the obvious way that I am about to describe? It would be a matter of having chosen build commands do nothing if their outputs are newer than their inputs. For example that is, cc file.c -o file.o should execute norm

[PATCH] Readline not being able to handle long lines

Configuration Information: OS: Happens both under Linux and MSYS2 (i.e. Cygwin), both 32 and 64 bit Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' \ -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' \

Re: Not operator (~) fail on arithmetic expansion.

John McKown wrote: Not replying for Chet, who will have the definitive answer, I will say that I, personally, think that is working as designed. ~ 0 (with space between) is definitely the "not" operator. But without the middle space, ~0, where there is a white space character in front of the

Re: Not operator (~) fail on arithmetic expansion.

Except that this is *inside* arithmetic context. Bash is definitely doing something wrong here: dualbus@hp:~$ for sh in bash zsh ksh93 mksh dash posh; do $sh -c 'echo $0 $((~0))' $sh; done bash: /home/dualbus: syntax error: operand expected (error token is "/home/dualbus") zsh -1 ksh93 -1 mksh -1

Re: Not operator (~) fail on arithmetic expansion.

Not replying for Chet, who will have the definitive answer, I will say that I, personally, think that is working as designed. ~ 0 (with space between) is definitely the "not" operator. But without the middle space, ~0, where there is a white space character in front of the tilde, looks to me like t

Re: bashbug install mode

Michał Górny wrote: Hi, While scanning our systems for executables that are installed u-w, I've noticed this specific mode is used for bashbug explicitly. Is there a good reason for doing that? --- Doesn't it have execute permission? But it seems semi normal for a system-"executable" t

Not operator (~) fail on arithmetic expansion.

Configuration Information: 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 uname output: Linux zeus 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Li

Re: here-documents in $(command) substitution

Am 27.11.2016 um 18:51 schrieb Eduardo Bustamante: > Hi Alexey, > > Please read the specification of here-documents in the standard: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04 > > Quoting the relevant parts: > >The here-document shall be treated

Re: [Bash 4.4.5] Variable indirection, error on empty variable

This change of behavior is the result of a bug fix for http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00058.html, introduced in the following commit http://git.savannah.gnu.org/cgit/bash.git/commit/?id=f2d7e1a3bcbdec7ef09db71779d800237fbc58bb (read the changelog in CWRU/CWRU.chlog) A couple

Re: here-documents in $(command) substitution

Hi Alexey, Please read the specification of here-documents in the standard: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04 Quoting the relevant parts: The here-document shall be treated as a single word that begins after the next and continues until th

[Bash 4.4.5] Variable indirection, error on empty variable

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' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./

here-documents in $(command) substitution

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-alt-linux-gnu' -DCONF_VENDOR='alt' -DLOCALEDIR='/usr/share/locale' -DPACKA

Nonterminating alias

A simpler one this time. Bash 4.4 only. $ bash -c $'alias @="eval {\n}"; eval @' bash: xrealloc: cannot allocate 18446744071562068464 bytes I would guess this is part of the way keywords are supposed to be re-interpolated after alias expansion since 4.4. Maybe not even be a bug depending on how

bashbug install mode

Hi, While scanning our systems for executables that are installed u-w, I've noticed this specific mode is used for bashbug explicitly. Is there a good reason for doing that? This normally doesn't cause any major issues, except for a few minor inconveniences when installed by a regular user. For e