가끔하지로 제공되며 소프트웨어에 실행 .deb또는 .rpm만 실행한다.
예를 들어 Visual Studio Code , WebStorm 또는 Kerbal Space Programm 입니다.
이 질문에 대해서는 Visual Studio Code를 참조 지점으로 사용합니다.
소프트웨어는 압축 패키지로 제공됩니다.
압축을 풀 때라 VSCode-linux-x64는 실행 파일이 들어있는 폴더가 남아 있습니다 Code. 터미널 을 실행하는 것처럼
두 번 클릭 Code하거나 가리킬 /home/user/Downloads/VSCode-linux-x64/Code수 있습니다.
그러나이 응용 프로그램을 설치하는 올바른 방법이 있는지 알고 싶습니다.
내가 달성하고자하는 것은 :
- 이러한 방식으로 제공되는 모든 응용 프로그램 / 소프트웨어 (실행 파일)를 넣을 수있는 한 곳
- 터미널 지원 (즉, 터미널의
vscode모든 폴더에서 쓸 수 있으며 Visual Studio Code가 자동으로 실행됩니다).
추가 정보:
- 데스크탑 환경 : Gnome3
- 운영체제 : Debian
편집 :
나는 그의 접근 방식이 내 백업 솔루션과 더 잘 작동하기 때문에 @kba에 대답하기로 결정했습니다. 바이너리를 스크립트로 실행하면 인수를 추가 할 수 있습니다.
그러나 공정하게 말하면 @John WH Smith의 접근 방식은 @kba의 방법만큼 좋습니다.
답변
이름으로 프로그램을 호출하기 위해 쉘은 $PATH환경 변수 에서 디렉토리를 검색합니다 . 데비안에서 $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디렉토리에 복사 할 수도 있지만 상대 경로에 의존하면 문제가 발생할 수 있습니다.
그러나 일반적으로 OS에서 제공하는 수단 (apt-get, deb 패키지) 또는 소프트웨어 프로젝트의 빌드 도구를 사용하여 소프트웨어를 올바르게 설치하는 것이 항상 바람직합니다. 이렇게하면 시작 스크립트, 매뉴얼 페이지, 구성 등과 같은 종속 경로가 올바르게 설정됩니다.
업데이트 : 또한 Thomas Dickey의 의견 과 Faheem Mitha의 답변 을 반영하여 최상위 바이너리가있는 tarball로 제공되며 거기에서 실행될 것으로 예상되는 소프트웨어에 대해 일반적으로 수행하는 작업은 다음과 같습니다.
(표준 준수를 위해 제정신 위치에 넣어 /opt, /usr/local또는 홈 디렉토리, 예에서 폴더 ~/build)와에 실행 스크립트 랩퍼를 작성 $PATH(예를 들어, 위치 /usr/local/bin또는 ~/bin해당 위치로 변경하고 바이너리를 실행하는) :
#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"
이는 해당 디렉토리로 변경하고 바이너리를 수동으로 실행하는 것을 에뮬레이트하므로 존재하지 않는 상대 경로와 같은 문제를 쉽게 디버그 할 수 있습니다.
답변
에 따르면 TLDP , /opt이런 종류의 소프트웨어를위한 좋은 장소가 될 수 있습니다. 프린터 관련 도구와 Skype의 “동적”버전을 저장하는 데 직접 사용했습니다 (kba에서 말했듯이 “터미널 지원”은 PATH변수를 적절히 설정하여 달성 할 수 있음 ).
좀 더 일반적으로, 나는 /opt실행 파일로 패키지 된 독점 소프트웨어를 “설치” 하는 데 사용 하는 경향이 있지만, 아마도 나일 것입니다. 게다가, 나는 보통 이런 종류의 소프트웨어를 피하는 경향이있다. 나는 보통 일단 그것을 실행하면 어떻게 될지 확실하지 않기 때문이다.
내가 선택한 또 다른 이유 /opt는 일반적으로 /opt/'package'디렉토리 외부의 파일 (및 opt같은 다른 디렉토리 /etc/opt)에 의존하지 않는 타사의 독립적 인 코드를 의미하기 때문입니다 .
어떤 상황에서도 파일 시스템 트리 내의 특정 위치에 있어야하는 패키지 파일을 제외하고 다른 패키지 파일이 / opt, / var / opt 및 / etc / opt 계층 외부에 존재하지 않아야합니다. […] 일반적으로 시스템에서 패키지를 지원하는 데 필요한 모든 데이터는 / etc / opt / ‘package’및 / var / opt / ‘로 복사하려는 파일을 포함하여 / opt /’package ‘내에 있어야합니다. / opt에 예약 된 디렉토리뿐만 아니라 package ‘도 있습니다.
소스 코드를 공개하면 사용자가 컴파일 프로세스를 구성하여 시스템의 특성에 따라 사용자 정의 라이브러리 / 헤더 경로를 제공 할 수 있다는 이점이 있습니다. 개발자가 코드를 실행 파일로 릴리스하기로 결정하면 이러한 이점이 사라집니다. IMHO는이 시점에서 개발자가 더 이상 자신의 프로그램의 종속성을 사용할 수 있다고 가정 할 수 없습니다 (이로 인해 모든 것이 실행 파일과 함께 패키지되어야합니다).
여기에 설치할 패키지는 별도의 / opt / ‘package’또는 / opt / ‘provider’디렉토리 트리 (Windows 설치 방식과 유사)에서 정적 파일 (예 : 추가 글꼴, 클립 아트, 데이터베이스 파일)을 찾아야합니다. 새 패키지를 자체 디렉토리 트리 C : \ Windows \ Progam Files \ “프로그램 이름”)에 추가합니다. 여기서 ‘package’는 소프트웨어 패키지를 설명하는 이름이고 ‘provider’는 제공자의 LANANA 등록 이름입니다.
자세한 내용은, 나 또한 읽기 제안 이 다른 U & L 질문 의 타협과 차이 거래 /opt와 /usr/local. /usr/local이 경우, 특히 내가 설치하는 프로그램 을 만든 사람이 아닌 경우 개인적으로 피할 것 입니다.
답변
Visual Studio Code의 예에서와 같이 바이너리 zip 아카이브 또는 tarball에서 배포 바이너리 패키지를 만드는 것은 전적으로 가능하며 실제로는 매우 쉽습니다.
예, debs 및 s와 같은 Linux 배포 바이너리 패키지 rpm는 소스에서 관례 적으로 생성되지만 반드시 그럴 필요는 없습니다. 결과 배포 배포판 패키지가 배포 정책을 준수하기 위해 “올바른”위치에 설치하는 것에 대해 배열하는 것이 가능할 수도 있습니다 (항상 그런 것은 아니지만).
임의의 독점 타르볼의 경우, 소프트웨어 (예 : makefile에 설치 대상)를 올바르게 설치하는 방법이 있으면 배포 패키징 기계와 함께 사용할 수 있습니다. 그렇지 않으면, “수동으로”파일을 “적절한”장소에 매핑하는 것이 많은 작업 일 수 있습니다. 이러한 패키지를 작성하는 것은 이상한 일이지만, 패키지 설치의 주요 이점 중 하나, 즉 새로 설치 및 제거를 수행하는 것입니다. 물론 그러한 패키지는 그만한 가치가있는 Linux 배포판으로 받아 들여지지 않을 것이지만 그것은 당신의 질문이 아닙니다.
답변
나는 바이너리 실행 파일로 제공되는 소프트웨어는 거의 보지 못했고 솔직히 의심 할 것입니다. 다른 것이 없다면 나는 적어도 README(설치 지침이있는) 및 LICENSE그것을 동반 할 것으로 기대 합니다. 그 말은 …
배포판의 패키지 관리자가 관리하지 않는 로컬로 설치된 바이너리는 보관되는 일반적인 장소는 /usr/local/bin입니다. 디렉토리를 넣을 수 있으며 해당 디렉토리가 이미 디렉토리에 있거나 $PATH명령 행에 이름을 입력하여 소프트웨어를 실행할 수 있습니다.
일반적으로 소프트웨어는 또한에가는 맨 페이지를 (문서화되지 않은 소프트웨어가 바로 나쁜?)이 있어야 /usr/local/man하며 갈 수있는 다른 언어와 플러그인에 번역을 일부 지원 파일이있을 수 있습니다 /usr/local/share또는 /usr/local/lib, 등등. 이러한 이유로 패키지와 같이 제공되지 .deb않거나 .rpm일반적으로 모든 것을 올바른 위치에 설치하는 설치 프로그램이 포함 된 소프트웨어가 제공됩니다 . 소스에서 설치하는 경우 일반적으로 make install입니다.