Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.1k views
in Technique[技术] by (71.8m points)

bash - On writing a Linux shell script to safely detach programs from a terminal

I'm trying to write a Linux shell script (preferably bash), supposedly named detach.sh, to safely detach programs from a terminal, such that:

  1. Invocation: ./detach.sh prog [arg1 arg2 ...].

  2. Is exec-able, eg. by running this in your shell:

    exec ./detach.sh prog [arg1 arg2 ...]
    
  3. With proper quoting (mainly handling of arguments containing whitespaces).

  4. Discards the outputs (since they are unneeded).

  5. Does not use screen, tmux, etc. (same reason with 4, plus no need for an extra babysitting process).

  6. Uses (reasonably) portable commands and programs, and no things like start-stop-daemon which is quite distro-specific.

I have thought of several ways (shebang lines #!/bin/bash neglected for the sake of briefness):

  1. nohup:

    nohup "$@" >& /dev/null &
    
  2. disown:

    "$@" >& /dev/null &
    disown
    
  3. setsid:

    setsid "$@" >& /dev/null &
    
  4. Using a subshell:

    ("$@" >& /dev/null &)
    
  5. nohup/setsid combined with subshell:

    # Or alternatively:
    # (nohup "$@" >& /dev/null &)
    (setsid "$@" >& /dev/null &)
    

When using gedit as the test program (substituting the "$@" part), condition 1 can be satisfied with all the above methods, but condition 2 can be satisfied with none.

However, if an arbitrary program (but not a shell builtin) is appended to script 5, all the conditions seem to be satisfied (at least for me in the gedit case). For example:

(setsid "$@" >& /dev/null &)
# Not just `true' because it is also a shell builtin.
/bin/true

Anyone with an idea about an explanation of the above phenomenons and how to correctly implement the requirements?

EDIT:

With condition 2, I mean the program should be detached from the terminal but runs as usual otherwise. For example, with the gedit case, the condition fails if gedit just exits immediately right after the process of the script has ended.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

Upon closer investigation, these previously unnoticed facts were revealed:

  1. Both scripts 3 and 5 (the setsid variant only) will satisfy all the conditions if a /bin/true is appended to the script.

  2. These scripts, as modified in fact 1, will work as well if /bin/true is replaced with for i in {0..9999}; do :; done.

Therefore we can conclude that:

  • (From fact 1)

    Multiple levels of detaching (as in script 5) is unnecessary, and the key is to use the right utility (setsid).

  • (From fact 2)

    A suitable delay before bash exit is necessary for the success of the script. (Calling external program /bin/true consumes some time, just like the pure-bash time consumer for i in {0..9999}; do :; done.)

    I have not looked at the source code, but I guess a possible explanation is that bash may exit before setsid finishes configuring the execution environment of the program to run, if an appropriate delay is not applied.

And finally, an optimal solution should be

#!/bin/bash
setsid "$@" >& /dev/null &
sleep 0.01

EDIT 1:

The necessity of a delay has been explained here. Many thanks to @wilx!

EDIT 2:

(Thanks to @MateiDavid) we seem to have forgotten to redirect the standard input, and a better way would be:

#!/bin/bash
setsid "$@" >& /dev/null < /dev/null &

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

1.4m articles

1.4m replys

5 comments

57.0k users

...