Re: BUG??

[PePa]

Of course... My own stupidity.

It did raise the question for me, what would be the recommended way to
'group' expressions, where other languages would use brackets, like:

if (((q==1)) || [[ $r ]]) && grep -q $s $file
then
  echo "$s is in $file, and either q is 1 or r is not empty"
fi

I guess this works, but it spawns a subshell. Is there a better way?

Thanks,
Peter


On 29/12/2559 08:38, Chet Ramey wrote:
> On 12/28/16 8:09 PM, Peter & Kelly Passchier wrote:
>> Is this a bug? These both output "q=1"
>>
>> q=1
>> [[ ((q==1)) ]] && echo q=1
>>
>> q=0
>> [[ ((q==1)) ]] && echo q=1
>>
> 
> No. These both end up checking whether the length of the string "q==1" is
> non-zero, which it is.
> 

Re: BUG??

[Greg Wooledge]

On Thu, Dec 29, 2016 at 09:43:54PM +0700, PePa wrote:
> if (((q==1)) || [[ $r ]]) && grep -q $s $file
> then
>   echo "$s is in $file, and either q is 1 or r is not empty"
> fi
> 
> I guess this works, but it spawns a subshell. Is there a better way?

What you're literally asking for should be done with command grouping
instead of a subshell:

if { ((q==1)) || [[ $r ]] ; } && grep -q "$s" "$file"; then ...

But my personal preference would be to rewrite it for readability:

if ((q==1)) || [[ $r ]]; then
  if grep -q "$s" "$file"; then
...
  fi
fi

Re: [Help-bash] Bash Trap: How to Get Line Number of a Subprocess with Non-Zero Status

[Eduardo Bustamante]

On Thu, Dec 29, 2016 at 11:20 AM, Steve Amerige  wrote:
> I've posted a question to StackOverflow, but I'm hoping the experts here can
> chime in.
>
> http://stackoverflow.com/questions/41346907/bash-trap-how-to-get-line-number-of-a-subprocess-with-non-zero-status
>
> In essence, I want to know how to get the line number in a function of a
> subprocess that exits with a non-zero status (see line 20 below):
[...]
> Thanks,
> Steve Amerige

First: Try to do better formatting on your emails next time. The code
block is completely unreadable. I had to follow the stackoverflow link
to understand what you were asking.


I'm adding the bug-bash list, since I think this is actually a bug in
the parse_comsub function, or maybe in execute_command_internal. I
haven't been able to figure it out yet. What I do know is that these
two should behave the same:

dualbus@yaqui:~$ cat -n h
 1  #!/bin/bash
 2  shopt -s extdebug
 3  main() {
 4  trap 'echo $LINENO' ERR
 5  (exit 17)
 6  }
 7  main
dualbus@yaqui:~$ ./h
3

--- vs ---

dualbus@yaqui:~$ cat -n i
 1  #!/bin/bash
 2  shopt -s extdebug
 3  main() {
 4  trap 'echo $LINENO' ERR
 5  `exit 17`
 6  }
 7  main
dualbus@yaqui:~$ ./i
5

There's no actual reason for these two to be different, and this leads
me to think the behavior you're seeing is a bug somewhere in the
$(...) style command substitution parsing. Perhaps it misses updating
the line_number variable.