Linux가 설치된 프로그램의 파일을 구성하는 방식의 이점은 무엇입니까? [닫은]

Windows에서 시스템 드라이브 C:에는 directory program_files가 있으며 그 아래에 각 프로그램에 고유 한 디렉토리가 있습니다.

Linux에서는 /usr/및 아래 에 등 /usr/local/이 있습니다 /bin, /etc, /share, /src.

따라서 Windows에서는 각 프로그램의 모든 파일이 동일한 디렉토리에 그룹화되고 Linux에서는 모든 프로그램의 동일한 유형의 파일이 있습니다.

Windows가 설치된 프로그램을 구성하는 방식이 Linux 방식보다 논리적이므로 설치된 프로그램을 수동으로 관리하는 것이 더 쉽다고 생각합니다.

Linux가 설치된 프로그램의 파일을 구성하는 방식의 이점은 무엇입니까? 감사.

쉘을 위해 $ HOME에 설치된 프로그램을 구성하는 방법에 문제가있을 때이 질문이 있습니까? $HOMEWindows에서 프로그램을 구성하려고 시도 하지만 프로그램의 검색 경로를 지정하는 데 문제가 있습니다.

Linux에서 다른 위치는 일반적으로 잘 관리되면 일부 논리를 반영합니다. 예 :

• /bin 가장 기본적인 도구 (프로그램)를 포함
• /sbin 가장 기본적인 관리자 프로그램을 포함합니다

둘 다 부팅 및 기본적인 문제 해결에 사용되는 기본 명령을 포함합니다. 그리고 여기 첫 번째 차이점이 있습니다. 일부 프로그램은 일반 사용자가 사용하지 않습니다.

그런 다음에서 살펴보십시오 /usr/bin. 여기에서는 일반적으로 1000 개가 넘는 명령 (프로그램)을 더 많이 선택할 수 있습니다. 그들은 표준 도구 만에 그만큼 중요하지 않습니다 /bin와 /sbin.

/usr/bin구성 파일이 다른 곳에 상주하는 동안 명령을 포함합니다. 이것은 기능 엔티티 (프로그램)와 구성 및 기타 파일을 분리하지만 사용자 기능면에서 명령을 다른 것과 혼합하지 않으면 PATH실행 파일을 가리키는 변수를 간단하게 사용할 수 있기 때문에 편리합니다. 또한 명확성을 소개합니다. 실행 가능한 것이 무엇이든간에.

내 것을 보아라 PATH.

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

직접 호출 할 수있는 명령을 포함하는 정확히 6 개의 위치가 있습니다 (예 : 경로가 아니라 실행 파일 이름).

• /home/tomas/bin 개인 실행 파일의 홈 폴더에있는 개인 디렉터리입니다.
• /usr/local/bin 아래에서 별도로 설명하겠습니다.
• /usr/bin 위에서 설명했다.
• /bin 위에서도 설명했습니다.
• /usr/local/games/usr/local(아래 설명)과 게임 의 조합입니다
• /usr/games게임입니다. 유틸리티 실행 파일과 혼합되지 않도록 별도의 위치가 있습니다.

지금 /usr/local/bin. 이것은 다소 미끄러 워서 이미 설명되어 있습니다. / usr / local / bin은 무엇입니까? . 이를 이해하려면 /usr많은 시스템 이 폴더를 공유하고 네트워크 위치에서 마운트 될 수 있음 을 알아야합니다 . 이전에 언급 한 것처럼 부팅시에는 명령이 필요하지 않으므로 /bin부팅 과정의 후반부에 위치를 마운트 할 수 있습니다. 또한 읽기 전용 방식으로 마운트 할 수도 있습니다. /usr/local/bin반면에, 로컬로 설치된 프로그램 용이며 쓰기 가능해야합니다. 따라서 많은 네트워크 시스템이 일반 /usr디렉토리를 공유 할 수 있지만 각각 의 네트워크 시스템은 공통 디렉토리 /usr/local안에 자체 마운트됩니다 /usr.

마지막으로 PATH루트 사용자를 살펴보십시오 .

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

다음이 포함됩니다.

• /usr/local/sbin유형의 관리자 명령이 포함 된 /usr/local
• /usr/local/bin일반 사용자가 사용할 수있는 것과 동일합니다. 다시, 그들의 유형은로 설명 될 수 있습니다 /usr/local.
• /usr/sbin 필수적이지 않은 관리 유틸리티입니다.
• /usr/bin 필수적이지 않은 관리 및 일반 사용자 유틸리티입니다.
• /sbin 필수 관리 도구입니다.
• /bin 관리자 및 일반 사용자 필수 도구입니다.

요즘 나는 이것이 고전 유닉스의 역사적 유산이라고 생각합니다.

최초의 유닉스 버전에서, 프로그램은 오늘날처럼 크지 않았습니다. 프로그램은 종종 시스템 라이브러리를 사용하는 하나의 실행 파일로 구성되었습니다. 따라서 아무도 두 개의 자체 라이브러리로 구성된 프로그램에 대해서는 생각하지 않았습니다. 주요 도서관은 C 도서관이었고 모든 프로그램은 그 위치를 알고있었습니다.

