Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Noilson Caio
thank you On Mon, Mar 20, 2017 at 4:03 PM, Greg Wooledge wrote: > On Mon, Mar 20, 2017 at 03:54:37PM -0300, Noilson Caio wrote: > > thank you so much Mr. Wooledge. i guess that BUG is a strong word for > this > > case. i fully agree about "his is not a bash bug. It's a problem with > your > > a

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Greg Wooledge
On Mon, Mar 20, 2017 at 03:54:37PM -0300, Noilson Caio wrote: > thank you so much Mr. Wooledge. i guess that BUG is a strong word for this > case. i fully agree about "his is not a bash bug. It's a problem with your > approach.", actuality that's my preoccupation. can you help me to > understand

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Chet Ramey
On 3/20/17 2:54 PM, Noilson Caio wrote: > i have afraid that a non-root user can > compromise a linux box intentionally. the memory needs be eaten until other > threshold can break it. This is why per-process resource limits exist. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Noilson Caio
thank you so much Mr. Wooledge. i guess that BUG is a strong word for this case. i fully agree about "his is not a bash bug. It's a problem with your approach.", actuality that's my preoccupation. can you help me to understand because 10^6 strings pull the trigger of "Argument list too long" and

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread John McKown
On Mon, Mar 20, 2017 at 10:17 AM, Noilson Caio wrote: > 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-redhat

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Greg Wooledge
On Mon, Mar 20, 2017 at 12:17:39PM -0300, Noilson Caio wrote: > 1 - Using mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ - ( 5 levels ) No > problems 10 to the 5th power (100,000) strings generated. Sloppy, but viable on today's computers. You're relying on your operating system to allow an extrao

Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Noilson Caio
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-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -