경로 구분자로 콜론이 선택된 이유


22

:경로 구분 기호 로 콜론 ( )을 선택한 이유는 무엇 입니까?

"디렉토리 구분자"가 아니라 "경로 구분자"를 의미합니다. 경로 구분 기호는 PATH환경 변수 의 항목 사이에있는 기호 입니다.

PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:..."
                     ^ this symbol

컴퓨터와 소프트웨어의 모든 것은 한때 누군가가 의도적으로 한 결정이었습니다. 예를 들어 틸드가 홈 디렉토리를 나타내는 이유 (및 vi의 방향 키에 대한 hjkl) . 이 결정의 배경을 알고 싶습니다.


몇 가지 무작위 사실 :

경로 구분자로 콜론이 있으면 이름에 콜론이있는 디렉토리를 경로에 추가 할 수 없습니다.

POSIX에서 :

<colon>이 컨텍스트에서 구분 기호 이므로 PATH에 사용될 수있는 디렉토리 이름에는 <colon>문자가 포함되지 않아야 합니다.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

콜론에서 벗어날 수없는 것 같습니다. Stack Overflow의 @ Random832는 PATH를 처리하는 소스 코드를 검사했으며 이스케이프 메커니즘을 찾지 못했습니다.

/programming/14661373/how-to-escape-colon-in-path-on-unix


또한 구분 기호이기도합니다 /etc/passwd(홈 및 셸 열에 경로가 포함되어 있음).
Stéphane Chazelas


11
어제 약 30 분 동안이 질문을 조사했습니다. 나는 콜론의 사용을 명시하지만 (예를 들어) 파이프 심볼 대신 콜론이 선택된 이유가 아닌 1971 유닉스 프로그래머 매뉴얼을 읽었습니다. 또한 Multics에 대해 가능한 한 많이 읽었지만 PATH에 하나의 디렉토리 만 있었으므로 분명히 구분 기호가 필요하지 않습니다. 우리가 여기에 좋은 대답을 얻지 못할 지 모르겠지만 일부 베테랑 유닉스 사용자 가이 질문에 대답 할 수있는 기회가 있다면 기회를 갖기를 바랍니다. 그래서 다시 열겠습니다.
Anthony G-Monica에 대한 정의

