On 12/6/14 7:06 AM, Robert Clausecker wrote:
> Fix the way bash blocks the delivery of signals when it can't
> fork so keyboard interrupts or signals received otherwise still
> have a way to get through. Stop trying to fork after some
> attempts and provide a reasonable eme
On 12/6/14 6:24 PM, Stephane Chazelas wrote:
> Hiya,
>
> this is potentially dangerous:
>
> If $a was previously used as an array (or hash), then:
>
> declare a=$external_input
So what you're saying is that blindly using external input can sometimes
have negative consequences?
> (or:
> declare
Robert Clausecker wrote:
Description:
When an unreasonable low limit for the number of executable
processes (e.g. 2) is configured for bash,
Doctor -- when I cut the blood flow to my brain down to 2 cells/second,
I pass out and die. Is this a bug?
Good thing I'm not a bash mainta
Greg Wooledge wrote:
On Wed, Dec 03, 2014 at 06:51:08PM +0400, Gennady Kupava wrote:
That was quite unexpected for me as a user. I checked sed script like this:
echo "a
b"| sed '/a/!d'
And that implementation detail were highly unexpected... What is the point
of multiline edits if quotes are
Hiya,
this is potentially dangerous:
If $a was previously used as an array (or hash), then:
declare a=$external_input
(or:
declare -r a=$external_input
for instance (or -l...)... but not:
readonly a=$external_input
(or export)
)
becomes a code injection vulnerability:
$ b='($(uname>&2))' bash
This is well know, and not a bug. Please read:
http://mywiki.wooledge.org/BashFAQ/024
when you run:
command | while-loop
the 'while-loop' part is executed in a subshell (actually, both commands are).
This means that they're no longer the same process as the main shell, and the
consequence is tha
HI:
one way:
#!/usr/bin/bash
a=0
FILE="myfile.txt"
cat $FILE | while read line
do
a=$(($a+1))
echo $a
#done < $FILE
done
echo "Final line count is: $a
two way:
#!/usr/bin/bash
a=0
FILE="myfile.txt"
while read line
do
a=$(($a+1))
echo $a
done < $FILE
echo "Final line count is: $a"
On
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
On 11/25/14 4:31 PM, Boris Fersing wrote:
> Hi there,
>
> any idea when the patch provided
> here https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00031.html will
> be added to a release?
>
> I've tested it on 4.3.30 and it works.
It should be in the next set of released patches.
--
``Th
