On Tue, Apr 10, 2012 at 16:38, Elliott Forney wrote:
> On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont
> wrote:
> > People should stop trying to execute code by parameter expansion, and
> specifically stop thinking that parameter-expanded words are evaluated as
> bash code.
>
> I still think t
On Tue, Apr 10, 2012 at 12:04:36PM -0400, Chet Ramey wrote:
> You're calling the error trap twice. The first time you call it is after
> the `false' in the body of the function, and the `return' works as intended
> there. Since you return 1, the call to `somefunc' fails, triggering the
> error tr
Thanks for getting back to me, Chet. The theory about the kernel's handling
of a full input queue seems likely. In the case of bash + readline, would
it be feasible to avoid readline changing the terminal settings while
reading a here document? Seems like the only remedy if the kernel is
misbehavin
On 4/10/12 1:22 PM, George Nachman wrote:
> Thanks for getting back to me, Chet. The theory about the kernel's handling
> of a full input queue seems likely. In the case of bash + readline, would
> it be feasible to avoid readline changing the terminal settings while
> reading a here document? Seem
On 6/13/11 1:45 AM, George wrote:
> I'm the maintainer of a terminal emulator on Mac OS and a user
> reported that if he pastes a large string of the form:
>
> cat << EOF > whatever.txt
> blah blah blah
> blah blah blah
> ... etc for 100k ...
> EOF
>
> That the output is badly mangled. I can repr
On 2/15/12 7:51 PM, dave reisner wrote:
> Hi all,
>
> I'm noticing some odd behavior in an ERR trap with errtrace. It's
> present in bash 3.2 and as well as 4.2. The simplest reproduction is
> as follows:
>
> --8<--
> #!/bin/bash
>
> somefunc() {
> false
> echo "shoul
On 4/10/12 12:22 AM, Elliott Forney wrote:
> My two cents, would be to add a bit to the man page that says something like:
>
> ---
> For historical reasons, the following format is also supported for
> arithmetic evaluation:
>
> $[expression]
>
> Note, however, that this format is non-standa
On 4/10/12 3:33 AM, Maarten Billemont wrote:
> If we were to move to $[ ... ]
But we're not. It's ludicrous to think we would. How far down the rabbit
hole are we going to go on this?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' -
On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont wrote:
> People should stop trying to execute code by parameter expansion, and
> specifically stop thinking that parameter-expanded words are evaluated as
> bash code.
I still think the behavior is interesting. The statement may not be
empty b
On 10 Apr 2012, at 08:26, Barry Margolin wrote:
>
> if [ $status = 0 ]
As an aside, I don't think it's a good idea to recommend comparing numbers
using string comparison operators.
if (( status == 0 ))
But if you wanted to treat them as strings for the sake of code simplicity,
just go the cas
On 09 Apr 2012, at 11:46, Linda Walsh wrote:
>
> Like it costs how much? I would **bet** that it cost more code to support
> (()) than to support [] as arith ops .. so if you want my opinion, lets toss
> (())...
> (like that'll happen)...
Just thought I'd add that I personally prefer $((...))
On 10 Apr 2012, at 06:03, Elliott Forney wrote:
> Here is another example that appears to defy my expectations. In this
> case, the semicolon is allowed:
>
> sine:~$ hello='echo hello'
> sine:~$ world='echo world'
> sine:~$ ${hello};${world}
> hello
> world
> sine:~$ unset hello
> sine:~$ ${hello
12 matches
Mail list logo
