Re: Bug? `set -e` inside functions inside `$(...)`

[John W]

Ah, got it sorted out.

Not a bug, of course (:

Bash, when not in posix mode, clears the '-e' flag in subshell environments.

On 10/3/19, John W  wrote:
> I'm seeing some strange behavior w/regard to `set -e` when invoking a
> shell function through a `$(...)` construct.
>
> I can't tell if it's a bug or not; the manpage doesn't really mention
> $() specially with regard to `set -e`, that I have found.
>
> I made a SO post with a bunch of details here:
> https://stackoverflow.com/questions/58228383/bash-set-e-reset-inside-functions-when-run-via
>
> But here's my small repro program:
>
> #!/usr/bin/env bash
>
> echo "Initial:$-"
> set -eu
> echo "After set:  $-"
>
> function foo() {
> echo "Inside foo: $-"
> }
> foo
>
> function bar() {
> false# I'd expect this to immediately fail
> echo "Inside bar: $-"
> }
> # When a $(...) construct is involved, 'bar' runs to completion!
> x=$(bar)
> echo "We should never get here ... but we do."
> echo "$x"
>
> For me, this ouputs:
>
> Initial:hB
> After set:  ehuB
> Inside foo: ehuB
> We should never get here ... but we do.
> Inside bar: huB
>
> and it's really the last two lines that confuse me. Why was 'set -e'
> disabled inside of "bar"?
>
> Is this documented behavior, and I missed it?
> Or a bug?
> Or makes sense under some interpretation of things that I'm not grasping?
>
> Thanks for any advice
> -John
>

Bug? `set -e` inside functions inside `$(...)`

[John W]

I'm seeing some strange behavior w/regard to `set -e` when invoking a
shell function through a `$(...)` construct.

I can't tell if it's a bug or not; the manpage doesn't really mention
$() specially with regard to `set -e`, that I have found.

I made a SO post with a bunch of details here:
https://stackoverflow.com/questions/58228383/bash-set-e-reset-inside-functions-when-run-via

But here's my small repro program:

#!/usr/bin/env bash

echo "Initial:$-"
set -eu
echo "After set:  $-"

function foo() {
echo "Inside foo: $-"
}
foo

function bar() {
false# I'd expect this to immediately fail
echo "Inside bar: $-"
}
# When a $(...) construct is involved, 'bar' runs to completion!
x=$(bar)
echo "We should never get here ... but we do."
echo "$x"

For me, this ouputs:

Initial:hB
After set:  ehuB
Inside foo: ehuB
We should never get here ... but we do.
Inside bar: huB

and it's really the last two lines that confuse me. Why was 'set -e'
disabled inside of "bar"?

Is this documented behavior, and I missed it?
Or a bug?
Or makes sense under some interpretation of things that I'm not grasping?

Thanks for any advice
-John

Re: Are there any plans for more readable, modern syntaxes for If statements?

[John W]

On 3/26/20, George  wrote:
> On Thu, 2020-03-26 at 19:05 +0200, Vaidas BoQsc wrote:
> I think shells would really benefit from things like
> more powerful data structures, better facilities for passing complex data
> to, and parsing complex data from different programs, better scoping,
> better file handling, and clean-up of various language and implementation
> details that currently tend to trip people up.

I can almost hear the same thoughts going through Larry Wall's head 30+
years ago (:

> $ some_command -file1 $fd1 -file2 $fd2 {fd1}<./first_file
> {fd2}<./second_file
>
> to work as a substitute for this:
>
> $ exec {fd1}<./first_file {fd2}<./second_file# open files, store file
> descriptor numbers in parameters
> $ some_command -file1 $fd1 -file2 $fd2
> $ exec {fd1}<&- {fd2}<&- # close files
>
> That is, open the files just for the command being run (because that's how
> redirections work) and make the parameters storing the file descriptor
> numbers available before expanding parameters in the command, so you can
> pass them to the command.

Are you familiar with Bash's <(...) syntax?
Your example could be written (if I understand right):

  $ some_command -file1 <(cat ./first_file) -file2 <(cat ./second_file)

Though that doesn't store the descriptors in variables.

Personally, I've found that I've grown into shell syntax over the years.
I certainly went through phases where it felt strange and clunky (and some
parts genuinely are, to be sure), but I have come to appreciate more of
the design choices and less-known features over time.

One day I may even read the entire manual page and understand it!