내가 할 때- CD ..대신 cd ..
오류가 발생합니다.
CD: command not found리눅스 명령 에서 터미널이 대소 문자를 구분 하는 이유는 무엇 입니까? “모든 대문자”또는 “모든 소문자”문자로 명령을 실행할 수 있어야합니다.
나는 그것이 어떤 이유로 인한 것이라는 것을 알고 있지만, 나는 단지 궁금합니다.
답변
궁극적으로, 그것은 40 년 전에 유닉스 제작자들이 임의로 선택한 것입니다. 그들은 MS-DOS 제작자가 10 년 후에 한 것처럼 대소 문자를 구분하지 않도록 선택할 수 있었지만 단점도 있습니다.
* ix 문화에 너무 깊이 포함되어있어 지금은 바꿀 수 없습니다. eppesuig에 의해 제기 대소 문자 구분 파일 시스템의 문제는 그것의 일부에 불과합니다. 유닉스 기반의 macOS 시스템 은 일반적으로 대소 문자를 구분하지 않지만 (대소 문자를 보존하는) 파일 시스템을 가지므로 이러한 시스템에서 쉘 외부의 명령은 실제로 대소 문자를 구분하지 않습니다. 그러나 내장cd 은 대소 문자를 구분합니다.
대소 문자를 구분하지 않는 파일 시스템을 사용하더라도 사물의 역사는 당신의 희망에 반합니다. lsMac에 입력 하면 색상이 지정된 디렉토리 목록이 표시됩니다. LS대신 입력 하면 /bin/ls여전히 실행되지만 -C플래그 를 추가하는 별칭 은 대소 문자를 구분 하므로 목록에 색상이 지정되지 않습니다 .
최선을 다해 익숙해 지십시오. 가능하다면 좋아하는 법을 배우십시오.
답변
이것은 “터미널”문제가 아니라 파일 시스템 기능입니다. 쉘은 항상 대소 문자를 구분하는 파일 시스템에서 명령을 어떻게 찾아야합니까?
답변
내가 사용하고 존중하는 기술 시스템은 거의 독점적으로 대소 문자를 구분합니다. OS 나 프로그래밍 언어 또는 다른 것입니다.
내가 지금 생각할 수있는 예외는 HTML 태그와 일부 SQL 구현 및 Ada 프로그래밍 언어입니다.
이러한 경우에도 실제로 HTML 태그를 소문자로 작성하고 SQL 쿼리 의미를 대문자로 사용하고 매개 변수를 대문자로 쓰는 경향이 강하다고 생각합니다. Ada의 경우 Emacs 모드는 컴파일 할 때 중요하지 않지만 소문자 절차 이름을 입력하는 경우와 같이 수정합니다. 따라서 대소 문자를 구분하지 않아도 사람들은 그것이 나쁜 생각이라는 데 동의합니다.
그 이유는 대소 문자를 구분하여 표현력이 훨씬 뛰어 나기 때문입니다. 뿐만 아니라 정량적 – CD하나이지만 CD, Cd, cD, 그리고 cd네입니다 -하지만 더 중요한 것은, 당신은 대문자 사용 등 목적, 중점을 표현하고 현명 소문자; 또한 프로그래밍 할 때 가독성이 향상됩니다.
직관적으로, 당신이 읽을하지 않는 것이 분명하다 hi와 HI같은 방법으로!
그러나 컴퓨터 언어의 예를 들어, 프로그래밍 언어 Ada (1980 년대)에서 프로 시저 코드 블록의 첫 번째 줄은 다음과 같습니다.
procedure body P(SCB : in out Semaphore_Control_Block) is보시다시피, 프로 시저 및 매개 변수 이름은 데이터 유형과 같이 대문자로 표시되며 나머지는 모두 소문자입니다. 또한 “모두 대문자”매개 변수 이름은 이것이 약어임을 나타냅니다. 자, 이것을 이것과 비교하십시오
procedure body p(scb : in out semaphore_control_block) is이것은 Ada가 대소 문자를 구분하지 않기 때문에 가능합니다 (또는 정확히 말하면 컴파일러는 첫 번째 예제에서 방식을 변경하지만 물론 코드는 변경하지 않습니다). 또는 어떻습니까 :
PROCedure body P(Scb : IN Out semaphore_CONTROL_BLOCK) iS그거 조금 말도 안 돼요. 그러나 누군가는 그런 식으로 글을 쓸만큼 어리 석을 것입니다. 요점은 대소 문자를 구분하는 시스템은 사람들이 일관성을 갖도록 강요 할뿐만 아니라 시스템의 도움을 받아 (가독성) 도움이 될 것입니다 (위의 약어 예).
답변
대문자와 소문자 알파벳이 있다는 사실보다 더 이상 이상하지 않습니다. 에서 살펴보면 /usr/bin대문자를 악용하는 (매우) 실행 파일이 거의 없다는 것을 알 수 있습니다.
대소 문자를 구분하는 네임 스페이스는 둔감 한 네임 스페이스의 두 배가 아니라 단어 길이에 따라 차이가 기하 급수적으로 증가합니다. 예를 들어 26자를 사용하면 세 글자에 26 ^ 3 (17576)의 다른 가능성이 있습니다. 52 (2 * 26)자를 사용하면 52 ^ 3 = 140608이 있습니다. 열린 네임 스페이스는 좋은 것입니다.)
답변
“상한 / 하한”사례의 개념은 로케일 특정 일 수 있으며 실제로는 다른 설계 복잡성으로 인해 애플리케이션 스택에서 가능한 한 사용 지점에 가깝게 밀려 나야합니다. 핵심.
대소 문자를 구분하는 환경이 있으면 대소 문자를 구분하지 않는 환경으로 래핑 할 수 있지만 다른 방법은 없습니다.
답변
터미널이 아니라 파일 시스템입니다. 또는 cd쉘이 내장 되어있는 경우 (cd는 내장 쉘임) 대소 문자를 구분합니다.
대소 문자를 구분하지 않고 (ASCII에서는 가능) 가능할 수 있습니다. 이제는 현재 사용되는 유니 코드를 사용하기가 더 어렵습니다 (두 문자가 동일하든 로컬에 따라 다를 수 있음).
그것에 대해해야 할 일
- 함께 살아라.
- 이 쉘 옵션을 사용해보십시오. 대소 문자를 구분하지 않고 문제를 해결하지 않고도 타협하고 일을 더 쉽게 만듭니다.
shopt -s nocaseglob# 이것은 내 안에~/.bashrcshopt -s nocasematch# 이것은 또한~/.bashrcset completion-ignore-case on# 이것은 내 안에~/.inputrc
답변
시작점으로,이 질문이 제기 된 이유와 Google이 주제를 다루는 경우 이에 대해 많은 토론을하는 이유는 대소 문자 구분으로 인해 “정상적인”사람들이 프로그래밍 언어 나 명령 줄을 배우고 사용하기가 더 어려워지기 때문입니다. 상호 작용.
대소 문자 구분은 과거 컴퓨터의 저전력에서 시작되었습니다. 대소 문자를 구분하지 않으려면 명령이 인터프리터 또는 컴파일러에 전달되기 전에 추가 구문 분석 작업이 필요했으며 초기 설계자는 대소 문자를 구분하기 위해 컴퓨터의 전원을 낭비 할 준비가되지 않았습니다.
위에서 언급 한 의견에는 여러 가지 잘못된 주장이 있다고 생각합니다. 첫째, 심리학자들은 인간이 대문자 또는 소문자로 쓰여진 단어 또는 단어의 의미 측면에서 두 단어의 조합을 자동으로 구별하지 않는다고 말합니다. 케이스는 일반적인 표현 언어로 사용되어 추가 의미를 전달합니다. 예를 들어, 문장에서 단어를 시작하는 대문자를 사용하면 가장 적절한 명사 일 수 있습니다. 대문자는 또한 산문 구조를 제공하는 데 사용됩니다. 예를 들어, 대문자는 문장의 시작을 나타내는 데 사용됩니다. 그러나 “단어”와 “단어”는 인간의 마음에 의해 동일한 의미로 간주됩니다.
DOS와 ADA, Pascal을 만든 사람들은 대소 문자 구분이 초보자에게 추가적인 부담이라는 점을 높이 평가했습니다. 나중에 “통합 개발 환경”(IDE)의 텍스트 편집기는 예약어를 인식하여 어쨌든 스타일과 일치하도록 해당 단어를 다시 변환 할 수있었습니다. 단어가 눈에 띄도록 다른 색상으로 표시하십시오. 따라서 대소 문자를 구분하여 더 읽기 쉬운 코드를 만들 수 있다는 주장은 잘못된 것입니다. 사람들을 “정상”하지 않습니다. 이미 까다로운 작업에 불필요하고 때로는 혼란스러운 레이어를 추가하기 만하면됩니다.
Java는 초보자가 사용하기 쉽다는 관점에서 열악한 언어의 극단적 인 예입니다. 대소 문자를 엄격하게 구분하지만 어리석게도 프로그래머는 동일한 이름을 가진 두 가지 기능을 가질 수 있지만 실제로는 다른 인수 집합을 가지고 있다는 사실 때문에 실제로 다른 기능입니다. 실제로, 자바는 대학이 파스칼 구문을 가르치는 것에서 학생들로 컴퓨터가 아닌 과학 과정을 옮길 때 통과율이 약 70 %에서 40 %로 떨어진 언어의 낙태입니다.
결론적으로, 대소 문자 구분은 두 가지 이유로 발생했습니다. 하나는 컴퓨터 전원이 부족했습니다. 두 번째는 컴퓨터 과학에 종사하는 사람들이 종종 자폐 스펙트럼에 속하며 “정상적인”사람들의 요구와 잘 관련이 없다는 것입니다. 결과적으로,이 사람들은 대소 문자 구분이 불필요하며 프로그래밍 언어를 배우고 사용하는 데 방해가된다는 것을 이해할 수 없습니다.