또한 UNIX 환경은 완제품 (문서 준비 용)으로 간주되었습니다. 따라서 모든 도구에 대한 경로가 수정되었습니다.

현재 HDD (Hard Disk Drive) 일 고정 경로의 이점이 있습니다. FSH (File System Hierarchy)가 별도의 디스크 파티션에서 분할되고 바이너리 및 라이브러리가있는 파티션을 HDD의 1 차 섹터 근처에 놓으면 프로그램 시작 시간이 약간 빨라집니다.

현대 유닉스 계열 시스템으로 보는 것은 실제로 전통적이지 않습니다.

일반적으로는 상당히 최소한있을 것이다 /및 /usr단지 시스템 유틸리티와 계층 구조 및 프로그램은 다음의 서브 디렉토리에 별도로 설치 /usr/local한 다음 심볼릭 링크를 생성하여 제공.

GNU 소프트웨어의 가장 일반적인 설정은 다음과 같이 컴파일하고 설치하는 것입니다.

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

GNU stow 유틸리티는 Windows와 마찬가지로 PATH 변수에 디렉토리를 추가 할 필요없이 표준 경로에서 소프트웨어를 사용할 수 있도록 심볼릭 링크를 생성합니다.

그러나 최신 Linux 배포판은 모든 것을 기성품 패키지로 제공하므로 프로그램은 "시스템"의 일부가되었습니다. 패키지 관리자는 설치를 관리하므로 기호 링크가 필요하지 않으며 프로그램 분리는 유용한 목적을 제공하지 않습니다 (그러나 많은 작은 디렉토리를 스캔해야하므로 프로그램 시작 속도가 느려집니다).

홈 디렉토리에 소프트웨어를 설치하려면 GNU stow도 사용하는 것이 좋습니다. 이렇게하면 프로그램을 별도로 유지할 수 있습니다. 이는 패키지 관리자를 사용하지 않는 경우에 합리적입니다.

그에 대한 나의 기존 설치 한 디렉토리입니다 ~/software/DIR그때 스토우의 내부 사용에 프로그램을 설치하는 것이 DIR생성 ~/software/bin, ~/software/share등 난 단지 추가해야이 수단 ~/software/bin내 모든 설치된 소프트웨어를 얻기 위해 PATH 변수를.

사용하다:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

프로그램이 GNU 규칙을 따르는 경우 설치합니다.

응용 프로그램 패키지 (한 디렉토리의 C ++ 컴파일러, 다른 디렉토리의 이미지 편집 프로그램)가 아닌 목적 ( /usr/bin실행 파일, /usr/lib라이브러리)으로 개별 파일을 나누는 스타일에 대해 이야기 하는 것 같습니다. 유닉스 시스템에는 이러한 역사적 이유가 많이 있지만, 유닉스 계열 시스템을이 시스템에 의존하게 만드는 오늘날의 세력도 있습니다 : 시스템에서 대부분의 프로그램을 관리하는 패키지 관리자.

역사적으로 오늘날까지도 여전히 Windows에서 응용 프로그램은 자체 설치 프로그램, 특히 제거 프로그램을 제공하는 책임을 맡았으며 이제는 종종 중앙 응용 프로그램 목록에 자신을 등록하지 않습니다. 이와 같은 상황에서는 일반적으로 응용 프로그램이 가능한 많은 파일에 대해 "자신의"디렉토리를 갖는 것이 좋습니다. 다른 응용 프로그램과의 충돌을 피하는 데 도움이되지만 항상 작동하지는 않습니다 (특히 DLL 의 경우 ).

반면에 유닉스 시스템은 90 년대 이후 일반적으로 단일 패키지 관리자와이 패키지 관리자를 통해 일반적으로 사용되는 많은 양의 소프트웨어를 제공하는 그룹을 가지고있었습니다. (다양한 유닉스 공식 패키지 관리자는 포함 yum및 apt리눅스 시스템, pkgsrcNetBSD에 대한, 그리고 portsFreeBSD를 위해. 종종 상용 유닉스 시스템은 또한 같은뿐만 아니라 비공식 그러나 널리 받아 들여진 패키지 관리자로 끝날 brew맥 OS합니다.)

이러한 패키지 관리자는 "소유 한"다양한 하위 디렉토리에서 시스템의 모든 파일을 추적 할 수 있다는 이점이 있습니다. 단일 그룹이 여기에서 모든 파일의 이름과 위치를 지정하므로 모두 공유되는 작은 디렉토리 세트를 사용할 수 있습니다. 이는 특히 응용 프로그램간에 파일을 공유하고 라이브러리 및 실행 파일을 검색하는 데 필요한 경로 수를 줄이는 영역에서 다양한 이점을 제공합니다.

즉, Unix에는 일반적으로 /opt디렉토리 아래에 "응용 프로그램마다 별도의 디렉토리"설치라는 오랜 전통이 있습니다.