skel/.config/bunsen/autostart: replace round brackets with curly brackets? about bunsen-configs HOT 4 CLOSED

@ohnonot thank you for looking at the code, and for your suggestion.
I'm not quite sure, though, whether the use of curly brackets will actually make the difference the manuals suggest. skel/.config/bunsen/autostart is run from sh not bash, and the following tests were done in a shell (dash) environment, launched from a bash terminal (hence the bash process). However, the same results were seen running in bash too, ie there are two shells running in both cases:

$ ( sleep 2; echo OK; ) & ps
  PID TTY          TIME CMD
15071 pts/1    00:00:00 bash
15305 pts/1    00:00:00 sh
15791 pts/1    00:00:00 sh
15792 pts/1    00:00:00 ps
15793 pts/1    00:00:00 sleep
[1] - Done                       (sleep 2)
$ OK

[2] + Done                       (sleep 2; echo OK)
$ { sleep 2; echo OK; } & ps
  PID TTY          TIME CMD
15071 pts/1    00:00:00 bash
15305 pts/1    00:00:00 sh
15809 pts/1    00:00:00 sh
15810 pts/1    00:00:00 ps
15811 pts/1    00:00:00 sleep
$ OK

[1] + Done                       sleep 2; echo OK

Also try these variants:

( ( sleep 2; echo OK ) ) & ps
( ( sleep 2; echo OK ) & ) & ps
{ { sleep 2; echo OK;} ;} & ps
{ { sleep 2; echo OK;} & } & ps

They all start the same number of processes.

Related:
https://unix.stackexchange.com/questions/127334/bash-subshell-creation-with-curly-braces
https://unix.stackexchange.com/questions/267660/difference-between-parentheses-and-braces-in-terminal/267661

So let's think about this a bit.

from bunsen-configs.

The first article uses examples with pipes; those create subshells alright.
But that's not what I'm talking about.

The accepted answer from the second article seems to confirm what I'm saying, but also what you're saying - maybe this statement:

Parentheses cause the commands to be run in a subshell.
Braces cause the commands to be grouped together but not in a subshell.

is to be seen in terms of shell functionality only, and not resource usage.

I didn't consider Debian's /bin/sh is linked to dash (something I also did now btw), which certainly makes a difference performance-wise, but the logic should be the same... again, as you observed.

I still believe curly braces would set a better example for aspiring hackers, but one should have something to back that up with. Still researching...

from bunsen-configs.

maybe this statement:

Parentheses cause the commands to be run in a subshell.
Braces cause the commands to be grouped together but not in a subshell.

is to be seen in terms of shell functionality only, and not resource usage.

That's how it looks to me - a saving in child processes looks hard to achieve, but there is a difference in things like variable scope when running in a subshell. That difference might be desirable, or not, depending on the particular case.

Of course, in the case of a simple process launch, needing no sleep, there is no question of wanting a subshell command & so indeed it seems reasonable to ask why we should need one when adding a delay, except that that has become the norm.

And, in the second article:

if you are interested in specific aspects, be careful and check your shell for its actual behavior

Switching from bash to dash can bring a substantial speed gain if the extra bash features can be lived without. I always try to use #!/bin/sh for system scripts, for portability. There are sometimes subtle catches though.

I still believe curly braces would set a better example for aspiring hackers, but one should have something to back that up with.

autostart is a user-editable file, so that's a valid point. Such files should be:
*) easy to read and understand, and
*) provide a good template for copying.
But as you say, we ought to have something substantial to point to before making such an unconventional (compared with what others are using) change.

from bunsen-configs.

Lacking any more evidence that switching to { } would bring any tangible benefits, let's stay with the conventional ( ) for now.

from bunsen-configs.