Re: Bug#519165: [Fwd: Bug#519165: bash 4 regression]

2009-07-06 Thread martin f krafft
also sprach Chet Ramey [2009.07.03.1952 +0200]: > There is, in fact a de facto standard, but the bash4 behavior is > what the Bourne and Korn shells have always done. In fact, the only > way Martin's statement is true is if "all other shells" means "dash", > since that's the only other shell I fo

Re: ulimit -p incorrect on linux (and besides being low, probably unenforceable(?))

2009-07-06 Thread Chet Ramey
Linda Walsh wrote: > Chet Ramey wrote: >> Linda Walsh wrote: >>> When under linux (2.6.30.x), I type >>> ulimit -p and get a return value of "8". >>> >>> from the man page this is in 512-byte blocks and may not be set. >> >> It's set at build time. Look at builtins/ulimit.def:pipesize() and >> bui

Re: $\n doesn't get expanded between double-quotes

2009-07-06 Thread Greg Wooledge
On Fri, Jul 03, 2009 at 01:01:47PM -0400, Chris F.A. Johnson wrote: > NL=$'\n' > string="This is a$NLmulti-line$NLstring" Of course you would need curly braces for that. NL=$'\n' string="This is a${NL}multi-line${NL}string"

Re: ulimit -p incorrect on linux (and besides being low, probably unenforceable(?))

2009-07-06 Thread Linda Walsh
Chet Ramey wrote: Linda Walsh wrote: When under linux (2.6.30.x), I type ulimit -p and get a return value of "8". from the man page this is in 512-byte blocks and may not be set. It's set at build time. Look at builtins/ulimit.def:pipesize() and builtins/psize.sh (which uses builtins/psize.c