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

[Mihail Konev]

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?

[Robert Durkacz]

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 normally if file.c is the newer file but do nothing
if file.o is newer.

Then you would have a deterministic script to build a system that simply
skipped steps determined to be unnecessary.

It is possible to achieve this without changing bash but it seems like
there would be leverage in having bash deliberately support this mode.

[PATCH] Readline not being able to handle long lines

[Mihail Konev]

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' \
 -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL \
 -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
  Note on CFLAGS: -DNO_MULTIBYTE_SUPPORT=1 helps.
  But then I cannot use anything non-ASCII :)
uname output: Irrelevant (see OS)
Machine Type: Irrelevant (see OS)

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
Readline is unable to handle long lines.
This was introduced in bash 3.2.0.
Didn't check the readline, through.
Maybe just updating would help.

Repeat-By:
git checkout 0628567a28f3510f506ae46cb9b24b73a6d2dc5d
git clean -dfx
./configure --enable-multibyte
make
./bash
export PS1='[bash]$ '
#
# Now begin typing. On 40-th character, typing Home
# would no longer succeed, instead moving cursor somewhere in
# the middle of the line.
# And then you cannot do End either.
# This is verified to be pure displaying issue - you can use
# editing keys and they would affect the command line.
# But display would be just-broken.
#
export PS1='[bash123]$ '
#
# Now it would happen on 53-th character
#
export PS1='[bash1234567890]$ '
#
# Now it would happen on 65-th character
#

Fix:
Maintainer side:
1. Please Use Git Submodules For Things Like lib/readline.
   'git bisect' would then result in 10-20 lines diff, not 4
   lines one with *unrelated* changes.
2. Please Use Git Commits For Every Small Self-Contained Change.
3. For Versioning Releases, Please Use Git Tags.
   Git Branches Are Also Ok.

It is **pure luck** I was able to do that (thanks to change
being on top of the file).

Even after I constrained the diff to lib/readline, it still
constituted 2000 lines.

Unfixedness of *this* for **ELEVEN** years is a **shame** for bash as a
program with which a **lot** of people interact *every* day.

The same also applies for Readline.

To clarify: ANY git user has very little respect to both
projects for how do they break 'git bisect'.

Oh, and one more: I just found the 'devel' branch.

Big thanks for it NOT being the master !!!

And still, git bisect would fail very short with this
"development" branch.

Also, "git commit" is really meant to have a *description*, not
a *revision* or *date*; for versioning, Git Tags are meant.

I am happy bash do not contain any more serious bugs.
Also, from now on, I would have troubles capitalizing the
program's name.

---
 lib/readline/display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/readline/display.c b/lib/readline/display.c
