☰

실행 파일을 설치하는 방법

tag-icon • tag-icon software-installation gnome3 executable
실행 파일을 설치하는 방법

.deb가끔 제공되지 않거나 .rpm실행 파일로만 제공되는 소프트웨어를 발견합니다 .
예를 들어비주얼 스튜디오 코드,사이버 폭풍또는커발 우주 프로그램.

이 질문에서는 Visual Studio Code를 참조점으로 사용하겠습니다.

소프트웨어는 압축된 패키지로 제공됩니다. 압축을 풀면 이라는 실행 파일이 포함
된 폴더가 남습니다 . 터미널을 두 번 클릭하거나 가리키면 실행할 수 있습니다 . 하지만 이 애플리케이션을 설치하는 올바른 방법이 있는지 알고 싶습니다. VSCode-linux-x64Code
Code/home/user/Downloads/VSCode-linux-x64/Code

내가 달성하고 싶은 것은 다음과 같습니다

  • 이렇게 제공되는 모든 애플리케이션/소프트웨어(실행 파일)을 한곳에 넣을 수 있습니다.
  • 터미널 지원(예: vscode터미널의 모든 폴더에서 쓸 수 있으며 자동으로 Visual Studio Code가 실행됩니다.

추가 정보:

  • 데스크탑 환경:그놈 3
  • 운영 체제:더반

편집하다:
@kba의 접근 방식이 무엇보다도 내 백업 솔루션에 더 적합하기 때문에 나는 @kba의 답변을 제공하기로 결정했습니다. 스크립트가 바이너리를 실행하게 하면 매개변수를 추가할 수 있습니다.
그러나 공평하게 말하면 @John WH Smith의 접근 방식은 @kba의 접근 방식만큼 좋습니다.

답변1

프로그램을 이름으로 호출하기 위해 쉘은 $PATH환경 변수에서 디렉토리를 검색합니다. Debian에서는 사용자의 기본값에 (예: ) $PATH가 포함되어야 합니다 ./home/YOUR-USER-NAME/bin~/bin

먼저 디렉터리가 존재하는지 확인하고 디렉터리 ~/bin가 없으면 생성하세요.

mkdir -p ~/bin

바이너리를 이 디렉터리에 심볼릭 링크하여 셸에서 사용할 수 있도록 할 수 있습니다.

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

vscode이렇게 하면 명령줄이나 명령 실행 프로그램에서 실행할 수 있습니다.

참고: 바이너리를 $PATH디렉터리에 복사할 수도 있지만 상대 경로에 의존하는 경우 문제가 발생할 수 있습니다.

그러나 일반적으로 말하면 운영 체제(apt-get, deb 패키지) 또는 소프트웨어 프로젝트의 빌드 도구에서 제공하는 수단을 사용하여 소프트웨어를 올바르게 설치하는 것이 가장 좋습니다. 이렇게 하면 관련 경로(예: 시작 스크립트, 매뉴얼 페이지, 구성 등)가 올바르게 설정됩니다.

고쳐 쓰다:또한 반영한다토마스 디키의 댓글그리고파힘 미사의 답변나는 일반적으로 최상위 바이너리가 포함된 tarball 형식의 소프트웨어로 다음을 수행합니다.

논리적인 위치에 배치합니다(표준 준수 순서대로)./opt,/usr/local또는 홈 디렉터리의 폴더(예: 또는 )를 만들고 해당 위치로 변경되고 바이너리를 실행하는 어딘가(예: 또는 )에 ~/build실행 가능한 스크립트 래퍼를 만듭니다 .$PATH/usr/local/bin~/bin

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

이는 디렉터리 변경 사항을 시뮬레이션하고 바이너리를 수동으로 실행하므로 존재하지 않는 상대 경로와 같은 문제를 디버깅하기가 더 쉽습니다.

답변2

~에 따르면TLDP, /opt이러한 유형의 소프트웨어에 적합한 장소일 수 있습니다. 나는 이를 사용하여 일부 프린터 관련 도구와 Skype의 "동적" 버전을 저장합니다(kba가 말했듯이 PATH그에 따라 변수를 설정하여 "터미널 지원"을 얻을 수 있습니다).

보다 일반적으로 저는 /opt실행 파일로 패키지된 독점 소프트웨어를 "설치"하는 경향이 있지만 이것이 제 경우일 수도 있습니다. 또한 저는 이런 종류의 소프트웨어를 사용하지 않는 경향이 있습니다. 왜냐하면 일단 실행하고 나면 어떤 일이 일어날지 확신할 수 없기 때문입니다.

내가 선택한 또 다른 이유 는 해당 디렉토리(및 기타 디렉토리(예: )) 외부의 파일 /opt에 의존하지 않는 타사 독립 실행형 코드에서 일반적으로 작동하기 때문입니다 ./opt/'package'opt/etc/opt

제대로 작동하려면 파일 시스템 트리의 특정 위치에 상주해야 하는 파일을 제외하고 어떤 상황에서도 /opt, /var/opt 및 /etc/opt 계층 외부에 다른 패키지 파일이 존재할 수 없습니다. [...] 일반적으로 시스템에서 패키지를 지원하는 데 필요한 모든 데이터는 /etc/opt/'패키지' 및 /var/opt/' 패키지의 파일 복사를 포함하여 /opt/'패키지'에 있어야 합니다. 그리고 /opt에 예약된 디렉터리가 있습니다.

소스 코드 공개의 장점 중 하나는 시스템의 세부 사항을 기반으로 사용자 정의 라이브러리/헤더 경로를 제공하도록 컴파일 프로세스를 구성할 수 있다는 것입니다. 개발자가 코드를 실행 파일로 릴리스하기로 결정하면 이러한 이점은 사라집니다. IMHO, 이 시점에서 개발자는 더 이상 자신의 프로그램의 종속성을 사용할 수 있다고 가정할 수 없습니다(이것이 모든 것이 실행 파일과 함께 패키지되어야 하는 이유입니다).

여기에 설치할 모든 패키지에는 별도의 /opt/'패키지' 또는 /opt/'provider' 디렉토리 트리에 있는 정적 파일(예: 추가 글꼴, 클립아트, 데이터베이스 파일)이 있어야 합니다(Windows와 유사). 자신의 디렉토리 트리 C:\Windows\Progam Files\"프로그램 이름"), 여기서 "패키지"는 소프트웨어 패키지를 설명하는 이름이고 "공급자"는 공급자의 LANANA 등록 이름입니다.

