26

Open a tmux session and start the first command. Then launch more commands on new windows and evenly distribute the window sizes at the end. tmux \ new-session "command1 ; read" \; \ split-window "command2 ; read" \; \ split-window "command3 ; read" \; \ split-window "command4 ; read" \; \ select-layout even-vertical The read after each command ...


26

tmux new -d -s my-session 'echo window-1 pane-1; sleep 8' \; \ split-window -d 'echo window-1 pane-2; sleep 6' \; down-pane \; \ new-window -d 'echo window-2; sleep 4' \; next-window \; \ attach \; The above is a running example of the general idea ... more here: How to run streamripper and mplayer in a split-...


25

The term for what you're trying to accomplish is multiplexing. This can be accomplished fairly easily in bash, but it does require some more advanced bash features. I created a script based on your which I think does what you're trying to accomplish. I'll explain it below. #!/bin/bash manager() { while IFS= read -r line; do echo "manager[$1:$BASHPID]...


25

You could use a combination of GNU stdbuf and pee from moreutils: echo "Hello world!" | stdbuf -o 1M pee cmd1 cmd2 cmd3 > output pee popen(3)s those 3 shell command lines and then freads the input and fwrites it all three, which will be buffered to up to 1M. The idea is to have a buffer at least as big as the input. This way even though the three ...


22

This turned out to be caused by a race condition. cp checks if the destination file already exists, and if not - overwrites it. The problem was happening because this cp command was being run twice in parallel, which caused the file in question to sometimes appear after checking whether it exists, but before the attempt to create the file. The strace output ...


20

Using rsync is fairly safe on read-write mounted file systems. When rsync is started it builds up a file list and then starts to copy those files. This file list is not being updated during the run. The actual data is then copied. This means when a file changes after rsync has built the file list, it will copy the new content. However, when a new file is ...


15

This is not a dpkg-specific issue (as the title of my edit suggested). Rather, this is something that every package manager (of which I am aware) does; and for good reason. Though, I do understand why it might be confusing. Package managers rely on databases to track the information for installed packages. If multiple users attempt to write to a database at ...


13

Your redirections have a race condition. This: >(wc -l | awk '{print $1}' > n.txt) runs in parallel with: awk 'BEGIN{getline n < "n.txt"}...' later in the pipeline. Sometimes, n.txt is still empty when the awk program starts running. This is (obliquely) documented in the Bash Reference Manual. In a pipeline: The output of each command in the ...


13

This is a classic problem in concurrency: when allocating a resource, you need to atomically determine that the resource is free and reserve it, otherwise another process could reserve the resource between the time you check that it's free and the time you reserve it. Do use losetup's automatic allocation mode (-f), and pass the --show option to make it ...


9

The lock file is used to prevent parallel execution of multiple instances. Why is this important for a package managers? A package manager — from a high level view — is a program which applies complex changes to the hard disk. The changes cannot be done in one step (“atomic”), so there are multiple steps; many of the steps depend on the result of ...


9

The reading operation will succeed, regardless from the time it takes to complete the reading operation. Why and how does this work? When the reading operation starts, the file's Inode is used as a handle from which the file's content is read. When moving another file to the target file, the result will be a new inode, which means the physical content of ...


9

You may see foo displayed before bar, after bar, or even after the prompt, depending on timing. Add a little delay to get consistent timing: $ echo foo > >(sleep 1; cat); echo bar; sleep 2 bar foo $ bar appears immediately, then foo after one second, then the next prompt after another second. What's happening is that bash executes process ...


7

If you only want one instance of your app running you can use a lock file. Open it with O_CREAT|O_EXCL flags and it will fail if the file already exists. If you want to sychronize access to a file use flock. It is also possible to lock parts of files with fcntl. Flock is only for advisory locking meaning a program can ignore the locks and access it anyway. ...


7

If it's always the same configuration of programs, you can use a tool like teamocil. You'll need to create with a configuration (e.g. ~/.teamocil/sample), which contains something like: windows: - name: my-first-window root: ~/Projects/foo-www filters: before: "rvm use 1.9.2" after: "echo 'I am done initializing this split.'" ...


7

In short: Yes, simultaneous writes from multiple NFS clients will be corrupted. Simultaneous appends locally are nicely interleaved, since the OS knows the file is opened in append mode, and atomically seeks to the current end of file before each write call, regardless of other processes that may have extended the file in the meanwhile. But on NFS, no ...


