On Tue, Feb 21, 2023 at 11:03:59AM -0500, Chet Ramey wrote:
(...)
> The shell should exit on EOF. Previous versions relied on undocumented
> bison behavior, which resulted in a token that wasn't handled by the
> grammar.
Thank you for reviewing this and for the explanation. I initially thought
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux system76-pc 6.1.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.11-1
Signed-off-by: Eduardo A. Bustamante López
---
lib/readline/tcap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/readline/tcap.h b/lib/readline/tcap.h
index 1121061b..a9c6322a 100644
--- a/lib/readline/tcap.h
+++ b/lib/readline/tcap.h
@@ -51,7 +51,7 @@ extern int
On Fri, Jan 22, 2021 at 05:05:31AM +0100, Mathias Steiger wrote:
>
> Here is the strace output.
>
> https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd
>
> It is very excessive due to the nature of Autoconf and I couldn't make a lot
> of sense of it.
>
>
> When I downgraded the
On Sun, Jul 21, 2019 at 06:56:09PM -0400, Chet Ramey wrote:
(...)
> Thanks for the report. Look at match_wpattern and consider what happens if
> wmatchlen returns something longer than the string length. It will be fixed
> for the next devel branch push.
Aha! I see.
| Starting program:
Bash `devel' crashes under the following circumstances:
| dualbus@system76-pc:/tmp/build-bash-devel$ CFLAGS='-O0 -ggdb'
~/src/gnu/bash/configure --with-bash-malloc
| (...)
| dualbus@system76-pc:/tmp/build-bash-devel$ make -j$(nproc)
| (...)
| dualbus@system76-pc:/tmp/build-bash-devel$ ./bash -c
On Sat, May 25, 2019 at 02:56:43PM -0400, Richard Marmorstein wrote:
> There was discussion on Twitter today
> (https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
> Bash manual appears to not be indexable by search engines.
>
>
On Mon, Mar 18, 2019 at 05:18:10PM -0400, Daniel Kahn Gillmor wrote:
> hi bash developers--
(...)
> a) use socketpair(2) or pipe(2) instead of making a tmpfile. this has
> the potential downside that the semantics of access to the remaining
> file descriptor would be subtly different
On Sat, Feb 23, 2019 at 01:48:08AM +, Robert White wrote:
(...)
> Your syntax checker is straight tripping on that SC1036 error dude. Array
> assignment using ARRAYNAME=( expression ) is completely legal and correct
> with or without the eval. The structure even allows for line continuation
>
Commit `be4078d25ff3af268a6ef7ab56c8121f9a8dfb36' introduced the following
issue:
| dualbus@system76-pc:~/src/gnu/bash$ ./configure --silent
|
| Beginning configuration for bash-5.0-maint for x86_64-pc-linux-gnu
|
| ./configure: line 9614: gl_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER: command not
I found another issue in rl_do_undo, but I haven't been successful in figuring
out how it happens.
I've been working with the `devel' branch, commit
`8a9718cfc93958b34e205d0507c3bbf64cba6db5'
Here's how I built the binaries I use below:
debian@debian-fuzz:~/tmp$ cat ~/build.sh
#!/bin/bash
On Wed, Jan 23, 2019 at 03:59:12PM +, Shen Herbert wrote:
(...)
> Repeat-By:
> Run this script:
> ```
> set +T
> one { trap 'echo in one' RETURN; }
> all {
> trap 'echo in all' RETURN
> one
> }
> all
> ```
Hm, the script above is a bit odd, these aren't syntactically valid function
On Mon, Jan 21, 2019 at 09:26:59AM +0700, Robert Elz wrote:
(...)
> I think his point is that if unset "unset f" (no flags) works to unset
> function f, if f is not a (set) variable, then it should work every time
> "f" is not a set variable, not only the times when the word "f" happens
> to be
On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> On 1/20/19 4:54 PM, Chet Ramey wrote:
>
> >> As an aside, I can confirm the findings of a performance difference
> >> between 4.4 and 5.0 when running the script provided earlier in the
> >> discussion. At first glance it seems to be
On Sun, Jan 20, 2019 at 06:26:43PM +0300, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function names, the '-f' unset flag is not required.
> Moreover, it seem confronts with Open Group Base Specification.
> So I consider it as a bug still.
>
It is
On Mon, Jan 07, 2019 at 01:30:46AM -0800, Eduardo A. Bustamante López wrote:
(...)
> I missed a spot, updated patch:
>
> diff -ruN bash-5.0-rc1.orig/lib/readline/undo.c
> bash-5.0-rc1/lib/readline/undo.c
> --- bash-5.0-rc1.orig/lib/readline/undo.c 2019-01-03 13:14:43.428
On Mon, Jan 07, 2019 at 01:16:05AM -0800, Eduardo A. Bustamante López wrote:
> I found this with AFL. I think it's related to the problem reported here:
> http://lists.nongnu.org/archive/html/bug-bash/2018-09/msg00045.html
>
> debian@debian-fuzz:/mnt$ cat -A rl_do_undo
> ^RM-C
Found by fuzzing `read -e' with AFL:
debian@debian-fuzz:/mnt$ cat -A dispose_word
"^[^EM-b^_M-u$$(M-J^^_^Q$
^[^E
debian@debian-fuzz:/mnt$ base64 < dispose_word
IhsF4h/1JCQoyl4fEQobBQ==
debian@debian-fuzz:/mnt$ LC_ALL=zh_CN.gbk ~/build-gdb/bash --noprofile --norc
-c 'PATH= read -e <
On Sun, Jan 06, 2019 at 08:46:33PM -0800, Eduardo A. Bustamante López wrote:
> On Sun, Jan 06, 2019 at 07:18:27PM -0800, Eduardo A. Bustamante López wrote:
> (...)
> > malloc: unknown:0: assertion botched
> > malloc: 0x55769408: allocated: last allocated from unknown:0
I found this with AFL. I think it's related to the problem reported here:
http://lists.nongnu.org/archive/html/bug-bash/2018-09/msg00045.html
debian@debian-fuzz:/mnt$ cat -A rl_do_undo
^RM-CM-!M-CM-CM-!M-C^[.^[^[0^P^@^P^Q0^[-^P^Q0^[^W0^@0&/^[^[^[--^W^_~0^@0^@-^L^D^@^@'/^[B^@0^B^@M-
On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> >
> > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > > (...)
> > >
On Sun, Jan 06, 2019 at 07:18:27PM -0800, Eduardo A. Bustamante López wrote:
(...)
> malloc: unknown:0: assertion botched
> malloc: 0x55769408: allocated: last allocated from unknown:0
> realloc: start and end chunk sizes differ
OK, I think I know what the problem is.
Found by fuzzing with AFL
debian@debian-fuzz:/mnt$ cat -A rl_extend_line_buffer
00^[^?000^?^X^E^_^Y^Y^Y^Y^Y^Y^Y^Y
debian@debian-fuzz:/mnt$ base64 < rl_extend_line_buffer
The expand_prompt_string function will call itself recursively in some
situations:
dualbus@system76-pc:~$ bash -c 'q="\${q@P}"; echo "${q@P}"'
Segmentation fault
My guess is that this is expected behavior. I'm reporting this because it's
affecting my fuzzing effort.
On Sat, Jan 05, 2019 at 08:19:38AM -0600, Peng Yu wrote:
> Hi,
>
> It is not uncommon to see the same name is used to defined functions
> in different .c files in bash source code.
>
> For example, sh_single_quote is defined in both lib/readline/shell.c
> and lib/sh/shquote.c with the exact same
The warning is raised by Clang (7.0.1-4) when sizeof(wchar_t) is 4
| dualbus@system76-pc:~/src/gnu/bash/lib/sh$ make unicode.o
| clang -c -I. -I../.. -I../.. -I../../lib -I../../include -I.
-DHAVE_CONFIG_H -DSHELL -ggdb -O0 -Wno-parentheses -Wno-format-security
unicode.c
|
- Adds the dependency on the Bash's libmalloc
- Removes the libintl dependency, since it's unused
- Adds the `running_trap' global variable, since libmalloc depends on
it when the `SHELL' macro is defined (see [1])
- Removes compiler warning due to missing return type in main function
After
gcc version 8.2.0 (Debian 8.2.0-13) x86_64-linux-gnu
```
malloc.c:333:3: warning: incompatible implicit declaration of built-in function
‘abort’
malloc.c:333:3: note: include ‘’ or provide a declaration of ‘abort’
```
---
lib/malloc/malloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Sun, Dec 30, 2018 at 10:10:42PM +0100, Dušan Kreheľ wrote:
> Hello.
>
> If I try in bash this command ex. "rmdir somethingA > somethingA.out
> 2>&1" work right. But, if I try "rmdir somethingB 2>&1 >
> somethingB.out" that work wrong.
>
> That work's wrong in Bash version 4.4.23(1) and too in
On Wed, Dec 26, 2018 at 12:40:09PM -0600, Peng Yu wrote:
> Hi,
>
> I can not mkdir -p . in /tmp/ via the loadable mkdir. What is the
> difference between /tmp/ and other directories? I am on Mac OS X. Is
> this a bug in mkdir?
>
> $ cd /tmp
> $ mkdir -p -- .
> -bash: mkdir: .: Operation not
On Mon, Dec 24, 2018 at 10:51:00AM +0800, chen liu wrote:
> Chet Ramey 于2018年12月22日周六 上午12:51写道：
(...)
> > What is the hard limit on the number of processes for a process started in
> > this environment? (The value of `ulimit -n'.)
Ah, interesting. Thanks for the pointer Chet.
(...)
> Below is
Commit 9d80be9ab5cc17011c634e0348c64c15fcba95bf adds the following compiler
flag:
dualbus@debian:~/src/gnu/bash$ cat -n configure.ac | grep Werror -C3
1159CFLAGS="$CFLAGS -Wno-parentheses -Wno-format-security"
1160if test -n "$DEBUG"
1161
On Wed, Oct 03, 2018 at 04:45:44PM -0400, Jeffrey Walton wrote:
> Hi Everyone,
>
> I noticed a fair number of new Linux users have trouble with stale
> program caches. Users install a package from a package manager or
> sources and then are confused when the new package is not used. They
> do not
Found via fuzzing (of `read -e') using AFL,
To reproduce:
In a shell with `emacs' readline mode, type:
~/
e.g.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/dualbus/src/gnu/bash/bash
[Thread
On Fri, Sep 21, 2018 at 01:11:38PM +0200, Dr. Werner Fink wrote:
> Hi,
>
> with 4.3.48 the line
>
> T="";echo ">${T//*/ }<"
>
> leads to
>
> ><
>
> but with 4.4.23 the correct result is given back
>
> > <
>
> in the git repro I do not find any useful login entry for this
Check commit
On Fri, Sep 21, 2018 at 04:17:11PM +0200, Enrique Soriano wrote:
> > You're seeing the status from the creation of the background job (which is
> > always 0), not from its completion.
>
> Ah, I see.
>
> Anyway, the behavior is not coherent with the manual page: in this
> case, $? has the status
Found using AFL. The following causes bash 5.0 to get into an infinite loop:
(sorry for the junk reproducer, I don't know how to minimize non-crashing
inputs)
bash-5.0$ IFS= read -r < <(base64 -d <<<
'QCgusbGxw7GxsbGxsbGxsbGxKyQoKChzc3NzcwRpc3Nzc3Nzc3NzdnNzKSMpBymxsbGxsbGxsbGxsR4oGCgoVQ==');
Found by fuzzing with AFL.
$ base64 -d >i
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwEzAwMDAwMDAA
MDAwMDAwMDAwMDAwMDAwMDAw/zAwMDAwMDAwMDAwMDAwMDAwMDABExMZMDAw86Iw
$ cat -A i
On Sun, Sep 16, 2018 at 07:24:13PM -0400, Chet Ramey wrote:
> On 9/16/18 5:15 PM, Eduardo A. Bustamante López wrote:
> > On Sun, Sep 16, 2018 at 02:39:07PM -0400, Chet Ramey wrote:
> >> On 9/16/18 4:12 AM, Eduardo A. Bustamante López wrote:
> >>> He
On Sun, Sep 16, 2018 at 12:42:28PM -0400, Chet Ramey wrote:
(...)
> Bash-5.0 is about to go into beta test.
Interesting. Thanks.
> (...) While fuzzing has some
> interesting results, I haven't really seen any security problems or
> any serious bug that would cause me to hold up a release from
On Sun, Sep 16, 2018 at 02:39:07PM -0400, Chet Ramey wrote:
> On 9/16/18 4:12 AM, Eduardo A. Bustamante López wrote:
> > Here's another interesting crash:
> >
> > $ base64 < 53
> > MBgFEBAQMBgFEBAfEA==
> >
> > $ gdb -batch -ex=r -ex=bt --args ./bash
Here's another interesting crash:
$ base64 < 53
MBgFEBAQMBgFEBAfEA==
$ gdb -batch -ex=r -ex=bt --args ./bash --noprofile --norc -c 'PATH=; set -o
emacs; IFS= read -re' < 53
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0
Found the following two cases by fuzzing with AFL:
# Case #1: array_expand_index
bash <<'EOF'
x='${p[--b[?]]'; echo ${x@P}
EOF
# Case #1 backtrace
: <<'EOF'
Program received signal SIGSEGV, Segmentation fault.
0x0080e0d3 in __strchr_sse2 ()
#0 0x0080e0d3 in __strchr_sse2 ()
#1
On Sun, Sep 02, 2018 at 11:55:21PM +0300, Eliran Gonen wrote:
[...]
> Description:
> “Here Strings” section in the bash(1) manual page claims that “word
> undergoes brace expansion” while it does not.
Hi Eliran,
This was reported by Conor McCarthy back in February 2017:
On Mon, Aug 13, 2018 at 10:52:20PM -0400, Bize Ma wrote:
(...)
> That version is not even beta, it is still alpha, are you asking that
> everyone should use
> non-released (and not yet tested as beta) alpha release ?
(...)
I didn't say that. My point is that, in the context of bug reports, it's
On Mon, Aug 13, 2018 at 09:36:23PM -0400, Bize Ma wrote:
(...)
> Please, do not waste our time in incorrect claims.
>
> Do your homework and test !
(...)
Did you test Bash 5.0? Because that's where the current bug fixes are going to.
I don't see Chet releasing a new version of 4.4 to fix
On Mon, Jul 02, 2018 at 04:58:06PM -0700, toww wrote:
[...]
> Description:
> There seems to be a new incompatibility or incorrect string parsing in how
> the Google "repo" utility interacts with the bash shell. Previously I could
> invoke the "repo" command, passing to it a string to execute
On Wed, Mar 28, 2018 at 06:42:21PM +0300, Кириллов Дима wrote:
[...]
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> I can't understand why read works without subshell before it,
> but with subshell before read it stops
>
> command_not_found_handle()
On Sat, Mar 24, 2018 at 06:05:07PM +, Dennis Williamson wrote:
[...]
> >> $ bash5 -c 'for i; do echo; done; echo in'
> >> bash5: -c: line 0: syntax error near unexpected token `in'
> >> bash5: -c: line 0: `for i; do echo; done; echo in'
[...]
> bash5 -c 'for i; do echo in; done'
>
> fails in
On Wed, Mar 21, 2018 at 11:07:45AM -0300, Larissa Braz wrote:
> Hi,
>
> I found the following compilation error:
>
> xmalloc.c:51:14: error: conflicting types for ‘sbrk’
> extern char *sbrk();
> ^
> In file included from xmalloc.c:29:0:
> /usr/include/unistd.h:1043:14: note:
On Wed, Mar 14, 2018 at 08:43:45AM -0400, Greg Wooledge wrote:
> > 1) You do not provide a hash-bang (i.e. #!/bin/bash), which means that
> > /bin/sh will be used (
>
> No, that's incorrect. When bash tells the operating system to run
> this program, the operating system will return ENOEXEC
> On 2/14/18 3:38 AM, Raphael Hertzog wrote:
[...]
> > Isn't it possible that sbrk() returns that pointer to you and you treat
> > it as being an error instead of a valid address?
The problem is in QEMU:
dualbus@ubuntu:~$ cat sbrk.c
#include
#include
int main() {
On Thu, Feb 08, 2018 at 05:51:06PM -0800, Nolan wrote:
> On 02/08/2018 05:04 PM, Eduardo Bustamante wrote:
> > On Thu, Feb 8, 2018 at 4:23 PM, Nolan <4030...@gmail.com> wrote:
> > > I have found a 'result' of a command that cannot be a feature.
> > >
> > > Enter command, command executes, prints
On Sat, Jan 06, 2018 at 09:13:17PM -0700, Bob Proulx wrote:
> > You can see that the brk() system call actually succeeds.
>
> If you are running under the Linux kernel in the default configuration
> then memory overcommit is enabled.
>
> $ sysctl vm.overcommit_memory
>
> With overcommit
On Sat, Jan 06, 2018 at 01:42:25AM +0200, Alfred Baroti wrote:
> Hi,
> I found this from long long time ago.
> Is this a serious bug?
[...]
This is not a serious bug at all. It's just a memory allocation failure.
> [root@n1x ~]#su nix
> nix@n1x:/root$ printf "%s\n"
>
On Thu, Nov 16, 2017 at 06:50:59AM -0500, Siteshwar Vashisht wrote:
[...]
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Repeat-By:
> $ bash -c 'true $(yes )'
> bash: xrealloc: cannot allocate 18446744071562067968 bytes
Interesting! I think
On Fri, Nov 10, 2017 at 01:59:46PM +0100, Egmont Koblinger wrote:
[...]
> On Ubuntu Artful (glibc-2.26), this tiny snippet reproducibly crashes bash:
>
> LC_ALL=en_US.UTF-8 # or any other UTF-8 locale
> echo -e '\ud800' # or any other lone high or low surrogate
> LC_ALL=en_US.UTF-8
On Wed, Nov 08, 2017 at 12:04:08PM +0100, kalle wrote:
> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an output of `u=rwx,g=rx,o=rx'.
> Shouldn't umask -S also formulate the mask in a negative way, as does
> `umask'? Thus giving out
On Wed, Nov 08, 2017 at 12:20:23PM +0800, Clark Wang wrote:
[...]
> It seems to me bash internally parses the `declare' command specially and
> (logically) convert `declare -a arr=()' to two statements `declare -a arr'
> and `arr=()'.
There is indeed special treatment for assignment builtins in
On Wed, Nov 01, 2017 at 01:19:08PM -0700, Alan Dipert wrote:
[...]
> I can imagine many reasons not to add a new variable, including the fact
> that it could change the behavior of existing scripts. It may also be the
> case that there’s already a method to get sub-second times without shelling
>
On Thu, Oct 26, 2017 at 11:07:57PM +0200, Jakub Wilk wrote:
[...]
> Bash Version: 20171020 snapshot
>
> Apparently an out-of-bounds read can happen in parse_comsub() when checking
> script sytnax. To reproduce, rebuild bash with AddressSanitizer enabled and
> run:
>
> $ printf
>
On Wed, Oct 25, 2017 at 09:48:14AM -0400, Chet Ramey wrote:
> On 10/22/17 6:52 PM, Aron Griffis wrote:
> > I'm seeing some strange behavior and don't know if it's a bug or intended.
> >
> > Reproducer:
> > 1. env INPUTRC=/dev/null bash --norc
> > 2. set -o vi
> > 3. true --foo=bar
> > 4. up
On Sun, Oct 22, 2017 at 10:15:54PM -0400, Aron Griffis wrote:
[...]
> Thanks Eduardo. The clue there about bind-tty-special-chars is helpful,
> since previously I hadn't been able to make unix-word-rubout work either!
>
> However this doesn't seem to explain the case where ctrl-w doesn't work at
On Sun, Oct 22, 2017 at 06:52:12PM -0400, Aron Griffis wrote:
> I'm seeing some strange behavior and don't know if it's a bug or intended.
[...]
> If this is intentional then I'd be curious about the rationale.
Please read:
http://lists.gnu.org/archive/html/help-bash/2016-11/msg4.html
I
On Sun, Oct 15, 2017 at 01:53:15PM -0500, Eduardo A. Bustamante López wrote:
[...]
> From what I can tell, most of the overhead should be in `execute_function'
> (execute_cmd.c):
>
> - calls `tc = (COMMAND *)copy_command (function_cell (var));' for every
> function invoca
On Tue, Oct 10, 2017 at 03:46:38PM +0200, Bernhard M. Wiedemann wrote:
> Hi,
>
> today I was debugging performance issues with a 200KB bash script [1]
> with bash-4.3 and 4.4
> and it seems that much of it came from a function call that took 0.1
> seconds (and it was done in a loop for 37000
On Sat, Oct 14, 2017 at 09:25:26PM -0400, Josh Blagden wrote:
> Hi GNUs,
>
> The page numbers in the Table of Contents are incorrect. For
> example, section 3.2.6, titled "GNU Parallel" is on page 21, not page
> 22. Also, section 3.6, titled "Redirections" is on page 38, not page 32.
> I
On Sun, Oct 08, 2017 at 11:16:33AM -0500, Dan Douglas wrote:
[...]
> Thinking out loud some more... it does make sense that a user in an
> interactive session expects commands to not alter their shell environment,
> and a badly written command_not_found_handle could do that, possibly
> without the
On Tue, Oct 03, 2017 at 10:29:08PM +0200, Mikulas Patocka wrote:
> If $OLDPWD points to a non-existing directory, 'cd -' will fail.
> But if we clear $OLDPWD, 'cd -' will fail too (with just different message).
[...]
I performed the following tests:
dualbus@ubuntu:~$ for sh in mksh ksh93
On Fri, Sep 29, 2017 at 12:51:37AM -0700, L A Walsh wrote:
[...]
> Why does bash clear OLDPWD when a child script is started?
>
> OLDPWD is exported and passed to any children, but bash apparently clears
> OLDPWD whenever a child script is started...
>
> GNU bash, version 4.1.2(1)-release
On Fri, Sep 29, 2017 at 11:12:59AM +0200, Mikulas Patocka wrote:
> This patch doesn't revert the above change. It only removes a test if
> $OLDPWD is a directory. With this patch, if $OLDPWD points to a directory,
> there will be no change, and if $OLDPWD points to non-directory, it will
> not
On Thu, Sep 28, 2017 at 11:44:02AM +0200, Mikulas Patocka wrote:
[...]
> +++ bash/variables.c
> @@ -899,7 +899,7 @@ set_pwd ()
> don't find OLDPWD in the environment, or it doesn't name a directory,
> make a dummy invisible variable for OLDPWD, and mark it as exported. */
>temp_var
On Wed, Jun 28, 2017 at 07:08:27PM -0700, Keith Thompson wrote:
[...]
> mapfile REDIRECT < /tmp/input.txt
> cat /tmp/input.txt | mapfile PIPE
The `mapfile PIPE' is a piece of a pipeline, and as such, it runs in a
subshell (different process).
See:
On Sat, Jun 24, 2017 at 04:46:47PM -0400, George wrote:
[...]
> I'm not seeing the problem here (at least, not in Bash or ksh - mksh and zsh
> seem to have gotten it wrong...)
You are right. I should get some sleep. FWIW, the original claim is that
having a locale-dependent parser is a problem.
I was looking through this old thread:
http://seclists.org/oss-sec/2014/q3/851
It looks like the issue reported in there is still there:
dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash
�\
dualbus@debian:~$ LANG=en_US.UTF8 printf 'echo \u4e57\n' |LANG=en_US.UTF8
On Sat, Jun 24, 2017 at 01:17:23PM -0400, Chet Ramey wrote:
[...]
> You haven't exported these. If you had, the subshell started to run the
> script would have the correct values.
Hm. I think this may be a documentation / usability problem.
The manual states the following:
COLUMNS
Chet:
I think the patch below could be a useful addition, to make the behavior
in this case a little bit less surprising.
*** /tmp/BdLnYa_shopt.def 2017-06-24 10:21:15.029707643 -0500
--- builtins/shopt.def 2017-06-24 10:17:00.540600773 -0500
***
*** 134,139
--- 134,140
On Sat, Jun 24, 2017 at 09:10:34PM +0700, Robert Elz wrote:
[...]
> The bugs in various implementations cause problems, yes, dealing with
> someone else's mistakes (and especially doing it in a way that things
> still work when the bugs get fixed) can be difficult.
>
> But the rules, no, the
On Sat, Jun 24, 2017 at 01:46:00PM +0200, sky...@top-email.net wrote:
[...]
>
> ### DEFINE FUNCTIONS ###
> _config-keymap() {
> # Select keymap
> # find keymap list, cut directory path and sort
> local list_keymaps=( $(find /usr/share/kbd/keymaps/
>
On Sat, Jun 24, 2017 at 09:35:34AM +0700, Robert Elz wrote:
[...]
> In cases where IFS is not a null string, the broken implementations mostly
> tend to work OK (sometimes perhaps only by a fluke), and even more work
> properly if IFS has its default value or something similar, that is
> where
On Tue, Jun 20, 2017 at 11:49:56AM -0400, tetsu...@scope-eye.net wrote:
[...]
> So implementing Unix Domain Sockets in the shell would give you the
> ability to connect to existing services on the machine that use named
> sockets for control (systemd, dbus, cups, etc.) or you could use the
>
I don't know how to fix this.
dualbus@debian:~/readline$
ASAN_OPTIONS=disable_coredump=0:unmap_shadow_on_exit=1:abort_on_error=1:detect_leaks=0
~/src/gnu/bash-builds/devel-asan/bash
bash-4.4$ PS1='$((b[x++}]))'
bash: x++}: syntax error: invalid arithmetic operator (error token is "}")
On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
[...]
> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
> and not the expected IFS=$' \t\n'. All the other unquoted mass
> This is a regression that appeared in 4.3 and is still present on devel
[...]
AFAICT,
There's something weird about the wait builtin + SIGINT handling in the latest
`devel' branch (i.e. 6374eecf232e70e45fe9c49cc8335e8779c07979)
If you interrupt the second `wait' with C-c, the shell will go into an infinite
loop.
dualbus@debian:~/src/gnu/bash-builds/devel$ cat /tmp/s
On Mon, Jun 19, 2017 at 07:30:42PM -0400, Z wrote:
> This patch adds support for Unix domain sockets. A filename of the form
> /dev/unixstream/path used in a redirection makes bash attempt to open a
> connection to the Unix domain stream socket at /path. Similarly a filename
> of the form
On Mon, Jun 19, 2017 at 07:18:11PM -0600, gaze...@xmission.com wrote:
[...]
> Description:
> Command "realpath --help" causes infinite loop.
I can reproduce this in the `devel' branch.
The getopts loop is missing a `return' to break out of it. This should
fix it:
diff --git
On Mon, Jun 19, 2017 at 10:08:30AM -0400, Chet Ramey wrote:
[...]
> I can't reproduce this. I suspect one of your startup files is somehow
> being read and setting PATH. It may also be an interaction with the
> command-not-found hook.
Hm, I can still reproduce it under Debian 9, using the
I'm trying to figure out a way to fuzz >>read -e -d ""<<, without having the
fuzzer break due to the temporary files created by fc.
While doing this, I noticed the oddities described below.
#1
Hit `C-x C-e' twice. The value of PATH seems to be ignored for the second
line.
dualbus@debian:~$
On Sun, Jun 18, 2017 at 02:02:05PM -0700, L A Walsh wrote:
[...]
> int dpi=$(ord $(<"$pixels_path" 2>/dev/null))
>
> This used to work but now works _unreliably_.
In what version does this used to work?
I tested on a couple of versions, and the behavior you describe didn't work:
# When bash is compiled with multibyte support, the following happens:
- set -o vi
- Type: <ñ><.>
- Bash writes \261 to `mb[0]' and '\0' to `mb[1]' (ñ is U+00F1, or in
UTF-8, \303\261)
- `mb' is of type signed char, and not really suitable to store a wide
character.
dualbus@debian:~$ set
dualbus@debian:~/src/gnu/bash$ git diff -- lib/readline/display.c
diff --git a/lib/readline/display.c b/lib/readline/display.c
index d5536211..1f281cd3 100644
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -2127,7 +2127,7 @@ dumb_update:
cpos_adjusted = 1;
The manual is clear on this:
Since the coprocess is created as an asynchronous command, the coproc
command always returns success
I'd argue that it should return an error code for this particular case
though:
$ bash -c 'coproc % { :; }; echo $?'
bash: `%': not a valid identifier
0
On Thu, Jun 15, 2017 at 09:42:41AM -0500, Eduardo Bustamante wrote:
> Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
> Sanitizer is followed by the base64 encoded crashing input.
>
>
> ==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6070ccc0 at
On Thu, Jun 15, 2017 at 09:39:09AM -0500, Eduardo Bustamante wrote:
> Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
> Sanitizer is followed by the base64 encoded crashing input.
>
>
> ==472==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6110977f at
On Thu, Jun 15, 2017 at 09:41:08AM -0500, Eduardo Bustamante wrote:
> Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
> Sanitizer is followed by the base64 encoded crashing input.
>
>
> ==1098==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x55e61a6b4c5c
On Thu, Jun 15, 2017 at 09:36:58AM -0500, Eduardo Bustamante wrote:
> Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
> Sanitizer is followed by the base64 encoded crashing input.
>
>
> ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x61109880 at
Actually, there are more leaks in execute_cmd.c, I'm just going to list them
here.
---
hp% ./bash -c '(:)'
=
I ran the configure script with the following arguments:
hp% ./configure CC=gcc-6 CFLAGS='-Wall -g -ggdb -O0 -fsanitize=address'
LDFLAGS=-fsanitize=address --without-bash-malloc
Which enables the LeakSanitizer
(https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer).
It
I'm running configure with the following flags:
|./configure CC=gcc-6
The error I get while building:
|make[1]: Entering directory '/home/dualbus/local/src/gnu/bash/lib/malloc'
|gcc-6 -I. -I../.. -I../.. -I../../include -I../../lib -DHAVE_CONFIG_H
-DSHELL -Wall -g -ggdb -O0
On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
[...]
> Assigning to BASHPID most certainly does have an effect. Since you
> didn't quote that part, I think you might have missed my point that
> attempting this will silently exit the shell without any error message,
> causing the
1 - 100 of 266 matches
Mail list logo
