오늘 이전에는 터미널을 디렉토리 내외로 이동하고 touch명령을 사용하여 파일 날짜를 변경하는 데 제한을 두었습니다 . Mac에 재미있는 스크립트를 설치하고 chmod 755나중에 파일을 실행하여 파일을 실행 한 후에 터미널의 전체 범위를 실현 했습니다.
/usr/local/bin그래도 무엇인지 알고 싶습니다 . /usr/나는 컴퓨터의 사용자라고 생각합니다. 그래도 왜 그런지 잘 모르겠습니다 /local/. 분명히 로컬 컴퓨터를 의미하지만 컴퓨터 (또는 서버)에 있기 때문에 실제로 필요합니까? 하지 않을까요 /usr/bin괜찮을?
그리고 무엇 /bin입니까? 이 영역이 일반적으로 터미널에 스크립트를 설치하는 데 사용되는 이유는 무엇입니까?
답변:
/usr/local/bin 일반 사용자가 실행할 수있는 프로그램을위한 것입니다.
/usr/local계층은 로컬 소프트웨어를 설치하는 시스템 관리자가 사용할 수 있습니다./usr./usr/local에서 소프트웨어를 교체하거나 업그레이드하기 위해 설치되지 않는 한 / usr 대신에 설치해야합니다 /usr.이 소스는 파일 시스템 계층 구조 표준 을보다 깊이 설명하는 데 도움이됩니다 .
이 기사는/usr/local/bin 흥미로운 사용 및 남용에 대해서도 찾을 수 있습니다 .
/ usr /, 컴퓨터의 사용자라고 가정합니다.
닫기.
유닉스는 다중 사용자 운영 체제로 시작, 그래서 "사용자는"그 "는 아니에요의 사용자 ,"복수.
AT & T Unix System V Release 4 (SVR4)가 1988 년에 사용자 관리 도구가 기본적으로 사용자 홈 디렉토리 생성으로 기본 설정되어 나오기 전에는 /home기존 위치가 /usr.¹ $HOME디렉토리가 System III 상자 /usr/jfw에 있었을 수 있습니다 .
/usr또한, 다음 지금으로, 포함 /usr/bin, /usr/lib등 체험 홈 디렉토리를 분리하는 것은 좋은 시스템 관리 관행 이었다는 것을 보여 너무 /homeSVR4의 정책 변화, 우리가 지금에 속하는 것으로 생각하는 모든 것을 남겼다 /usr.
/usr여전히 이름을 붙일만한 충분한 이유가있었습니다. 남은 것은 정상적인 대화식 사용을 지원할 정도로 시스템이 부팅 될 때까지 사용할 수 없었던 파일이었습니다. 즉, 남은 것은 OS 의 사용자 중심 부분이었습니다. 이것은 /usr다른 물리적 볼륨에있을 수 있음을 의미했는데 , 이는 92MB의 하드 디스크 드라이브가 세탁기 크기였던 시절에 좋은 일이었습니다 .
초기 유닉스 시스템은 어떤 이유로 든 볼륨을 마운트 할 수 /usr없는 경우에도 단일 사용자 모드 ²로 부팅 할 수 있도록 코어 OS 파일을 유지하는 데주의를 기울 /usr였습니다. 루트 볼륨에는 /usr볼륨을 온라인으로 되돌릴 수있는 충분한 도구가 포함되어 있습니다.
아주 작은 임베디드 시스템은 기존의 루트 볼륨 파일 모두를위한 충분한 공간이 있기 때문에 여러 유닉스 맛은 지금이 오래된 디자인 원칙을 무시하지 하고 모든 /usr단일 volume.³은 Red Hat Enterprise Linux, Solaris 및 Cygwin에서 심볼릭 링크에를 /bin로 /usr/bin와 /lib하는 /usr/lib어떤이있다 그래서 이 디렉토리들 간의 차이가 더 깁니다.
... / local / ... 확실히 로컬 컴퓨터를 나타냅니다 ...
예. 아래의 파일 /usr/local이 해당 단일 시스템에만 적용 된다는 사실을 나타냅니다 . 일반적인 방식의 파일은 다른 곳에 있어야합니다.
이것은 또한 모든 것이 표준화되었을 때 수십 년 전에 유닉스 시스템이 일반적으로 사용 된 방식에 뿌리를두고 있습니다. 다시 말하지만, 당시의 하드 디스크는 부피가 크고 실제로 비쌌으며 오늘날의 표준에 따라 저장되지 않았습니다. 디스크에 돈과 공간을 절약하기 위해 Unix 박스로 가득 찬 컴퓨터 /usr실은 종종 NFS 또는 다른 네트워크 파일 공유 프로토콜 을 통해 대부분을 공유하므로 각 박스마다 자체 중복 사본을 가질 필요가 없었습니다. 상자가 아래 /usr/local에 있습니다 /usr.
이 역사적 유산은 여전히 대부분의 타사 Unix 소프트웨어가 직접 설치할 /usr/local때 설치되는 기본 이유 입니다. 이러한 소프트웨어는 대부분 패키지를 다른 곳에 설치할 수 있지만 선택하지 않은 경우 안전한 기본값을 얻게되므로보다 일반적인 목적으로 다른 일반적인 설치 위치를 방해하지 않습니다.
소프트웨어를 다른 곳에 설치해야 할 이유가 있습니다. Apple의 macOS 팀은 GNU Bash 소스 코드bash 에서 빌드 할 때이 작업을 수행 합니다 . /설치 접두사로 사용 하여 /usr/local기본값을 재정의 하므로 Bash는로 끝납니다 /bin.
또 다른 예는 기존 Linux 시스템이 GUI 소프트웨어를로 /usr/X11R6분리하여 기존 명령 행 및 curses기반 소프트웨어 와 분리되도록하는 방법 입니다. 기본 /usr/local접두사를 /usr/X11R6.⁵ 로 재정의하면됩니다.
그리고 / bin은 무엇입니까?
"이진 (binary)"의 줄임말로이 문맥에서 "일반 텍스트가 아닌 파일"을 의미합니다. 이러한 파일은 대부분 Unix 상자에서 실행 파일 이므로이 두 용어는 일부 원에서 동의어가되었습니다. ( "RHEL 7 용 바이너리를 빌드하십시오. Fred")
유닉스 상자에 텍스트 파일이 다른 곳에서 살고 : /etc, /usr/include, /usr/share, 등
옛날 옛적에 일반 텍스트 파일 인 쉘 스크립트조차 bin디렉토리에서 제외되었지만이 줄도 희미 해졌습니다. 오늘날 bin디렉토리는 일반적으로 엄격하게 "이진"인지 여부에 관계없이 모든 종류의 실행 파일을 포함합니다 .⁶
각주 및 오류 :
SVR4 이전의 사용자 관리 도구의 기본 특성은이 HOME=/usr/$NAME체계가 소프트웨어 도구에 의해 기본값으로 시행되는 것이 아니라 단지 규칙으로 문서화 되었음을 의미했습니다 .
" AT & T Unix System V 릴리스 3.2 시스템 관리자 안내서 "의 4-8 페이지에서이 내용을 볼 수 있습니다 . 여기서 AT & T는 /usr/$NAMESVR4가 나오기 전에 마지막 주요 버전의 Unix에서 이전 체계를 권장합니다 .
구형 유닉스 시스템에서는 시스템 관리자가 더 적합한 다른 체계를 선택하는 것이 일반적이었습니다. 사람들은 사람들이며, 그것은 많은 다른 계획이 고안되었음을 의미합니다.
내가 전에 만난 계획 /home/$NAME은 표준이되었습니다 /u/$NAME.
1990 년대 초에 사용 했던 또 다른 시스템 에는 너무 많은 사용자가 있었기 때문에 모든 홈 디렉토리를 하나의 물리적 볼륨에 맞출 수 없었기 때문에 제가 기억 하는 것처럼 /u1/$NAME, /u2/$NAME등 의 체계를 사용했습니다 . 홈 디렉토리가 어느 디스크에 있는지는 단순히 계정을 만들 때 어느 디스크에 공간이 있는지에 대한 문제입니다.
부팅하는 Cmd-S동안 누르고 있으면 macOS 상자를 단일 사용자 모드로 부팅 할 수 있습니다 . 화면이 검게 변하면 밝은 회색 텍스트가 나타납니다. 터미널에서 실행하는 것과 비슷하지만 GUI가 아직 시작되지 않았기 때문에 전체 화면을 차지합니다.
로 실행 중 root입니다.
단일 사용자 루트 프롬프트에서 "exit"를 입력하여 단일 사용자 모드를 종료하고 다중 사용자 GUI 모드로 계속 부팅하십시오.
중요한 단일 사용자 모드 파일을 유지 하지 않는 것으로 보이는 Unixy OS /usr는 실제로 요즘에는 그렇지 않을 수 있습니다. /usrZFS 볼륨 으로 이동 하여 FreeBSD 9 박스를 부팅 할 수 없게 만들었습니다 . ZFS-on-root 기능이 FreeBSD 10까지 도달하지 않아서 Catch 22를 만들었습니다 . OS /usr는 마운트하기 위해 파일이 필요했습니다 /usr!
그것은 충분히 나빴지 만 FreeBSD 9가 여전히 단일 사용자 부트 항목을 유지하지 않았다면 그 /usr자리를 고칠 수있었습니다. /usr마운트 할 수없는 단일 사용자 모드로 부팅되지 않기 때문에 전통이 어떻게 든 위반되었다는 것이 분명합니다. 시스템을 다시 백업하려면 복구 CD로 부팅해야했습니다.
이것은 또한 우리가 얻을 수있는 곳입니다 /usr/share: 다른 프로세서 유형의 유닉스 박스 간에도 공유 할 수있는 파일을 분리합니다. 일반적으로 텍스트 파일 : 매뉴얼 페이지, 사전 등
"X11R6" 은이 규칙이 널리 보급 된 당시 Linux GUI를 지원 하는 X Window System 버전을 나타 냅니다. Linux 시스템은 일반적으로 X11R6이 X.Org 로 교체 될 때 GUI 소프트웨어 분리를 중지했습니다 .
오리지널 유닉스 시스템은 /etc에서 실제 바이너리와 섞이지 않도록 코어 쉘 스크립트를 유지했습니다 /bin.
일반적으로 구조 관련 질문에 대해서는 Wikipedia 를 참조하는 것이 좋습니다 . 기본 사항을 다룰 것입니다.
그러나 귀하의 질문에 직접 대답하려면 :
이것이 둘 사이에서 유사한 구조를 찾는 경향이있는 이유입니다. / usr / {, local /} {bin, sbin, lib}. 셸을 처음 사용하기 때문에 {}의 비트는 셸 확장입니다. 실행을 시도
ls -ld /usr/{,local/}{bin,sbin,lib}
로컬 쉘에서 작동 방식을 확인하십시오.
/usr/local/bin 최신 Mac OS (UNIX 기반 루트) (BSD 기반 BSD)가 표시됩니다.
이것은 초기 UNIX 구현부터 Linux 및 BSD로 바뀌었지만 규칙은 그대로 남아 있습니다. 이제는 /usr/bin"주"또는 핵심 프로그램 및 라이브러리 /usr/local/bin용이며 애드온 및 중요하지 않은 프로그램 및 라이브러리 용입니다.
/usr/nzwulfin기본적으로 초기 작업 디렉토리가 됩니다. 또 다른 일반적인 계획. SVR4 /home계획이 인수 되기 전 이었습니다 /u. 내가 처음에 사용했던 한 시스템에는 사용자 파일 저장을 위해 여러 개의 물리적 디스크가 필요한 많은 사용자가 있었으므로 다음과 같은 것들이있었습니다 /u/d5/tangent.
/usr/local/bin 실행 파일, 특히 오픈 소스 파일에서 가장 많이 사용되는 기본 위치입니다.
그러나 이것은 유닉스 시스템에서 /usr90 년대 초에 운영 체제에 속하는 파일의 계층 구조를 포함하도록 표준화되었으므로 해당 OS를 사용하는 여러 시스템에서 공유 할 수 있기 때문에 잘못된 선택 입니다.
이러한 파일은 정적이므로 /usr파일 시스템을 읽기 전용으로 마운트 할 수 있습니다. /usr/local로컬로 설계되어 공유되지 않기 때문에이 표준을 그대로 따르므로 로컬 컴파일을 허용하려면 운영 체제의 일부가 아닌 읽기 / 쓰기가 필요합니다. /opt/local대신 선택하지 않은 것과 같은 나쁜 일이 ...
/usr/localMathematica와 같이 설치할 수있는 상용 프로그램에 사용 하는 것이 좋습니다 . 설정할 때 자체 파티션에 배치하십시오. OS를 업그레이드 할 때이 파티션은 방해받지 않으며 내용을 다시 설치할 필요가 없습니다. 따라서 OS 업그레이드 사이에 유지하려는 항목에 사용하십시오.
이와 별도로이 경우 /home에도 자체 파티션을 제공해야합니다 .
이 답변도 도움이 될 수 있습니다.
원래의 아이디어 /usr/local는를 제외한 모든 머신에 별도의 ( 'local') '/ usr'디렉토리를 갖는 것이 었습니다.이 디렉토리는 /usr다른 곳에서 읽기 전용으로 마운트 될 수 있습니다. 의 구조를 복사합니다 /usr.
요즘 /usr/local은 자체 컴파일 또는 타사 프로그램을 유지하기에 좋은 장소로 널리 알려져 있습니다. /usr/local계층은 로컬 소프트웨어를 설치하는 시스템 관리자가 사용할 수 있습니다. 시스템 소프트웨어가 업데이트 될 때 덮어 쓰기되지 않도록 안전해야합니다.
호스트 그룹간에 공유되지만에서 찾을 수없는 프로그램 및 데이터에 사용될 수 있습니다 /usr. 로컬로 설치된 소프트웨어 내에 배치해야 /usr/local보다는 /usr이 교체하거나 소프트웨어를 업그레이드하기 위해 설치되는 경우를 제외 /usr.