7

When a file is opened in append mode, the OS guarantees that all writes take place at the end. So the data from one writer will not overwrite the data from another writer. This only applies if the file is opened in append mode, i.e. with >> in the shell. If the creator of the file opens it with > then that guarantee won't apply and it's possible to ...


6

With gnome-terminal it would be: gnome-terminal --window -e 'cmd1' --tab -e 'cmd2' --tab -e 'cmd3' Each tab will be closed after its command is finished.


5

pipe expression in process substitution causes a race condition in bash and ksh, zsh doesn't. The main problem here is that zsh waits, bash doesn't. You can see more details here. A quick fixed, adding sleep 1 in your awk to make n.txt always available: awk 'BEGIN{system("sleep 1");getline n < "n.txt"};{print $1 "\t" $1/n*100 "\t" $2}'


5

Yes, that's a race condition. The problem is that the shell starts all processes in the pipeline at the same time and tee truncates the output file on startup. If tee is faster then comm the file is empty for comm otherwise it is not. The pipeline behaviour can be seen if you run this several times (mabe in a loop): date '+first: %T'|(cat>&2;...


5

I figured it out. While I am not sure how the issue with the permission thing is, I can instead shoot first and ask later like this: sudo losetup -f myfile.img ld=$(losetup -j myfile.img | grep -o "/dev/loop[0-9]*") dostuffwith $ld


5

In a word, "no" :-) Linux tar will not stop any other process from reading the files while it is running. If you are concerned about writing the tar doesn't block that either, but if a file changes while tar is reading it then you'll get a warning message; if the directory structure changes while tar is in the middle of it then you might see some oddities ...


5

Look at standards such as POSIX for portability guarantees. In practice, most POSIX-compliant systems have minor deviations from the specifications, but generally speaking you can rely on the guarantees given in the specification. Most modern unices comply with the specification even if they haven't been formally tested. They may need to be run in a POSIX ...


5

No. If you add a file after tar has scanned a directory, the file will not be added. If a file has been added to the archive but you delete it on disk, it won’t be removed from the archive. This applies also if you change content. One thing Unix (not tar) will do: If a file is opened (for editing) when tar gathers it, you will not know what version of ...


5

The shells have little involvement there. All they do is create the pipe and start those 3 commands which then run in parallel independently from the shell. What matters here is that both tail commands write to a file descriptor to the same writing end of the same pipe. If you do: printf foo1 >> file1; sleep 1 printf foo2 >> file2; sleep 1 ...


4

sync does everything dirsync does, plus more. Unfortunately this 'more' is a significant performance penalty. With sync enabled, all disk I/O is immediately written to disk. With dirsync, only directory operations are immediately written. The only case I've seen where one might want to use dirsync instead of sync is in the case of network filesystems. When ...


4

Simply adding an ampersand to the end of each line will fork all the commands into the background. cmd1 & cmd2 & cmd3 & Example $ more at_once.bash #!/bin/bash echo "1" && sleep 10 & echo "2" && sleep 10 & echo "3" && sleep 10 & pgrep -a sleep Now when we run this script: $ ./at_once.bash 1 3 2 7533 ...


4

This should work for a bash script. It will abort execution of the script if another instance of the external software was found. The key here is `pidof. #!/bin/bash # Abort startup if another instance was found pidof /path/to/software.executable > /dev/null && { echo Sorry. Only one instance allowed. exit } Alternatively you could use ...


4

If you need to save the intermediate file after the processing is done, then inter-process communication (such as through a pipe or socket) is not particularly valuable.  Similarly, if you need to run the two programs at vastly different times, you should just do it the way you're doing it now. Back when Unix was created, disks were very small, and it was ...


4

1. tar will not screw up something on the source dir/subdirs True, unless you count updating access times as screwing up. Other than that, tar doesn't change anything in the source tree. 2. tar will add to archive as it found in the moment of building archieve True, for some value of “in the moment”. If the source tree changes while tar is reading it, ...


4

This kills the background process before the script exits: trap '[ "$pid" ] && kill "$pid"' EXIT function repeat { while :; do echo repeating; sleep 1 done } repeat & pid=$! echo running once How it works trap '[ "$pid" ] && kill "$pid"' EXIT This creates a trap. Whenever the script is about to exit, the commands in ...


Only top voted, non community-wiki answers of a minimum length are eligible