3
1979 년 Unix 버전 7 이 도입되기 전에 호출 된 쉘 / 환경 변수 는 없었지만 1977 년 초에 검색 경로 가 구분되었습니다.  PWB / Unix (Programmer 's Workbench) 는 Mashey shell을 사용 했습니다. John R. Mashey 는 Thompson 쉘과 Bourne 쉘 사이에서 시간순으로 떨어졌습니다. … (계속)PATH:
G-Man, 'Reinstate

3
(계속)…  Mashey 쉘 은 26 개의 쉘 변수 (이름이 무엇인지 추측)를 지원했습니다. 변수 p는 디렉토리가 콜론으로 구분 된 검색 경로 (“명령 실행을위한 쉘 디렉토리 검색 순서”라고 함)였습니다. 재미있는 사실 : Mashey 쉘이 .profile파일을 처리하는 동안 $p이라는 파일에서 초기 값 을 지정할 수도 있습니다 .path.
G-Man, 'Reinstate

답변:


3

약간의 파기 후에 나는 실제 답변이 없지만 역사적인 사실에 의해 뒷받침되는이 대화에 추가 할 최소한 새로운 정보가 있습니다.

Peter Chubb https://www.youtube.com/watch?v=Sye3mu-EoTI 는 그의 연설 중 하나에서 쉘에 대해 이야기하고 있으며, 19:00 마크 주위 e에 기본 편집기의 별칭이 왜 언급되는지들을 수 있습니다. 유닉스 쉘에서는 사용하기 쉽지 않고 사용하기가 쉽지 않은 오래된 터미널이 불쾌한 경험 이었기 때문입니다.

그는 정확한 모델 인 언급되는 https://en.wikipedia.org/wiki/Teletype_Model_33 이 경우에는.

약간의 연구 ( http://www.pdp8.net/asr33/asr33.shtml ) 후이 기계를 사용하면 64 자의 풀에서만 선택할 수 있으며, 미국 ASCII 지원은 물론 2 자에서 6 자까지 가능합니다. 6 비트 조합입니다.

사실이 기계는 ASCII와 전혀 관련이 없습니다. ASCII의 첫 64 자만 지원할뿐 아니라 완전히 관련이없는 입력 세트 일 뿐이며 아마도 표준 (현대 시대)의 문자 세트가 아닙니다. .

ASR 33 텔레타이프는 64 자 (대문자, 문자 및 기호 만 허용)를 인쇄 할 수 있습니다.

에서 http://www.pdp8.net/asr33/asr33.shtml

그리고 이것은 대문자를 지원하기 위해 실제로 6 비트 이상이 필요하고 대문자가 64 자 표시를 초과한다는 사실을 감안할 때 미국 ASCII가 아니라는 것을 분명히 증명합니다 (또는 표를 따르려면 소수점 이하 63 값)

    0 NUL    16 DLE    32      48 0    64 @    80 P    96 `   112 p 
    1 SOH    17 DC1    33 !    49 1    65 A    81 Q    97 a   113 q 
    2 STX    18 DC2    34 "    50 2    66 B    82 R    98 b   114 r 
    3 ETX    19 DC3    35 #    51 3    67 C    83 S    99 c   115 s 
    4 EOT    20 DC4    36 $    52 4    68 D    84 T   100 d   116 t 
    5 ENQ    21 NAK    37 %    53 5    69 E    85 U   101 e   117 u 
    6 ACK    22 SYN    38 &    54 6    70 F    86 V   102 f   118 v 
    7 BEL    23 ETB    39 '    55 7    71 G    87 W   103 g   119 w 
    8 BS     24 CAN    40 (    56 8    72 H    88 X   104 h   120 x 
    9 HT     25 EM     41 )    57 9    73 I    89 Y   105 i   121 y 
   10 LF     26 SUB    42 *    58 :    74 J    90 Z   106 j   122 z 
   11 VT     27 ESC    43 +    59 ;    75 K    91 [   107 k   123 { 
   12 FF     28 FS     44 ,    60 <    76 L    92 \   108 l   124 | 
   13 CR     29 GS     45 -    61 =    77 M    93 ]   109 m   125 } 
   14 SO     30 RS     46 .    62 >    78 N    94 ^   110 n   126 ~ 
   15 SI     31 US     47 /    63 ?    79 O    95 _   111 o   127 DEL 

이제 우리는 코딩 된 테이블에서 지원하기위한 실제 표준 없이이 문제에서 64 개의 문자를 얻었으며 소문자가 없으며 대문자와 기호 및 숫자 만 가지고 있음을 알고 있습니다.

이 웹 사이트 http://keyboards.jargon-file.org/#ASR33 덕분 에 그런 키보드의 입력 레이아웃을 보여줄 수 있습니다

여기에 이미지 설명을 입력하십시오

SHIFT를 누르면

여기에 이미지 설명을 입력하십시오

또한 문자를 생성하는 실제 연결이 http://jargon-file.org/jargon-html/html/B/bit-paired-keyboard.html 로 코딩되는 방법에 대한 자세한 정보가 있습니다 (페이지에서 ASR33 ASCII 문자는 비트 수준에 따라 다릅니다.

나는이 더 없는지주의하는 것이 재미 있다고 생각 {또는 }()아마 만드는 서브 쉘이 좋아하지만, 새로운 프로세스를 생성했다 수단 아마 너무 쉬웠다 또는 터미널에서 허용이.

결국 나는 진정한 과학적 대답 이 있다고 생각하지 않습니다. 아마도 특별한 의미를 기다리는 "자유로운"인물 일 것입니다. 쉘과 터미널이 ASCII보다 오래되었고 ASCII 또는 코딩 된 테이블에 대해 생각하는 것은 오늘날 미스터리를 해결하지 못할 것입니다.


:부호와 쉘 에 더 많은 것 stackoverflow.com/questions/3224878/…
user31223
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.