index 47ff06159747..690f9f9b1ef3 100644
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -78,7 +78,11 @@ static int inv_lbsize, vis_lbsize;
 /* Heuristic used to decide whether it is faster to move from CUR to NEW
by backing up or outputting a carriage return and moving forward.  CUR
and NEW are either both buffer positions or absolute screen positions. */
-#define CR_FASTER(new, cur) (((new) + 1) < ((cur) - (new)))
+#if defined (HANDLE_MULTIBYTE)
+#  define CR_FASTER(new, cur) 0
+#else
+#  define CR_FASTER(new, cur) (((new) + 1) < ((cur) - (new)))
+#endif
 
 /* _rl_last_c_pos is an absolute cursor position in multibyte locales and a
buffer index in others.  This macro is used when deciding whether the
-- 
2.9.2

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

[L A Walsh]

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 
tilde, looks to me like the normal "get the home directory for the 
following id" .


Does ~ get home dirs for UID's?  I thought it only worked
for usernames?  I would think that allowing user names that were
all numeric would be confusing for software that accept either UID's or
usernames.  Can usernames even begin with a number?

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

[Eduardo Bustamante]

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
dash -1
posh -1

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

[John McKown]

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
the normal "get the home directory for the following id" processing. Eg: ~0
gets the home for the 0 user (same as ~user) whereas in "a~0", then tilde
is simply a character. This is basically how ever other Bourne type shell
seems to work.

On Sun, Nov 27, 2016 at 2:33 PM, Bize Ma  wrote:

> 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/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 5
> Release Status: release
>
> Description:
>   The ~ operator is called not, and does a one's complement of the
> following value. That works correctly with
>
>$ echo $(( ~1 ))
>-2
>
> Even with
>
>$ echo $(( ~0 ))
>-1
>
> But fails with this:
>
>$ echo $((~0))
>bash: /home/user: syntax error: operand expected (error token is
> "/home/user")
>
>
>
> Repeat-By:
>
>   Use $((~0)) (without spaces) to generate the error.
>



-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

Re: bashbug install mode

[L A Walsh]

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" to be installed w/o write permissions
by "default", since, if the user *really* wants to delete it, they
can -- but the -w would at least give them a pause and they might
remember that it belongs to 'bash'.

However, I don't really see why those should be enforced for bashbug
when bash is regularly installed u+w.
  

---
   Now that, to me, is a bit odd.

   Looking at the makefile,  there are two installmode
constants -- w/installmode being 755 and installmode2 being 555.

   They are only used for 'bash' and 'bashbug' respectively.

   Weird.  I would have thought 555 for installing both would
be used.  FWIW, in the build dir, both are 775, which likely
has to do with my umask settings (002), as I manage permissions
more by group than by user.

I've also heard of SELinux issues with u+w executables. However, I'm
not aware if they're specific to binary executables or apply to
interpreted scripts as well.
  

---
   Well, technically, most modern cpus have the NX bit for
memory permissions, and except for special-need programs, areas
of memory that are RW *default* to not being executable.  So
settings of 'rwx' are inconsistent with the memory access.

It, also, might be argued, though, that for binaries, executables
are more often protected by utilities that create executables
(e.g. executables are not usually updated in place).  Whereas
it is, "more often", the case that text-based files (that may be
'executable') are updated, in-place, by more text-editing
applications.  Also, technically, "scripts" don't need to be
executable to be run -- only to have the kernel automatically
look at the 1st line for automatic invocation of an interpreter.
But one can always put the interpreter 1st, followed by the
scriptname and that will usually execute the script even if it
doesn't have the exec-bit set.

Not operator (~) fail on arithmetic expansion.

[Bize Ma]

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/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 5
Release Status: release

Description:
  The ~ operator is called not, and does a one's complement of the
following value. That works correctly with

   $ echo $(( ~1 ))
   -2

Even with

   $ echo $(( ~0 ))
   -1

But fails with this:

   $ echo $((~0))
   bash: /home/user: syntax error: operand expected (error token is
"/home/user")



Repeat-By:

  Use $((~0)) (without spaces) to generate the error.

Re: here-documents in $(command) substitution

[Reuti]

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 as a single word that begins
> after the next  and continues until there is a line
> containing only the delimiter and a , with no 
> characters in between. Then the next here-document starts, if there is
> one. [...]
> 
>[n]delimiter
> 
> Delimiter (in your case the three character string "EOF"), has to be
> on its own line, with no leading or trailing blanks (or any other
> characters). If bash 3.x used to behave different, it's because it was
> buggy.
> 
> Hence, the proper way to do a here-document inside command substitution:

My understanding was that he is referring to the strange behavior in case of a 
malformed syntax. Why is "baz" output at all then?

-- Reuti


> 
>hp% cat hd
>export foo=$(cat EOF
>)
>echo baz
>hp% bash hd
>baz
> 

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

[Eduardo Bustamante]

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 of things here though:

1. The error is a non-fatal error
2. It is indeed an error to attempt to perform indirection on an empty
or unset parameter. There is no good reason to revert the fix,
considering that you were relying on unspecified behavior.

Re: here-documents in $(command) substitution

[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 as a single word that begins
after the next  and continues until there is a line
containing only the delimiter and a , with no 
characters in between. Then the next here-document starts, if there is
one. [...]

[n]<

[Bash 4.4.5] Variable indirection, error on empty variable

[Otenba]

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./lib -D_FORTIFY_SOURCE=2 
-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' 
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' 
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -Wno-parentheses -Wno-format-security
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.4
Patch Level: 5
Release Status: release

Description:
Performing variable indirection using an empty value causes an error. It didn't 
in Bash 4.3.

Repeat-By:
$ reference=1
$ echo ${!indirect} #variable indirection using an unset variable

$ indirect=reference
$ echo ${!indirect} #variable indirection to a variable name
1
$ indirect=
$ echo ${!indirect} #variable indirection using an empty variable
-bash: : bad substitution

The expected behavior is that the result of an indirection be the same whether 
the indirect variable is empty or unset.

here-documents in $(command) substitution

[Alexey Tourbin]

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' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -pipe
-march=native -Wall -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux celery 4.1.17-std-def-alt1 #1 SMP Tue Feb 2
12:43:38 UTC 2016 x86_64 GNU/Linux
Machine Type: x86_64-alt-linux-gnu

Bash Version: 4.4
Patch Level: 0
Release Status: release

Description:
Handling of here-documents in command substitution seems to be inconsistent.

$ cat test.sh
export foo=$(cat <

Nonterminating alias

[Dan Douglas]

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 I'm supposed to look at this.

bashbug install mode

[Michał Górny]

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 example, the user
can't write to the file directly without adding u+w. rm will request
additional confirmation for removal, and vim will default to opening
the file read-only.

However, I don't really see why those should be enforced for bashbug
when bash is regularly installed u+w.

I've also heard of SELinux issues with u+w executables. However, I'm
not aware if they're specific to binary executables or apply to
interpreted scripts as well.

-- 
Best regards,
Michał Górny



pgpJR4AO9gENI.pgp
Description: OpenPGP digital signature