On Mon, Oct 17, 2016 at 08:38:29PM +0200, Martijn Dekker wrote:
[...]
The BASHPID variable is initialized with null_assign as its "assign_func". The
default value for this attribute in newly created variables is NULL.
The problem here is caused by the following code from variables.c (function is
The attached patch "fixes" this:
hp% ./bash -c 'time (TIMEFORMAT=y)'
real0m0.001s
user0m0.000s
sys 0m0.000s
hp% bash -c 'time (TIMEFORMAT=y)'
y
Disclaimer: I don't know if it's a good patch. It may break stuff.
This problem is caused due to bash passing
On Wed, Jul 27, 2016 at 09:06:50AM +0300, Pierre Gaston wrote:
[...]
> > Description:
> > Unlike usual variables, that have been assigned an empty value,
> > arrays are treated by test -v as if they weren’t assigned anything.
[...]
> > This has been reported and discussed several times.
>
On Wed, Apr 27, 2016 at 08:58:47PM +0200, Piotr Grzybowski wrote:
> On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote:
>
> > The attached patch seems to take care of at least these two cases: [..]
>
> your patch also adresses the original Grisha's report:
>
>
On Mon, Apr 25, 2016 at 03:48:17PM -0400, Grisha Levit wrote:
> There seems to be a bug that if an array variable with a name matching one
> of the special single-character variables exists, then that variable is
> used during substring expansion and parameter transformation.
[...]
> # Expected
The attached patch seems to take care of at least these two cases:
| dualbus@hp ...src/gnu/bash % ./bash --norc --noprofile -c 'r=@; declare -n r'
| ./bash: line 0: declare: @: invalid variable name for name reference
|
| dualbus@hp ...src/gnu/bash % ./bash --norc --noprofile -c 'declare -n
On Wed, Apr 27, 2016 at 08:41:20AM -0400, Grisha Levit wrote:
[...]
> The above works when the readonly variable has a value that is also a valid
> identifier. In my previous example I worked around this using the fact
> that ref=;
> declare -n ref does not check to make sure that $ref is a valid
Hi Lauri,
Thanks for your report.
This is fixed in the devel branch (bash v4.4). I can confirm the issue in v4.3:
dualbus@hp ~ % { sleep 1; printf ': <(: <(: /etc/pass'; sleep 1; printf
'\t'; sleep 1; printf ') )\necho $?\n\030\026exit\n'; } | script -q -c
Hey,
We got your report three times. Try to be more patient ;)
This is not a bug. When you use shopt -s extglob, you change how bash parses
the input script. But it has some restrictions:
- You can't enable extglob and use extglob syntax in the same line
- You can't enable extglob in a function
On Thu, Jan 07, 2016 at 08:56:06PM +, Reuben Thomas wrote:
[...]
> Yes, and it's not at the moment (or wasn't, until I added timestamps to
> every line in my history), because the lines at the start of the history,
> with no timestamp, were given the current date and time, and lines at the
>
Take into account that many options have been provided (history -d, the space
prefix, even editing .bash_history yourself).
But you request a single key stroke to do this... why?
If you enter a password by mistake in your shell, and it gets recorded, then
you go and clean up. It's not hard to
It's impossible to tell with the amount of info you provided. That's why
there's a 'bashbug' script alongside bash to generate a useful bug report
template.
Provide:
- bash version: bash --version
- OS name and version: uname -a
- The contents of the run.sh file
- If possible also the su version
On Sat, Jan 02, 2016 at 03:08:54PM +0200, Joey Geralnik wrote:
> I have found an easily reproducible bug in bash that causes it to crash and
> have attached a fix.
I think this was already reported here:
- https://lists.gnu.org/archive/html/bug-bash/2015-07/msg00022.html
And I think the fix is
bashdb is maintained separate from bash, by a different person:
http://bashdb.sourceforge.net/
Kelvin:
This is what's typically called a layer 8 issue, or PEBKAC. It just means that
you're failing to understand how bash works.
If you write a script that runs:
#!/bin/bash
sudo poweroff
Is that a vulnerability? No! The script does exactly what you wrote, that is,
to shutdown the
This definition (
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_230
) states:
3.230 Name
In the shell command language, a word consisting solely of underscores,
digits, and alphabetics from the portable character set. The first character
of a name is not
On Thu, Oct 29, 2015 at 02:03:50PM -0700, Dan Stromberg wrote:
> Hello? I sent the message I'm replying to 5 days ago, and no one has
> replied.
Hi Dan, the only one with commit access to bash is Chet Ramey. You'll have to
wait a bit more than 5 days for him to see and review your patch, since
Hi Chet,
I compiled bash with:
CFLAGS='-O0 -g' ./configure --silent && make -j2 && make tests 2>&1 | tee
out.log
And I get many parsing errors in the results. Most seem to be parenthesis
related, and some segfaults. I hope these two lead to fixing the whole thing:
$ uname -a
OpenBSD
On Mon, Oct 26, 2015 at 09:02:21AM -0400, Chet Ramey wrote:
> Use bison. Command substitution requires invoking the parser recursively,
> and byacc is completely incapable of reentrant parsing.
>
> This is one of the reasons that production bash releases ship with versions
> of y.tab.c and
I found this some time ago, but didn't report it because I couldn't come up
with a patch:
dualbus@hp ~ % for sh in bash mksh zsh ksh93 dash; do $sh -c
't=${KSH_VERSION+typeset}; f() { x=3; ${t:-local} x; echo $x; }; [ "$(f)" =
"$(x=4 f)" ]'; echo $sh $?; done
bash 1
mksh 0
zsh 0
ksh93 0
dash 0
> Repeat-By:
> shopt -u extglob
> isnum () ( shopt -s extglob; case "$1" in [1-9]*([0-9])) return 0 ;;
> *) return 1 ;; esac; )
Remember that bash parses and interprets the script line-by-line. If you want
to change the parser's operation (for example, have it recognize the extglob
On Sat, Sep 19, 2015 at 11:17:33PM -0500, Brian Carpenter wrote:
> I found another null ptr deref and segfault. This only seems to affect bash
> 4.4.0 as 4.2.37(1)-release and 4.2.37(1)-release only return a 'bad
> substitution' error message.
Hey Brian,
I just wanted to step in and say: you're
dualbus@hp ~ % bash -c 'a=1; echo "${!a}"' . arg
arg
--
Eduardo Bustamante
http://dualbus.me/
Just FYI, if this were really a critical security issue, this is not how you
should disclose it:
https://www.reddit.com/r/netsec/comments/3h997d/bash_integer_overflow/
You have to first contact the maintainer in private, make sure the issue is
acknowleged, fixed, and that the fix is available to
In the US we call those parentheses, and we reserve the word brackets
(or square brackets) for [ ]. I realize that the UK uses different
terminology. Hence, the word is ambiguous and you should always type
the actual characters you mean.
These are also paréntesis in Spanish, so it's not a
Hello,
Can you please try the 'devel' branch?
There's a fix for this issue already in it:
| commit 947f04912e4715e7a9df526cd99412bffa729368
| Author: Chet Ramey chet.ra...@case.edu
| Date: Tue Jan 27 11:10:49 2015 -0500
|
| commit bash-20150116 snapshot
Here's the description of
On Mon, Jul 13, 2015 at 11:46:50PM +0300, Dmitry Bogatov wrote:
Hello, bug-bash and personally maintainer Chet Ramsey.
Would you be interested in following patches?
* GNU Guile integration (built-in that outputs value of Guile procedure
call, similar to what Make recently introduced)?
On Thu, Jul 09, 2015 at 01:53:52PM -0700, Bill Parker wrote:
Hello All,
In reviewing the code at line 990 in bashfile.c, while the
issue of rl_line_buffer[0] = '\0', would it not be better to
use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to
clobber the entire line more
Using LC_ALL=C here is just like hiding your head in the dirt and pretending
nothing is wrong. If the tests break with non-C locales, it means that bash
doesn't compile correctly under that system, and that's worth investigating.
--
Eduardo Bustamante
https://dualbus.me/
On Mon, Jun 29, 2015 at 07:49:24PM -0400, Chet Ramey wrote:
That't not what he's saying. He's saying -- correctly -- that different
locales produce different localized error messages (e.g., command not
found) and that produces output. The majority of those tests can set
LC_ALL=C without
On Wed, Jun 10, 2015 at 11:00:51AM -0400, Chet Ramey wrote:
On 6/2/15 1:07 PM, Roy Keene wrote:
All,
There is a bug of some sort in bash 4.3.30 (and likely others) when
compiled with --disable-job-control on Linux/x86_64.
I can't reproduce this on RHEL 6 or Fedora 22 with
On Wed, May 27, 2015 at 12:59:53AM -0700, Dave Yost wrote:
OK, I can make it to work in bash if I say
echodo a=b\\ c
but then zsh tries to execute c. Can’t win.
The problem is: how do I write this function so that it can be invoked
identically in zsh and bash with identical results of
On Tue, May 26, 2015 at 05:47:30PM +0200, Geir Hauge wrote:
[...]
The surprising part is that it keeps the -n flag, but partially loses
the nameref ability:
$ var=foo; declare -n ref
$ ref=var
$ printf '%s - ' $ref; declare -p ref
foo - declare -n ref=var
$ unset ref
$ ref=var
$ printf
The total of 38.5% isn't that bad considering the condition/decision
coverage metric. Better than other projects we tried at least.
Thanks for this.
Although it's kind of useless without knowing the context of how these graphs
were generated. How did you measure coverage? What tests did you
[19:24] dualbus for every fix that Chet does, he introduces like 2 bugs.
Nice way of keeping himself busy
That points to the importance of having a good, comprehensive test suite.
It's difficult to test the interaction between features otherwise.
I apologize for my comment :-) I
On Fri, Apr 17, 2015 at 11:12:50AM +0200, isabella parakiss wrote:
I need to check if an element in an associative array is set. What's the
correct way to test it?
dualbus@yaqui ~ % export key; for key in \* x y; do bash -c 'declare -A
a=([x]=y [y]=); echo $key ${a[$key]+inarray}; declare -p
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
[...]
AFAIK, _exec_gvim, can only be called from within function gvim, no?
No. Doing this:
outerfunc() {
func() { ...; }
func args
unset -f func
}
outerfunc
Doesn't guarantee that `func' will be only called from outerfunc. If you
Ok that kind of makes test -v useless, doesn't it?
You might want to read:
https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
--
Eduardo Bustamante
https://dualbus.me/
This is not a bug.
This is due to not understanding two aspects of bash:
1) $arrname is the same as ${arrname[0]} (not the first element, as what you
seem to imply). Bash arrays are sparse, so you can define the element at
index 1, without having an element at 0.
2) unset and empty is not
Always quote your variables. The problem comes from
echo $INPUT
which should be
echo $INPUT
Someone derped. It *should* be
echo $INPUT
--
Eduardo Bustamante
https://dualbus.me/
0001-Fix-spacing-issues-in-tests-to-make-it-easier-to-tra.patch
This one attempts to remove the false positives that the different spacing
output between od's causes. There's also a change for one of the unicode
tests, but I'm not sure about that one.
0002-Fix-unclosed-double-quote.patch
This
In the BSDs, doing a read on a directory doesn't return a negative value.
Bash assumes that you can't do reads on directories here:
1501 /* Only do this with non-tty file descriptors we can seek on. */
1502 if (fd_is_tty == 0 (lseek (fd, 0L, 1) != -1))
1503 {
1504 /* Check to see
I agree 100% with you here. I don't see the point of optimizing bash for
unrealistic cases.
--
Eduardo Bustamante
https://dualbus.me/
On Fri, Apr 17, 2015 at 04:26:08PM -0400, Mike Frysinger wrote:
please post patches inline and as a series rather than attaching a binary
tarball. it makes review much harder when you do this.
in fact, `git send-email` takes care of all of this for you.
-mike
Makes sense, thanks! I'll
Well, if your scripts are so simple, why use local functions at all? You're
claiming we invent stuff to make your examples fail, but I don't know anyone
that writes such complex code for very simple tasks that can even be done
without functions. So, the burden to prove these convoluted approaches
intention, though that doesn't
matter much.
On Fri, Apr 17, 2015 at 03:27:12PM -0700, Linda Walsh wrote:
Eduardo A. Bustamante López wrote:
Well, if your scripts are so simple, why use local functions at all?
---
Cleanliness, Hygiene...
You're
claiming we invent stuff to make
Any reason to justify this instead of using a simple loop?
--
Eduardo Bustamante
https://dualbus.me/
On Thu, Apr 16, 2015 at 11:07:34AM -0400, Chet Ramey wrote:
[...]
I knew that rang a bell somewhere. mt_hash is a function in the bash
malloc library that keeps track of all allocations and deallocations in
a table. It's part of the debugging that is enabled when you build from
the devel
You can trap SIGPIPE and handle it.
--
Eduardo Bustamante
https://dualbus.me/
It is from FreeBSD ports. Everyone has the same bash there.
make distclean etc is all made in a standard way.
Are you saying that the ports build is broken?
Yuri
Hello Yuri. See Chet's response. That's the actual issue. My response was a
best effort attempt at helping, but I ended up
Did you build bash yourself?
You need bison when compiling it, and make sure to run a: make distclean
before building. I also found this issue while building for openbsd/freebsd,
but this is due to some problem in the files included with the bash
distribution that have to be regenerated
Oh, you already have lots of things to do to bother with this :-)
Anyways, I'll expand them.
On Fri, Apr 10, 2015 at 04:35:25PM -0400, Chet Ramey wrote:
On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
- a faster implementation of the variable lookup code
What does this mean
Read about set -T in the manual. Also, you have an error in your trap
definition. The $1 inside ... will expand at *definition* time, not when the
trap is executed. See:
dualbus@yaqui ~/t % cat script
echo '
trap echo $1 DEBUG
' ./trapcmd
source ./trapcmd first
There is no bug. Simply, your expectations on when the DEBUG trap runs are
wrong.
The `script2' I provided ran with set -T is the closest you'll get to what you
expect, but, since DEBUG runs *before* the source command, it'll not work as
you want.
--
Eduardo Bustamante
https://dualbus.me/
Not a bug.
This is a well known issue with restricted mode. You as a sysadmin must provide
a very restricted PATH that contains only secure programs. For example, you
have to avoid: GNU sed, nvi, vim, ed, emacs, ...
Perhaps this *should* be documented under RESTRICTED SHELL in the bash manual.
I'm replying to this report, because it's the latest.
This seems to be caused by last_read_token having an incorrect value set.
`alias_expand_token' in parse.y relies on
`command_token_position (last_read_token)' (and parser_state), to determine if
an alias expansion should be performed.
The
Hello Chet,
You introduced a regression:
[dual...@ma.sdf.org /tmp/tmp.ps6HXrLSZX/devel-]$ ./bash -c 'typeset -i x;
x=([0]=1+1); echo $x'
1+1
vs
dualbus@yaqui ~ % bash -c 'typeset -i x; x=([0]=1+1); echo $x'
2
The regression was introduced here: 06c3a57511953d09ac9ea262bc18bfdbcff23fc4
The
Here's a patch:
diff --git a/builtins/declare.def b/builtins/declare.def
index 5ed83a0..f0f9a6d 100644
--- a/builtins/declare.def
+++ b/builtins/declare.def
@@ -280,7 +280,7 @@ declare_internal (list, local_var)
return (sh_chkwrite (any_failed ? EXECUTION_FAILURE :
EXECUTION_SUCCESS));
Already fixed:
dualbus@yaqui:~/local/src/gnu/bash$ for ((; 1(1) ;)); do break; done
dualbus@yaqui:~/local/src/gnu/bash$
GNU bash, version 4.4.0(1)-devel (x86_64-unknown-linux-gnu)
On Wed, Apr 01, 2015 at 12:53:16PM -0500, Dan Douglas wrote:
Hi, This was noticed in a comment to a github issue.
Not a bug.
On Tue, Mar 31, 2015 at 06:04:53PM +0300, Filimonov Vadim wrote:
[..]
filimonov@filimonov:~/bashbug/bash-4.3$ read -u63 LINE (echo *);echo $LINE
bash: read: `/dev/fd/63': not a valid identifier
ABOUT-NLS aclocal.m4 alias.c alias.h alias.o array.c arrayfunc.c arrayfunc.h
On Tue, Mar 31, 2015 at 07:24:09PM +0300, Filimonov Vadim wrote:
[...]
But I can't understand why
echo *
Read the bash manual, section 'Pathname Expansion'.
--
Eduardo Bustamante | https://dualbus.me/
Why would the user set BASH_VERSION in the environment? That sounds like asking
for trouble!
If you're against someone who actively tries to fool you into thinking you're
in bash, then it'll be very hard.
One way that I think would work is to:
- try to unset BASHOPTS (did it work? then it's not
Original report here: https://savannah.gnu.org/support/index.php?108732
On systems without /dev/fd support, using procsub will generate a temporary
file.
In the case of bash -c 'cat (echo yes)', the no-fork optimization will cause
this to not clean up the created temporary file.
Reproduced
Original-Report: https://savannah.gnu.org/support/index.php?108708
Reporter: Pasha Bolokhov
Alias produces non-reusable output:
dualbus@yaqui:~$ alias -- -x='echo x'
dualbus@yaqui:~$ alias -p
alias -x='echo x'
alias ls='ls --color=auto'
'help alias' claims it's reusable:
alias -p|grep reusable
On Wed, Mar 25, 2015 at 10:17:49AM -0400, Chet Ramey wrote:
On 3/25/15 6:35 AM, Eduardo A. Bustamante López wrote:
Original-Report: https://savannah.gnu.org/support/index.php?108708
Reporter: Pasha Bolokhov
Alias produces non-reusable output:
This is fixed on the devel branch.
Hm
Here's the other side: allowing `set -$-' to succeed keeps a Posix-mode
shell running a script from throwing a fatal error. Allowing it also
keeps the bug reports down. The same rationale can be used to add -c and
-s to the no-op flags, since those are command-line options that end up
in
I know that some people are interested in a more detailed commit history in
bash's git repository. After all, it's easier for all of us to just learn to
use a tool, and use that for everything.
The changelog files distributed with bash are useful, *but*, I claim that it'd
be more useful to use
You can avoid these surprises by making -i just as other options, i.e.,
working within the shell not just when a shell is started. [..]
I don't think it's good to have set +/-i available after initialization. It's
more complex to handle, and with little (or null?) gain. If you're using
set -i
This seems to be a bug. (I'm Cc-ing bug-bash)
When you set the 'i' flag as an option to bash, it works:
dualbus@hp ~ % bash -O checkwinsize -ic 'echo $COLUMNS'
136
This is because of the special treatment that 'i' gets in shell.c. There are
some tests there for the value of
Your code is horrible. Why do you have to alias stuff like declare -p?
Anyways.
#!/bin/bash
echo Using:
bash --version|head -1
shopt -s expand_aliases
RA='declare -a'
alias rs=IFS=\ $'\x09'$'\x0a'
The fuck? Just use
alias rs=IFS=\$' \t\n' or even better, alias rs='unset IFS'
alias
But I am wondering if there is a walkaround to deal with errors in
(). The ideal behavior should be that if there is a error in (),
then we should not consider commandA is executed correctly even if its
return status is 0.
Again, address your questions to help-bash.
you can use:
CommandB |
On Sat, Mar 07, 2015 at 04:31:54PM -0600, Peng Yu wrote:
Hi, I use unset to remove x from the environment once the for loop is
finished. Is it the best way to do in bash? Thanks.
First, use the help-bash mailing list for this kind of queries.
Second, unless you used 'export x', then the 'x'
On Sat, Mar 07, 2015 at 05:10:51PM -0600, Peng Yu wrote:
Hi,
The following code works in bash.
for x in a b c; { echo $x; }
But I only find the following in bash man page. Does anybody know
where the above usage is documented? Thanks.
for name [ [ in [ word ... ] ] ; ] do list ; done
On Thu, Mar 05, 2015 at 02:26:48PM +, Jason Vas Dias wrote:
Good day list, Chet -
I think this is a bug:
( set -x ; tab=$'\011'; s=some text: 1.2.3;
if [[ $s =~ ^some text:[\ $tab]+([0-9.]+) ]]; then
echo ${BASH_REMATCH[1]};
fi
)
-bash: syntax error in conditional
So I'm wondering -- why didn't the alias call the function.
dualbus@hp ~ % type setsid
setsid is /usr/bin/setsid
So, basically you did:
external-program anotherprogram
And external-program only knows how to execute programs, not bash functions.
Put the setsid inside the function, and
Recursion is not a bug, it's a feature of the language.
On Wed, Feb 18, 2015 at 08:30:31PM +0100, SN wrote:
Also, remember to state the version you're using.
I pasted version in the format printed by bashbug. In case it's not enough:
Yep, you omitted this part though:
Bash Version: 4.3 - that
Patch Level: 33
Release Status: release
Let's wait to
it:
dualbus@dualbus ~/local/src/bash
% git log -p -1|cat
commit 5d29a37a60c9daabf85de66dd7df3c459bd0c468
Author: Eduardo A. Bustamante López dual...@gmail.com
Date: Wed Feb 18 18:53:04 2015 -0600
Check if v is not NUL
diff --git a/variables.c b/variables.c
index 2f07ebb..91912cd 100644
On 2/18/15 3:49 PM, Maarten Billemont wrote:
[...]
I think the more important question isn't why does (( behave this way?,
but rather should (( behave this way?.
It's probably not reasonable to expect the author to know and take into
account that (( arr[$key] )) treats key's data as
I'm pretty sure this was already discussed in this thread:
* http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00108.html
But... it's huge, so it's hard to find the precise part where this
was discussed.
Also, remember to state the version you're using. This particular
feature seems to
On Mon, Feb 16, 2015 at 03:04:49AM +0100, emanuelczi...@cryptolab.net wrote:
Description:
when dealing with integer operations(let, ++), bad array subscript
errors
can happen because subscripts get unquoted (and evaluated even though they
are in single quotes); unlike what happens when
Already reported:
* test -v: http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
* declare -p arrname:
https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00084.html
On Tue, Jan 27, 2015 at 06:11:37AM -0800, Ryan Cunningham wrote:
And by type-in programs in the message to which I am replying, I mean those
published in source code form.
Please, stop it. We're not interested in hearing about your get back to the
'80s stuff, and this discussion does NOT belong
I'd suggest first investigating how bash works (read the source), before
claiming funky stuff. Bash interpretes *source code*, it doesn't matter how you
provide it. The only exception is what Greg specified.
Mr. Ramey, I already pointed that out to Mr. Stallman. I found that out from
testing a similar technique using Python.
How is a heredoc object code? You're just passing the source to the bash
interpreter through a pipe, but it's still source code.
I am proposing this as a possible alternative or complement to publication
on the Internet to take into account those without Internet access, though
those *with* Internet access also get the benefit.
So you want to publish stuff on the Internet for people that don't have access
to the
I read somewhere that GNU was moving to C++.
But I can rewrite this in C.
--- Brian
You forgot to CC the list.
Also, consider the following:
- bash has one maintainer only
- the code you provided is just an example, it's not a patch against bash, so,
further work is needed to understand
On Fri, Jan 23, 2015 at 06:35:14PM +0100, Artur Rataj wrote:
Hello. After typing the following, then space, then Tab,
tar --exclude-vcs cBvf a.tar.bz2
the shell or whatever freezes.
Best regards,
Artur
bash-completion is a separate package, and reports should go here:
On Sat, Jan 24, 2015 at 01:53:43PM -0500, McGuinness, Brian wrote:
I have been experimenting with code to allow
sequences to be included in lists and to
extend sequences to arbitrary character strings.
This seems to work well now. Please feel free
to incorporate this into future versions of
On Tue, Jan 20, 2015 at 01:39:02PM -0800, marc.coiff...@gmail.com wrote:
Seems to be either a Debian-specific bug, or a bug that was fixed in a
later patch than Debian is using.
Great ! Thank you for the quick response.
If you have time for a followup question, do you know who I should
On Wed, Jan 14, 2015 at 09:55:33AM -0500, Dave Rutherford wrote:
[...]
I don't think so, unless Debian turned it on for me.
Can you test with:
bash --norc --noprofile -i
Note that without a\ a.odt there,
$ ls ~/a/aTAB[completes to a\ a.txt]
but
$ ls ~/a/a\ TAB
See:
- http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00200.html
- http://lists.gnu.org/archive/html/bug-bash/2014-04/msg00077.html
- http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00202.html
On Wed, Jan 14, 2015 at 09:33:31AM -0500, d...@evilpettingzoo.com wrote:
[...]
Bash Version: 4.2
Patch Level: 37
[dualbus@dualbus ~]$ mkdir a; a/a\ a.txt
[dualbus@dualbus ~]$ echo ~/a/aTAB [completes]
[dualbus@dualbus ~]$ echo ~/a/a\ a.txt
/home/dualbus/a/a a.txt
[dualbus@dualbus ~]$ echo
I think that the following text from the zshell's code is an interesting read
on the subject:
TL;DR: Another strategy is to migrate the while-loop to a child process the
moment that you hit ^Z, but, this is really hard (maybe impossible?) to do
correctly.
(From Src/exec.c)
/*
* [...]
*
* In
I was playing with the following scenario:
IFS set to backslash,
using read (with and without -r),
triggering field splitting by passing multiple names to read,
triggering field splitting by expanding an unquoted parameter.
And, I found the following results:
(note: the ones with a # something,
I think the issue here is the inconsistent behavior of read -t num when
delim != '\n'.
read -t 3 -d not-\n will *not* leave the input as typeahead.
read -t 3 -d $'\n'will leave the input as typeahead.
I tried playing with the 'unbuffered_read' variable in builtins/read.def
(forcing it to
Forgot to include mksh:
| dualbus@hp ~ % mksh -c 'read -t 3'
| afafafafafafa%
| dualbus@hp ~ % afafafafafafaRET
| zsh: command not found: afafafafafafa
| dualbus@hp ~ % mksh -c 'read -t 3 -d d'
| affafafafafafaf%
| dualbus@hp ~ % affafafafafafafRET
| zsh: command not found: affafafafafafaf
:-)
Description:
Log files are showing an increased level of buffer overflows from common
CLI usage and scripts that previously did not result in excessive overflows
being passed.
Can you show us a sample of these log files? Also the scripts that are causing
the issue.
Did you test against the current development version?
I'm not seeing that in 4.3:
dualbus@hp ~ % bash --version
GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
Here 'terminated' is related to shell syntax, as in: 'the command line is
terminated by the character'
You can terminate commands with ; \n ...
101 - 200 of 266 matches
Mail list logo