자세한 내용은 다음을 읽어 보는 것이 좋습니다.기타 U&L 질문/opt, 와 사이의 차이를 처리합니다 /usr/local. 나는 개인적으로 이것을 피하고 싶습니다 /usr/local. 특히 제가 그렇지 않다면 더욱 그렇습니다.세워짐제가 설치하고 있는 프로그램입니다.

답변3

Visual Studio Code 예제에 표시된 것처럼 바이너리 zip 아카이브 또는 tarball에서 배포 바이너리 패키지를 만드는 것은 전적으로 가능하며 실제로 매우 쉽습니다.

deb예, s 및 s와 같은 Linux 배포판용 바이너리 패키지는 rpm일반적으로 소스에서 생성되지만 반드시 그럴 필요는 없습니다. 항상 그런 것은 아니지만 일반적으로 결과 배포 바이너리 패키지가 배포 정책을 준수하기 위해 "올바른" 위치에 항목을 설치하도록 항목을 배열하는 것이 가능합니다.

임의의 독점 타르볼의 경우 makefile에 설치 대상 등 소프트웨어를 올바르게 설치할 수 있는 방법이 있으면 배포 포장 기계에서 작동할 수 있습니다. 그렇지 않으면 파일을 "올바른" 위치에 "수동으로" 매핑해야 하므로 많은 작업이 필요할 수 있습니다. 이러한 패키지를 만드는 것이 이상해 보일 수도 있지만 패키지 관리의 주요 이점 중 하나인 새로 설치 및 제거가 가능합니다. 물론, 그러한 패키지는 그 이름에 걸맞는 어떤 Linux 배포판에서도 결코 받아들여지지 않을 것입니다. 그러나 그것은 여러분의 문제가 아닙니다.

답변4

ln -s </path/to/executable> /usr/local/bin/<program-name>일을 해야 합니다. 로컬 소프트웨어의 표준 위치는 /opt이므로 위 명령을 사용하여 설치하기 전에 소프트웨어 폴더/파일을 해당 위치로 이동하는 것이 좋습니다.

관련 정보