I use startx
to start X which will evaluate my .xinitrc
. In my .xinitrc
I start my window manager using /usr/bin/mywm
. No
sleep infinity
looks most elegant, but sometimes it doesn't work for some reason. In that case, you can try other blocking commands such as cat
, read
, tail -f /dev/null
, grep a
etc.
What about sending a SIGSTOP to itself?
This should pause the process until SIGCONT is received. Which is in your case: never.
kill -STOP "$$";
# grace time for signal delivery
sleep 60;
Maybe this seems ugly, but why not just run cat
and let it wait for input forever?
This approach will not consume any resources for keeping process alive.
while :; do sleep 1; done & kill -STOP $! && wait $!
while :; do sleep 1; done &
Creates a dummy process in backgroundkill -STOP $!
Stops the background process wait $!
Wait for the background process, this will be blocking forever, cause background process was stopped beforetail
does not blockAs always: For everything there is an answer which is short, easy to understand, easy to follow and completely wrong. Here tail -f /dev/null
falls into this category ;)
If you look at it with strace tail -f /dev/null
you will notice, that this solution is far from blocking! It's probably even worse than the sleep
solution in the question, as it uses (under Linux) precious resources like the inotify
system. Also other processes which write to /dev/null
make tail
loop. (On my Ubuntu64 16.10 this adds several 10 syscalls per second on an already busy system.)
Read: I do not know any way to archive this with the shell directly.
Everything (even sleep infinity
) can be interrupted by some signal. So if you want to be really sure it does not exceptionally return, it must run in a loop, like you already did for your sleep
. Please note, that (on Linux) /bin/sleep
apparently is capped at 24 days (have a look at strace sleep infinity
), hence the best you can do probably is:
while :; do sleep 2073600; done
(Note that I believe sleep
loops internally for higher values than 24 days, but this means: It is not blocking, it is very slowly looping. So why not move this loop to the outside?)
fifo
You can create something which really blocks as long as there are no signals send to the process. Following uses bash 4
, 2 PIDs and 1 fifo
:
bash -c 'coproc { exec >&-; read; }; eval exec "${COPROC[0]}<&-"; wait'
You can check that this really blocks with strace
if you like:
strace -ff bash -c '..see above..'
read
blocks if there is no input data (see some other answers). However, the tty
(aka. stdin
) usually is not a good source, as it is closed when the user logs out. Also it might steal some input from the tty
. Not nice.
To make read
block, we need to wait for something like a fifo
which will never return anything. In bash 4
there is a command which can exactly provide us with such a fifo
: coproc
. If we also wait the blocking read
(which is our coproc
), we are done. Sadly this needs to keep open two PIDs and a fifo
.
fifo
If you do not bother using a named fifo
, you can do this as follows:
mkfifo "$HOME/.pause.fifo" 2>/dev/null; read <"$HOME/.pause.fifo"
Not using a loop on the read is a bit sloppy, but you can reuse this fifo
as often as you like and make the read
s terminat using touch "$HOME/.pause.fifo"
(if there are more than a single read waiting, all are terminated at once).
pause()
syscallFor the infinite blocking there is a Linux kernel call, called pause()
, which does what we want: Wait forever (until a signal arrives). However there is no userspace program for this (yet).
Create such a program is easy. Here is a snippet to create a very small Linux program called pause
which pauses indefinitely (needs diet
, gcc
etc.):
printf '#include <unistd.h>\nint main(){for(;;)pause();}' > pause.c;
diet -Os cc pause.c -o pause;
strip -s pause;
ls -al pause
python
If you do not want to compile something yourself, but you have python
installed, you can use this under Linux:
python -c 'while 1: import ctypes; ctypes.CDLL(None).pause()'
(Note: Use exec python -c ...
to replace the current shell, this frees one PID. The solution can be improved with some IO redirection as well, freeing unused FDs. This is up to you.)
How this works (I think): ctypes.CDLL(None)
loads the standard C library and runs the pause()
function in it within some additional loop. Less efficient than the C version, but works.
Stay at the looping sleep. It's easy to understand, very portable, and blocks most of the time.
while :; do read; done
no waiting for child sleeping process.