셸에서 애플리케이션을 "올바르게" 시작하는 방법

Question 1

프로그램을 실행하고 터미널에서 분리하는 방법에는 여러 가지가 있습니다. 하나는 백그라운드에서 실행하는 것입니다.서브쉘, 다음과 같이( firefox좋아하는 프로그램으로 교체):

(firefox &)

다른 하나는 프로세스를 거부하는 것입니다.

firefox & disown firefox

애플리케이션 런처 작동 방식이 궁금하신 경우 dmenu바이너리 1개와 셸 스크립트 2개( dmenu, , dmenu_path) 를 제공해 주세요 dmenu_run.

dmenu_run의 출력을 dmenu_pathdmenu로 파이프하면 $SHELL설정한 변수로 파이프됩니다. 비어 있으면 사용됩니다 /bin/sh.

#!/bin/sh
dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &

dmenu_path약간 복잡하지만 간단히 말해서 $PATH환경 변수에 바이너리 목록을 제공하고 가능한 경우 캐싱을 사용합니다.

#!/bin/sh
cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
if [ -d "$cachedir" ]; then
        cache=$cachedir/dmenu_run
else
        cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
fi
IFS=:
if stest -dqr -n "$cache" $PATH; then
        stest -flx $PATH | sort -u | tee "$cache"
else
        cat "$cache"
fi

프로그램을 쉘에서 실행할 필요는 없습니다. 셸에 연결하지 않고 작성하는 또 다른 방법은 다음 dmenu_run과 같습니다.

#!/bin/sh
$(dmenu_path | dmenu "$@") &

Answer

프로그램을 실행하고 터미널에서 분리하는 방법에는 여러 가지가 있습니다. 하나는 백그라운드에서 실행하는 것입니다.서브쉘, 다음과 같이( firefox좋아하는 프로그램으로 교체):

(firefox &)

다른 하나는 프로세스를 거부하는 것입니다.

firefox & disown firefox

애플리케이션 런처 작동 방식이 궁금하신 경우 dmenu바이너리 1개와 셸 스크립트 2개( dmenu, , dmenu_path) 를 제공해 주세요 dmenu_run.

dmenu_run의 출력을 dmenu_pathdmenu로 파이프하면 $SHELL설정한 변수로 파이프됩니다. 비어 있으면 사용됩니다 /bin/sh.

#!/bin/sh
dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &

dmenu_path약간 복잡하지만 간단히 말해서 $PATH환경 변수에 바이너리 목록을 제공하고 가능한 경우 캐싱을 사용합니다.

#!/bin/sh
cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
if [ -d "$cachedir" ]; then
        cache=$cachedir/dmenu_run
else
        cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
fi
IFS=:
if stest -dqr -n "$cache" $PATH; then
        stest -flx $PATH | sort -u | tee "$cache"
else
        cat "$cache"
fi

프로그램을 쉘에서 실행할 필요는 없습니다. 셸에 연결하지 않고 작성하는 또 다른 방법은 다음 dmenu_run과 같습니다.

#!/bin/sh
$(dmenu_path | dmenu "$@") &

Question 2

나는 G-Man의 답변을 정말 좋아합니다. 하지만 귀하의 우려가 혼란스러울 것 같아 답변을 드립니다. Wayne이 지적했듯이 가장 좋은 대답은 "원하는 결과를 얻는 것이 무엇이든"입니다.

Unix 프로세스 관리에서 각 프로세스에는 상위 프로세스가 있습니다. 유일한 예외는 init시작 시 운영 체제에 의해 시작되는 프로세스입니다. 부모 프로세스가 종료될 때 모든 자식 프로세스를 가져가는 것은 정상적인 동작입니다. 이는 모든 하위 프로세스에 SIGHUP 신호를 전송하여 수행됩니다. SIGHUP의 기본 처리는 프로세스를 종료합니다.

사용자 프로세스에 대한 쉘 생성은 작성한 코드와 다르지 않습니다.포크(2)/실행(3)원하는 언어로 전화하세요. 셸은 상위 프로세스이며, 셸이 종료되면(예: 로그아웃) 생성된 하위 프로세스도 마찬가지입니다. 설명하는 미묘한 차이점은 해당 동작을 수정하는 방법일 뿐입니다.

exec /path/to/program전화를 거는 것처럼실행(3). 예, program상위 실행 쉘을 유지하면서 쉘을 으로 대체합니다 .

sh -c /path/to/program.program /path/to/program( sh /path/to/script.sh하위 쉘에서 실행 권한이 부족한 쉘 스크립트를 실행하는 데 사용할 수 있음)

/path/to/program"포그라운드" 프로세스를 생성합니다. 즉, 쉘은 다른 작업을 수행하기 전에 프로세스가 완료될 때까지 기다립니다. 시스템 호출 컨텍스트에서는 다음과 같습니다.포크(2)/실행(3)/프로세스를 기다리는 중(2). 하위 프로세스는 상위 프로세스로부터 stdin/stdout/stderr을 상속받습니다.

/path/to/program &(리디렉션 무시) "백그라운드 프로세스"를 만듭니다. 프로세스는 여전히 셸의 하위 프로세스이지만 상위 프로세스는 프로세스가 종료될 때까지 기다리지 않습니다.

nohup /path/to/program옮기다노스햅(1)program제어 터미널이 닫혀 있으면 SIGHUP이 전송되지 않도록 합니다. 전경 또는 배경 중 하나는 옵션입니다(대부분 프로세스가 배경에 있음에도 불구하고). nohup.out다른 방식으로 표준 출력을 리디렉션하지 않으면 이는 단지 출력일 뿐입니다.

프로세스를 백그라운드에 넣을 때 상위 프로세스가 종료되면 두 가지 중 하나가 발생합니다. 부모라면제어 터미널, 그러면 SIGHUP이 어린이에게 전송됩니다. 그렇지 않은 경우 프로세스는 "고아"가 되어 init프로세스에 의해 상속될 수 있습니다.

입력/출력/오류를 리디렉션할 때 각 프로세스가 소유한 파일 설명자를 상위 프로세스에서 상속된 파일이 아닌 다른 파일에 연결하기만 하면 됩니다. 이 중 어느 것도 프로세스 소유권이나 트리 깊이에 영향을 미치지 않습니다(그러나 3개 프로세스 모두를 터미널에서 백그라운드 프로세스로 리디렉션하는 것은 항상 의미가 있습니다).

하지만 프로세스 관리와 관련된 특정 문제를 해결하지 않는 한 쉘, 서브쉘 또는 하위 프로세스의 프로세스 생성에 신경써서는 안 된다고 생각합니다.

Answer