In Bash blocks {} and subshells () the exit early doesn't work if there is an OR condition following it. Take for example

set -e
{ echo a; false; echo b; } || echo c

prints

a
b

and

set -e
{ echo a; false; echo b; false;} || echo c

prints

a
b
c

It seems to take the last executed command's exit code only. While this makes sense, given a semicolon instead of && is used, I'd expect the set -e to still make it exit on the first false and execute the error handling echo c code. Using && instead of ; does make it work, but that makes it messy when having multiple line blocks. Adding in set -e at the start of the block/subshell also has no effect. The reason this confuses me is because

set -e
{ echo a; false; echo b; }

prints

a

which means the exit-on-failure works when there's no || code following it. So I'd expect this to be the case with || code following it, executing it after the first failure in the block. Is there no way to achieve that without appending && after each line in the block?

In bash, I want to assign my current working directory to a variable. Using a subshell, I can do this. var=$(pwd) echo $var /home/user.name If I use process substitution like so: var=<(pwd) echo $var /dev/fd/63 I have understood that process substitution is primarily used when a program does not accept STDIN. It is unclear to me what a process substitution exactly does and why it assigns /dev/fd/63 to var.

I'm experiencing extremely sluggishness in opening subshells (by using \ \ or $( ) command substitutions in scripts) while in ksh on some Linux servers. The same problem does not exist in sh or any other shell. strace indicates that the time is due to stat and openat calls against randomly named files in /tmp. **test.sh**: echo expr 1 + 1 **command**: strace -tttT ksh test.sh **output**: . . .[snipped]. . . 1734368858.571604 stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=708608, ...}) = 0 1734368859.184765 geteuid() = 1001 1734368859.184851 getegid() = 1002 1734368859.184879 getuid() = 1001 1734368859.184913 getgid() = 1002 1734368859.184946 access("/tmp", W_OK|X_OK) = 0 1734368859.185012 getpid() = 210594 1734368859.185055 openat(AT_FDCWD, "/tmp/sf0p.si0", O_RDWR|O_CREAT|O_EXCL, 0666) = 1 1734368860.771539 unlink("/tmp/sf0p.si0") = 0 . . . Between stat and openat, my simple invocation of expr 1 + 1 **took more than 2 seconds of time.** Questions: 1. Why is ksh creating files in /tmp, whereas none of the other shells (sh, bash, csh) do that? 2. How do I start diagnosing why these operations would take 1-2 seconds? Server in question is at version: Linux 5.4.17-2136.322.6.4.el8uek.x86_64 (distribution Oracle Linux Server release 8.9). Ksh is version AJM 93u+ 2012-08-01 **Update:** We've seen some artifacts of python creating empty directories under /tmp, which a few days ago I found to number 10,000 subdirs under /tmp. I deleted them all but it did not help performance. Forgive my lack of Unix knowledge, but am I right in assuming that once the directory inode is enlarged to list such an extensive # of subdirs/files, deleting those doesn't shrink the directory inode itself, but leaves a sparse structure that still has to be scanned through by all file accesses? The inode size of my /tmp (ls -ld /tmp) is currently 708KB. That's 172x larger than the starting size of 4096 bytes. Could that be what's slowing down stat and openat calls that hit /tmp ?

This command is a simplification of the problem I've come across: ssh grinder1h.devqa sh -c "cd /etc/ssh && pwd" This command gives an output of ***"/home/fetch"***, which is the remote user's home directory. I would expect the output to be ***"/etc/ssh"***, as the "cd" should run in the same shell as "pwd", and so should affect its output. In fooling around, I tried this command: ssh grinder1h.devqa sh -c "pwd && cd /etc/ssh && pwd" This command produces ***"/home/fetch"*** followed by ***"/etc/ssh"***, which is the expected output. So for this command, the first sub-command produces a result, and somehow affects the remaining sub-commands. It turns out that I can add any subcommand to the front of this command to cause the remaining parts of the command to work correctly. So this command produces ***"/etc/ssh"***, the desired result: ssh grinder1h.devqa sh -c "X=1 && cd /etc/ssh && pwd" So my question is, why does adding "X=1" to the front of this command affect its output? I could add any number of examples that act strangely. They all suggest that the first part of my remote command is either not being executed at all, or its effects are ignored. What am I missing? In case it matters, the client machine is a Mac, the remote host is running Alma Linux 9.5, and doing "sh --version" on the remote host produces this version info: GNU bash, version 5.1.8(1)-release (x86_64-redhat-linux-gnu)

I have a Debian 12 (bookworm) host where I run three VMs using QEMU / KVM. To simplify VM management, each VM has a QEMU monitor socket. These sockets are /vm/1.sock, /vm/2.sock and /vm/3.sock. Among others, I can use such a socket to gracefully shutdown the respective VM; the command would be something like that:

printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/1.sock

So far, so good. This works as expected for each of the three VMs / sockets. Now I have a script that needs to shut down all of these VMs, where no delay must occur if one of the shutdown commands hangs or takes a long time. That means that I have to execute the command line shown above in the background. The respective part in the original version of that script is:

{ printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/1.sock; } &
{ printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/2.sock; } &
{ printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/3.sock; } &

Apart from the fact that this produces weird output (because the commands are executed asynchronously and their outputs are interleaved), it does not work as intended. **It shuts down one of the VMs, but not the other two.** During my tests, it was always VM #2 that got shut down, but I believe that this is pure random. [ Side note: VM #2 takes only 3 seconds or so to actually shut down, while VM #1 and VM #3 take 10 seconds or so; this *may* be the reason why it's always VM #2 that gets shut down. But let's put that aside for the moment; I wouldn't be able to explain it anyway and still believe that it's random that it's only VM #2 that gets shut down. ] Then I changed the passage shown above in the following way:

( printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/1.sock ) &
( printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/2.sock ) &
( printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/3.sock ) &

Of course, this version also produces weird output, **but otherwise works; it reliably shuts down all of the three VMs.** While I am glad to have a working solution, I would like to understand the matter. After having re-visited the relevant parts of the bash manual, I believe that both versions should shut down all VMs, but this is not the case. Why does the second version work, while the first version doesn't? Of course, I have read some similar questions on this site and elsewhere that deal with executing commands or pipes in background. From this research I got the impression that both variants should work. Some answers also proposed to move the & into the braces, like that:

(printf "%s\n" 'system_powerdown' | socat - unix-connect:/vm/1.sock &)

But I haven't tried that yet because I first would like to understand the difference between the first and the second version shown above.

there is a script, 1.sh. 1.sh starts 1a.sh and then 1b.sh. But how to exit all scripts, how to exit 1.sh and how to not start 1b.sh if 1a.sh breaks with an error?

Contrived example: #!/usr/bin/bash MYVAR=$(cat /somedir | grep -i myval) Now I want: #!/usr/bin/bash BASEDIR=/somedir MYVAR=$(cat [BASEDIR?] | grep -i myval) How should variable be passed to subshell?

About bash For a new _tty_ when is executed the echo $SHLVL command it displays 1 as expected. Now, if in the same _tty_ is executed the bash command and later again the echo $SHLVL command it displays 2. Is mandatory use the exit command to exit of course. Furthermore I did do realize that each bash has its own _history command_ and the user is interacting or has access in the current bash. So far, after to did do a research it seems _it is a kind of subshell_ (correct me if I am wrong), it because mostly a subshell is created through the () approach instead. Just as playing I executed the bash cat /etc/os-release command and nothing is printed. Therefore *being curious* **Question** * How does bash work? As _extra question_: * Under what circumstances the bash approach would be mandatory to be applied? **Observation** In the answer was indicated to expect an error message. Well, the error mentioned is correct (tested on Ubuntu and Fedora) but in my case the bash cat /etc/os-release command was applied as an argument to create a docker container based on Linux and none error was shown as indicated from the beginning and it was the reason to create this post. Well it is other history

The command df . can show us which device we are on. For example, me@ubuntu1804:~$ df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 61664044 8510340 49991644 15% /home Now I want to get the string /dev/sdb1. I tried like this but it didn't work: df . | read a; read a b; echo "$a", this command gave me an empty output. But df . | (read a; read a b; echo "$a") will work as expected. I'm kind of confused now. I know that (read a; read a b; echo "$a") is a subshell, but I don't know why I have to make a subshell here. As my understanding, x|y will redirect the output of x to the input of y. Why read a; read a b; echo $a can't get the input but a subshell can?

I understand that when I run exit it terminates my current shell because exit command run in the same shell. I also understand that when I run exit & then original shell will not terminate because & ensures that the command is run in sub-shell resulting that exit will terminate this sub-shell and return back to original shell. But what I do not understand is why commands with and without & looks exactly the same under pstree, in this case sleep 10 and sleep 10 &. 4669 is the PID of bash under which first sleep 10 and then sleep 10 & were issued and following output was obtained from another shell instance during this time: # version without & $ pstree 4669 bash(4669)───sleep(6345) # version with & $ pstree 4669 bash(4669)───sleep(6364) Should't the version with & contain one more spawned sub-shell (e.g. in this case with PID 5555), like this one? bash(4669)───bash(5555)───sleep(6364) PS: Following code was omitted from output of pstree beginning for better readability: systemd(1)───slim(1009)───ck-launch-sessi(1370)───openbox(1551)───/usr/bin/termin(4510)───bash(4518)───screen(4667)───screen(4668)───

You can give a Flatpak permissions to access files/folders outside of its sandbox using the techniques described in this Ubuntu Stack Exchange QA . **But is it possible to give an existing Flatpak application permission to run another Flatpak application?** The catch here (which is a bit of a Catch-22 ) is that to run a Flatpak application, the flatpak executable needs to be run, and it is typically located in /bin or /usr/bin. And /bin is reserved path, according to the Flatpak documentation . Thus, a Flatpak application cannot call flatpak itself unless it is stored somewhere atypical, which could, in theory, violate the effectiveness of its sandboxing functionality. So is it possible or impossible to give an existing Flatpak application permission to run another Flatpak application?