On Mon, Jun 19, 2017 at 5:17 AM, L A Walsh wrote:
>
>
> Chet Ramey wrote:
>
>> On 6/18/17 6:59 PM, L A Walsh wrote:
>>
>>
>>> Chet Ramey wrote:
>>>
>>>
Bash has always stripped NULL bytes. Now it tells you it's doing it.
>>> Why? Did I toggle a flag asking for the warning? Seems
On Mon, Jun 19, 2017 at 12:07:31AM -0400, George wrote:
> ultimately identified in the nameref also comes from the caller) but the
> inconsistency there, of "typeset -n" behaving differently depending on where
> the name comes from, is very unappealing to me. I'd much rather see this
> behavior a
As a bonus you'd be able to lure the uninitiated into asking questions
like "What's upvar?"
- Original Message -
From: "Greg Wooledge"
To:"bug-bash"
Cc:
Sent:Mon, 19 Jun 2017 08:18:14 -0400
Subject:Re: RFE: Fix the name collision issues and typing issues with
namerefs, improve various
On 6/18/17 10:17 PM, L A Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 6/18/17 6:59 PM, L A Walsh wrote:
>>
>>> Chet Ramey wrote:
>>>
Bash has always stripped NULL bytes. Now it tells you it's doing it.
>>> Why? Did I toggle a flag asking for the warning? Seems like it
>>> w
On 6/19/17 9:12 AM, tetsu...@scope-eye.net wrote:
>
>
> As a bonus you'd be able to lure the uninitiated into asking questions
> like "What's upvar?"
The same old, what's up with you?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - H
On Sun, Jun 18, 2017 at 07:17:46PM -0700, L A Walsh wrote:
> Oh? I want to read in a value from the registry where something may
> have zeros
> after the data. Please tell me the mechanism to read this in w/no warnings
> that won't silence more serious cases of zero's other than at the end of
>
On 6/18/17 9:39 PM, Eduardo A. Bustamante López wrote:
> 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
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 `devel'
On Mon, Jun 19, 2017 at 9:57 AM, Eduardo A. Bustamante López
wrote:
[...]
> Hm, I can still reproduce it under Debian 9, using the `devel' branch, and I'm
> sure no startup files are being sourced.
>
> dualbus@debian:~/src/gnu/bash-builds/devel$ ./bash --norc --noprofile
> bash-4.4$ declare -p
On 6/18/17 9:39 PM, Eduardo A. Bustamante López wrote:
> #1
> Hit `C-x C-e' twice. The value of PATH seems to be ignored for the second
> line.
The shell should ensure that the temporary env is preserved across the
entire execution of any builtin that can call parse_and_execute (like `fc'
and `r
On 6/18/17 9:39 PM, Eduardo A. Bustamante López wrote:
> 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
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share
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 /dev/unixdgram/path makes bash attempt to open a connection to
the U
Hi,
When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
and not the expected IFS=$' \t\n'. All the other unquoted mass
expansions ($@, array[*], array[@]) are word-split as if IFS=$'
\t\n'.For instance:
nb_args() { echo $#; }
set -- $'a\nb'
unset IFS
# Expected: 2,
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 /dev/unixdgram/path makes bash attempt to open
a connection to the U
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 a/examples/load
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 /dev/unix
Attaching the patch usock.diff.txt
On Mon, Jun 19, 2017 at 11:36 PM, Eduardo A. Bustamante López
wrote:
> 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 attemp
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
#!/bin/bas
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, the
20 matches
Mail list logo
