On Wed, May 24, 2017 at 11:53:45AM -0400, Chet Ramey wrote:
[...]
> It was changed back in 2015 as the result of
>
> http://lists.gnu.org/archive/html/bug-bash/2015-09/msg00053.html
After reading POSIX's [1] (section 2.5.3 "Shell Variables"), I noticed
that bash may not be following the specifica
On Mon, May 29, 2017 at 12:29:16AM -0400, George Caswell wrote:
[...]
> Bash's builtin function "read" has one simple job: read data, return
> it to the caller. There shouldn't be anything in there about executing
> commands.
>
> Why does read even need a function like this? Is it something that w
On Mon, May 29, 2017 at 04:17:16PM -0400, Chet Ramey wrote:
[...]
> So the bug is that readline doesn't print an error message if the history
> file isn't a regular file?
Correct. Another problem is that the history builtin doesn't propagate
back a meaningful return code indicating that there was
On Mon, May 29, 2017 at 06:25:06PM -0400, Chet Ramey wrote:
[...]
> If PWD appears in the environment, and it is an absolute pathname of the
> CWD, set PWD to the canonicalized version of the environment value. The
> canonicalized version removes . and .., makes sure that the length is
> less than
On Mon, May 29, 2017 at 11:40:54PM -0400, George wrote:
[...]
> You misunderstand. Being able to use Readline in "read" is great! And
> "edit-and-execute-command" may have its uses when invoked from an
> interactive
> shell session. But why is "edit-and-execute-command" useful or in any
> way desir
On Thu, Jun 01, 2017 at 09:31:24PM -0700, L A Walsh wrote:
[...]
> Absolutely needs? Do people absolutely need computers? They are supposed
> to
> be there to serve us and make our life easier. So you shouldn't be asking
> a lame question that eliminates the machines and media we are using to
>
I'm using the latest `devel' commit as a reference:
dualbus@debian:~/src/gnu/bash$ git show -q HEAD
commit 1110e30870a8782425067a060d89cc411b014418
Author: Chet Ramey
Date: Wed May 31 15:53:02 2017 -0400
commit bash-snap-20170531 snapshot
Since there are still many memory
On Thu, Jun 01, 2017 at 10:16:30PM -0700, L A Walsh wrote:
> > Should UTF-8 be assumed?
> You realize bash already allows UTF-8 input?
Of course. Both Bash and Readline are able to process multibyte
character input. That's not the same as parsing multibyte sequences in
*code*. See Python's Enhance
val)
[...]
> Is this solution ok?
Yes. That works.
Chet went with the other option though:
dualbus@debian:~/src/gnu/bash-build$ ./bash -c 'read -n0; echo $?; declare -p
REPLY'
0
declare -- REPLY=""
You can see the change by navigating the `de
"1.61803398874989485"
declare -- π="3.14159265358979324"
With this terrible patch:
dualbus@debian:~/src/gnu/bash$ PAGER= git diff
diff --git a/general.c b/general.c
index 584e7859..40db7b1d 100644
--- a/general.c
+++ b/general.c
@@ -61,6 +61,9 @@ extern int errno;
# include
strings and normal
strings, because that was easier to hack quickly.
By the way, ksh93 and zsh already support Unicode identifiers:
dualbus@debian:~$ for sh in bash mksh ksh93 zsh; do LC_CTYPE=en_US.utf8 $sh
-c 'φ=phi; echo $φ'; done
bash: φ=phi: command not found
$φ
mksh: φ=p
On Tue, Jun 06, 2017 at 10:20:03AM -0400, Greg Wooledge wrote:
[...]
> (OK, in reality, I am not taking any of this seriously. This entire
> proposal and discussion are like some bizarre fantasy land to me. Bash
> is a SHELL, for god's sake. Not a serious programming language. Even
> serious pr
-gnu/libasan.so.3+0xc1d28)
#1 0x558589eb06d6 in xmalloc
(/home/dualbus/src/gnu/bash-build/bash+0x14f6d6)
#2 0x558589ea2c62 in set_default_locale
(/home/dualbus/src/gnu/bash-build/bash+0x141c62)
#3 0x558589de17f0 in main
(/home/dualbus/src/gnu/bash-build/bash+0x807f0
On Thu, Jun 08, 2017 at 09:59:39AM -0400, Chet Ramey wrote:
[...]
> Even though glibc allocates the memory for the current locale, the man page
> warns not to assume that:
>
> "A successful call to setlocale() returns an opaque string that corre-
> sponds to the locale set. This string may be a
On Fri, Jun 02, 2017 at 12:07:34AM -0500, dualbus wrote:
[...]
> #1 _rl_get_char_len / update_line
[...]
> ==5781==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6190cc80 at pc 0x7f400d00b063 bp 0x7ffcbce72250 sp 0x7ffcbce71a00
> READ of size 851 at 0x6190cc
15 matches
Mail list logo
