376

(11개의 댓글, PunBB 맛보기 글에 작성됨)

이 곳의 글타래를 보면, search_words 테이블에 있는 word 필드의 type을 VARCHAR에서 VARBINARY로 바꾸면 문제가 해결된다는군요.

아무래도 utf-8 이외의 인코딩 값으로 된 검색어 저장에 문제가 있나 봅니다.

377

(11개의 댓글, PunBB 맛보기 글에 작성됨)

그 한국어라는 인코딩 값이 어떤 것인가요?

참고로, utf-8과 더불어 http://www.iana.org/assignments/character-sets에 등록된 한국어 인코딩은 euc-kr, iso-2022-kr이 있습니다. x-windows-949(ms949)와 같은 인코딩 값은 다른 플렛폼들에서는 인식을 못 할 수도 있으므로, 웹 페이지의 charset 값으로는 권장되지 않습니다.

웹 브라우져에서 자동으로 웹 페이지에 지정되어 있는 인코딩 값을 사용하도록 해서 글들이 잘 보인다면, 정상이겠군요. 물론, 웹 페이지에 지정된 인코딩 값 이외의 것으로 페이지를 읽어드리면, 당연히 글자들이 깨져보이겠지요.

378

(11개의 댓글, PunBB 맛보기 글에 작성됨)

기본 인코딩 값을 변경했다고 메인 화면에 아무것도 보이질 않는다는 것은 조금 이상하군요. 인코딩 값이 틀리더라도 메인 화면에는 깨진 글자들이라도 보이게 되거든요.
인코딩이 틀려서 생기는 문제가 아닌 듯 합니다만, 웹 서버의 기본 인코딩 값(AddDefaultCharset)이 일치하는지도 확인해 보세요. 그리고 아파치 서버의 error_log에도 혹시 수상한 것이 찍혀있는지 확인해 보시구요.

혹, 원래의 PunBB 파일들을 수정했었다면, 원본을 대치해서 문제가 지속되는지 알아보는 것도 문제의 원인을 찾는데 도움이 될 듯 합니다.

참고로, my.cnf의 default character set이 euckr로 되어 있다면, 개별 데이타베이스를 생성할 때 character set 값을 따로 지정해 주지 않는 한, 모든 db들은 기본적으로 설정되어 있는 character set을 따릅니다.

379

(11개의 댓글, PunBB 맛보기 글에 작성됨)

PunBB의 charset 설정은 lang/Korean/common.php 파일의 'lang_encoding' 값에 지정되어 있습니다. 이 값을 고쳐주시면 되겠네요.

380

(0개의 댓글, Mac OS 글에 작성됨)

새로 배포되고 있는 Boot Camp Beta 1.0.2에서는 개선된 Windows XP 드라이버들이 내장되어 있다고 합니다. 그래서, 이전에 Boot Camp Beta 버전을 설치했었다고 하더라도, 다시 한 번 Windows XP 용 Apple 드라이버 CD를 구워야만 하는데, MacFixIt에 올라온 기사에 따르면, 이 드라이버 CD를 굽지 않고서도 새로운 드라이버들을 설치하는 방법이 소개되어 있어서 이 곳에도 그 방법을 옮겨놓습니다.

먼저, Boot Camp를 설치하면 생기는 Boot Camp Assistant(Applications/Utilities/) 어플리케이션의 아이콘을 선택하고 "패키지 내용 보기"로 열어서, Contents/Resources/ 폴더 속에 있는 "DiskImage.dmg" 파일을 두 번 클릭해서 마운트 시킵니다. 이렇게 해서, 화면에 올려진 디스크 이미지의 내용을 Windows XP로 부팅시 접근 가능한 외장 드라이브나 다른 파티션에 복사해 놓습니다. 물론, Windows XP가 설치되어 있는 볼륨이 FAT 32 형식으로 포멧되어 있다면, 바로 이 곳으로 복사해 넣으셔도 되겠습니다.

이제, 드라이버들의 설치는 Windows XP로 시동한 후에, 아까전에 복사해 넣었던 파일들 중 "Install Macintosh Drivers for Windows XP.exe" 파일을 실행시키면 되겠습니다.

이 방법은 나중에 또 새로운 버전으로 배포될 Boot Camp에서도 비슷하게 적용될 수 있으리라 기대합니다. 그러면, 불필요한 CD의 낭비는 막을 수도 있겠군요.

381

(2개의 댓글, 맥 개발 글에 작성됨)

Widget에게 sudo의 마력을 얹어 주기

Giving Your Widget that sudo Voodoo

위에 소개된 글에서는, widget에서 system() 함수를 통한 광범위한 유닉스 터미널 도구들을 사용할 때 참고가 될 만한 여러 요령들과 더불어서 sudo 명령을 사용하고자 할 때, 그 구현 방법과 미리 염두에 두어야 할 여러 주의 사항들을 자세한 예제들을 통해 소개하고 있습니다.

382

(2개의 댓글, 맥 개발 글에 작성됨)

Dashboard가 화면 상에서 감추어져 있을 경우, 모든 widget들은 불필요한 CPU 소비량이 없어야 합니다. 이것을 구현하기 위해서, O'Reilly Network에 소개된 The Widget Maker's Prime Directive라는 제목의 글에서는 크게 두 가지를 제시하고 있습니다.

우선, onshowonhide에 지정되어 있게 될 함수들을 잘 활용해야 합니다.

if (window.widget){
    widget.onhide = onhide;
    widget.onshow = onshow;
}

function onhide() {
    //stop processing...
}

function onshow() {
    //restart processing...
}

위에서처럼, onshowonhide에는 Dashboard가 보여지고 숨겨질 때마다, 실행되는 일종의 정리하는 코드들이 들어가는데, 이 곳에서 살펴야할 불필요한 주요 CPU 소비 형태들로는, 움직이는 .gif 파일들의 사용과 불필요한 Interval들의 사용이 있습니다.

움직이는 .gif 파일들의 경우에는, onhide 안에 다음과 같은 코드를 심어서 Dashboard가 감추어질 경우 불필요한 CPU 소모를 없앨 수 있습니다.

document.getElementById("myGifId").style.display = "none";

그리고, Dashboard가 열려서 다시 .gif 파일을 표시하려면 onshow에 다음과 같이 처리해 주면 됩니다.

document.getElementById("myGifId").style.display = "inline";

또 하나 setInterval()clearInterval()을 써서 어떤 지속적으로 반복해서 실행되는 동작을 구현했을 경우에는, 아래의 예에서와 같이 setInterval()을 부를 때 전역 변수에 넣어서 나중에 Dashboard가 감추어질 때 clearInterval()로 정지시킵니다.

var timer = null;
var active = false;
function someEvent(event){
    timer = setInterval("doSomethingOverAndOver()", 100);
    active = true;
}


function onhide(){
    if(null != timer){
        clearInterval(timer);
        timer = null;
    }
}

function onshow(){
    if(true == active){
        timer = setInterval("doSomethingOverAndOver()", 100);
    }
}

이러한 사항만 잘 지키면, 대부분의 불필요한 CPU의 부담을 덜어줄 수 있답니다.

383

(5개의 댓글, PunBB 맛보기 글에 작성됨)

DB에도 문제가 없다면, Mod나 Plugin들을 설치하면서, 문제가 생겼을 수도 있겠군요. 물론 어느 시점에서 이런 문제가 시작되었는지 알 수 있다면 문제 해결도 쉬울 것이라 생각되지만, 제가 해드릴 수 있는 말은 새로 설치했거나 수정했던 내용들을 다시 한 번 찬찬히 살펴보시라는 것 밖에는 없네요.

그리고, Image Upload Mod와 Attachment Mod와의 충돌 문제는, Image Upload Mod의 개발자가 전에 언급했던 내용이 있어서 제가 물어본 것입니다. 그 때는 둘 중에 하나만 사용할 수 있다고 했었거든요.
지금은 둘 다 잘 작용한다고 하셨으니, 갱신되면서 이 부분이 고쳐진 것인지도 모르겠군요.

384

(5개의 댓글, PunBB 맛보기 글에 작성됨)

설정의 문제가 아니라면, 포럼 DB의 데이타가 올바로 저장되어 있는지 확인해 보시기 바랍니다.
users 테이블에 있는 Guest(id=1)의 group_id가 3으로 되어있어야 합니다.
그리고, groups 테이블에 저장되어 있는 손님의 권한 설정 내용도 제대로 되어 있는지 확인하시구요.

그런데, Attachment Mod와 Image Upload Mod를 동시에 설치해도 둘 다 제대로 동작을 하나요?
동시에 설치를 하면, 충돌이 있다고 하던데...:roll:

385

(12개의 댓글, Mac OS 글에 작성됨)

위에서도 이미 설명되어 있듯이, 파일이나 폴더 이름이 점(.)으로 시작하면 Finder에서 숨겨지게 됩니다.

간단하게 그냥 숨기려고만 할 때 쓸 수 있는 방법으로 터미널의 mv 명령을 쓰면 됩니다:

mv ~/test ~/.test

위의 예에서는. 자신의 홈 디렉토리에 있는 test라는 이름의 폴더를 감추어 줍니다. 이렇게 해놓고, 나중에 접근할 때마다, Finder의 메뉴막대에 있는 "폴더로 가기..."를 선택해서 폴더의 경로를 입력하면 됩니다. (여기서 열었던 폴더들은 "최근에 열었던 폴더들"의 기록에 남게 된답니다.)

숨겨진 폴더를 원래의 상태로 되돌리는 방법은:

mv ~/.test ~/test

386

(12개의 댓글, Mac OS 글에 작성됨)

위에서 설명된 숨겨진 디렉토리들에 쉽게 접근할 수 있게 해주는 열려라 참깨! widget의 오류나 건의 사항이 있으시면, 이 곳에 의견을 남겨주시기 바랍니다. wink

387

(12개의 댓글, Mac OS 글에 작성됨)

Mac OS X의 숨겨진 파일들과 디렉토리들

옮긴 글 - Mac OS X Hidden Files & Directories

Mac OS X 볼륨에는 상당히 많은 파일들과 디렉토리들(폴더들)이 Finder에서는 보이질 않습니다. 대부분은, 그럴만한 이유가 있어서 숨겨져 있으며 특별한 경우가 아니라면 건드릴 필요도 없을 겁니다. 하지만, 만약을 대비해서 숨겨져 있는 것들의 대략적인 설명을 이 곳에 해놓았습니다.

._어쩌구저쩌구 - 이 파일들은 본래 HFS 파일 특성들을 완전하게 지원하지 못 하는 볼륨들(예를 들어 ufs 볼륨들, Windows 파일 공유 등)에 생성된다. 그래서 Mac 파일들이 이런 볼륨으로 복사될 때, 파일의 데이타 포크(data fork)는 파일 이름으로 저장되고, 더불어 추가 HFS 정보(resource fork, type & 생성 코드, 등)는 "._"로 시작하는 이름의 추가 파일(AppleDouble 형식)에 저장된다. (물론 이런 파일들은 OS X 상에서는 보이질 않지만, 기타 OS들에서는 그렇지를 않아서 어떤 경우에는 이것이 문제가 될 수도 있다.)

.DS_Store - 이 파일은 Finder에 의해 생성되며 폴더의 보기 선택사항들, 아이콘 위치, 그리고 폴더에 관한 가시적 정보들을 저장하게 된다. 각각의 .DS_Store 파일들은 여러 해당 디렉토리들에 관한 정보들을 저장해 놓기 위해 매 디렉토리에 개별적으로 생성되기 때문에, OS X Finder에서 열어본 폴더들에는 항상 이 파일이 생성되기 마련이다.

~/.Trash - 특정 사용자가 시동 볼륨에 있는 파일들이나 폴더들을 휴지통으로 버렸으나 아직 지우지는 않았을 경우에 임시로 보관되는 곳.

/.Spotlight-V100 - 메타데이타(metadata) 색인들과 Spotlight(버전 1.00)의 색인 규칙들의 정보가 저장된 곳. Mac OS X 10.4에서만 생성됨.

/Volumes/(어쩌구저쩌구)/.Trashes - 시동 볼륨이 아닌 볼륨들의 경우, 휴지통에는 버려졌으나 아직 지워지지 않은 파일들이나 폴더들이 .Trashes 폴더에 임시로 저장된다. 각각의 사용자들은 저마다의 개인 휴지통을 가지고 있기 때문에 .Trash의 바로 아래 디렉토리에는 각 사용자 ID에 해당하는 이름의 하위 폴더가 생성된다. 예를 들어, ID 501의 사용자가 "Data" 볼륨을 휴지통으로 버리게 되면, 바로 /Volumes/Data/.Trashes/501/ 디렉토리로 이동된다.
이 폴더의 권한은 오직 버렸던 사용자만이 접근할 수 있게 되어 있으며, 다른 사용자의 휴지통에 버려진 파일들의 목록은 볼 수가 없다.

/.hidden - 이 곳에는 Finder가 숨기려는 파일들의 목록이 저장되어 있다 - 이것은 OS X에서 파일들을 안보이게 할 수 있는 세 가지 방법들 중 하나이다. (여기서 이 세 가지 방법들은 아래의 내용을 참고.) 이 방법은 이젠 구식이어서, Mac OS X 10.4의 표준 설치 상태에선 비어있게 되지만, 아직은 만약 이곳에 파일이 존재하게 되면 Finder에서는 이것을 참고하게 된다.

/.hotfiles.btree - 일반적으로 사용되는 작은 파일들의 디스크 상 위치를 추적하는데 사용되며, 나중에 최적화 작업(adaptive hot file clustering)에 이 정보가 읽혀진다.

/.vol - 이 가상 디렉토리는 파일들에 접근할 때, 이름이 아닌, 파일의 ID 번호(inode 번호)를 가지고 접근할 때 사용된다. 예를 들어, /.vol/234881034/105486/는 #234881034 볼륨에 있는 #105486 파일을 가르킨다.

/automount - OS X 10.1에서 네트워크 볼륨들의 "일종의 정적" 마운트 작업들을 관리하는데 사용된다. 대부분의 유닉스들에서는, 네트워크 볼륨이 클라이언트에서 정적으로 마운트될 시에, 파일 시스템의 어딘가에 올려지게 되어 일반 디렉토리처럼 보여진다. OS X 10.1에서 정적으로 마운트된 네트워크 볼륨은 실제적으로 /automount에 올려지고, 심볼릭(symbolic) 링크로 볼륨이 일반적으로 올려지는 곳을 가리키게 되면서 정상적인 볼륨처럼 보이게 된다. (이것은 아래에서 설명된 /private/Network를 통해 처리되는 네트워크 마운트 동작과 차이가 있다.)

/bin- 이 곳은 유닉스 형태의 binary들(말하자면, 프로그램들, 혹은 터미널 명령들)이 위치하고 있는 몇 가지 여러 장소들 중의 한 곳이다. /bin 속에 위치하는 프로그램들은 유닉스 터미널과 여러 shell들에서 사용되는 아주 일반적이고 기본적인 것들이다. (예. ls 그리고 rm)
이것들 외에 기타 비슷한 파일들은 /sbin, /usr/bin, /usr/sbin, 그리고 /usr/local/bin, /usr/local/sbin, 또 터미널에서 일반 /Applications 디렉토리와 비슷하게 생각될 수 있는~/bin/powerpc-apple-macos에 위치하고 있다.

/cores - (이것은 실제로 /private/cores에 위치하고 있으며, /cores는 symbolic 링크에 불과하다.)
어떤 특정한 상황에서, 만약 프로그램이 죽는다면, 프로그램이 죽었을 당시의 상태 복사본이 담긴 "core를 쏫아내게" 되는데 이것들이 저장되는 장소가 바로 이 곳이다. 이 곳은 단지 프로그램의 오류를 찾으려는 프로그래머들에게나 쓸모가 있다.

/div - 이 디렉토리에는 기술적으로 장비의 특수 파일들(device special files)이 위치하고 있다. 이것들은 일반적 상식의 실제 파일들은 아니고, 시스템에 붙어있는 장비들(디스크, 키보드, 모니터, 네트워크 접속 등)을 관리하기 위한 저장소와 같은 구실을 한다.

/etc - (이것은 실제로 /private/etc에 위치하고 있으며, /etc는 symbolic 링크에 불과하다.)
일반적인 유닉스 시스템에서 /etc 폴더는 설정 정보를 지정하는 문서들과 실제로 다양한 설정 작업들을 실행하는 스크립트들을 포함하는 시스템 설정 파일들이 저장되어 있다. OS X에서 이곳에 저장된 몇몇 설정 정보들은 NetInfo 혹은 기타 디렉토리 서비스들에 의해 덮어씌어지게 되지만, /etc 파일들은 계속 존재하게 된다.

/lost+found - 만약 Disk Utility 혹은 fsck가 "고아가 된" 파일들(예를 들어, 파일들은 존재하지만, 실제로 어떠한 디렉토리에도 위치하지 않은 파일들)을 발견시, 이 곳에 저장된다.

/Network - 이것은 Finder에서 컴퓨터 수준으로 보여지는 네트워크 항목의 "실제" 위치이다. 여기는 네트워크 자원들과 서버 볼륨들을 붙이기 위해 필요한 장소를 제공한다. OS X 10.1에서 네트워크 자원들은 실제로 /private/Network에 올려지는 경향이 있으며, 이것을 가리키는 symbolic 링크가 /Network에 생성된다.
OS X 10.3의 경우, 다양한 네트워크 자원들(주로 서버들)은 (약간은 가상 파일시스템의 마법 덕분에) 유동적으로 /Network에서 보여지게 된다.

/mach, /mach.sym, /mach_kernel - Mac OS X의 아주 밑바닥 핵심에서 실행되는 Mach 커널로서, 이것에 접근할 수 있는 몇 가지의 단축 방법들이 함께하고 있다.

/private - OS X에서 특정 루트 수준의 디렉토리들은 실제로 /private에 위치하는 디렉토리들을 가리키는 symbolic 링크들이다. 이러한 예에는 /cores, /etc, 그리고 /var들이 있으며, 이들은 각각 /private/cores, /private/etc, 그리고 /private/var와 연결되어 있다. /private은 또한 특정 주변 장치들의 드라이버들을 저장하고 있는 디렉토리들을 포함하고 있다.

/private/Network - OS X 10.1에서 네트워크 볼륨들의 (유동적) 네트워크 마운트들을 관리하는데 사용되었었다. 이전 버전에서는, 네트워크 마운트들은 /Network에 올려졌었으나, 10.1에 와서는 실제로 /private/Network에 올려지며, symbolic 링크가 /Network에 위치하면서 실제 마운트 포인트를 가리키게 된다.

/sbin - /sbin 디렉토리는 /bin과도 비슷하지만 시스템 관리에 사용되는 특정 바이너리들이 포함되어 있다는 것이 차이점이다. (예, mount 그리고 fsck)

/tmp - (이것은 실제로 /private/tmp에 위치하고 있으며, /tmp는 symbolic 링크에 불과하다.)
하드 디스크의 임시 공간이 필요로한 프로그램들은 /tmp 디렉토리에 임시 파일들을 쓰게 된다. (간혹 /var/tmp가 대신 사용되기도 함.)

/usr - /usr 디렉토리에는 특정 일반 유닉스 사용자가 사용하는 바이너리들과 파일들이 저장되어 있는 많은 서브디렉토리들을 포함하고 있다.

/usr/bin - 유닉스 바이너리들이 저장되어 있는 또 다른 장소.

/usr/lib - Mac OS X에서 프로그램을 짜는데 사용되는 라이브러리들. Developer Tools를 설치하지 않았다면, 대부분은 비어있게 된다. Mac OS X의 다양한 "Library" 디렉토리들과는 아무런 관계가 없다.

/usr/libexec - 다양한 디몬(daemon) 프로그램들, 시스템 유지보수 스크립트들, 그리고 기타 유닉스 형태의 보통 사람이 직접 실행하지 않는 프로그램들이 위치하는 곳.

/usr/local - 보통 대부분의 유닉스들에선, 이 디렉토리에 일반 OS 설치에 추가되는 맞춤형 파일들이나 추가 파일들이 저장된다. (예. /usr/local/bin에는 시스템 관리자에 의해 추가된 유닉스 바이너리들이 설치된다.) 이 디렉토리는 유닉스 격의 Mac OS X 로컬 라이브러리와도 비슷하게 생각될 수 있다. 기본 Mac OS X 설치시에 이 곳은 당연히 완전하게 비어있다.
주의: OS X 10.2에서는, 이 곳 디렉토리들이 더 이상 터미널 실행 파일들을 위한 검색 경로로 포함되어 있지 않다. 결과적으로, 이 곳에 설치되어 있는 것들은 추가적인 조치를 해주지 않는 이상 사용될 수가 없다.

/usr/sbin - 유닉스 바이너리들이 저장되어 있는 또 다른 장소.

/usr/share - 기본적으로 여러 시스템 구조들에서 공통적으로 사용될 수 있는 여러 데이타들과 텍스트 파일들이 포함되어 있다. (이 디렉토리가 가지는 차별성은 Mac OS X 말고 서로 다른 구조와 형태들을 갖는 유닉스들에서 더 적절하게 이해될 수 있을 것이다.)

/usr/standalone - (잠재적으로) 다양한 컴퓨터 형태들을 위한 부트 로더(boot loader) 프로그램들이 저장된 곳. 내가 살표본 바로는, 이것은 단지 System/Library/CoreServices/BootX 디렉토리에 있는 BootX loader의 복사본에 지나지 않지만, 왜 두 개의 복사본이 필요한지는 이유를 알 수 없다.

/var - (이것은 실제로 /private/var에 위치하고 있으며, /var는 symbolic 링크에 불과하다.)
가끔 OS에 의해 조종되는 작업들은 변수 파일들을 저장할 장소가 필요하게 된다. 인쇄 작업이나 로그 파일들을 저장하는 프로그램들은 /var 디렉토리 아래에 위치하는 하부 디렉토리에 이런 파일들을 저장하게 된다. 또한 이 곳에는 (특히 /var/db의 경우에) 많은 양의 설정 관련 정보들을 저장하고 있다.

/var/backups - 중요한 시스템 정보들의 백업들을 저장하는데 사용된다. (주로, 매일 밤 저장되는 NetInfo 데이타베이스들)

/var/db - 시스템 정보에 관란 다양한 데이타베이스들이 저장된 곳. 가장 대표적인 것은 /var/db/netinfo에 저장된 NetInfo 데이타베이스들과 시스템의 네트워크 설정 데이타베이스(/var/db/SystemConfiguration/preferences.xml - 10.3에 와서는 /Library/Preferences/SystemConfiguration/으로 옮겨졌다.)가 있는데 대부분은 시스템과 네트워크 설정 정보가 저장되어 있으며, 전통적인 유닉스 관점에서는 /etc 디렉토리에서 찾을 수 있는 파일들이다.

/var/log - 이 곳에는 많은 시스템 이벤트들의 로그 파일들이 저장되어 있는 곳으로 기타 다른 로그 파일들은 /Library/Logs/ 디렉토리에도 위치한다.

/var/root -  루트(root 혹은 superuser) 계정의 홈(Home) 디렉토리. 주의할 것은 비록 루트 계정을 활성화 하지 않았더라도 존재하게 된다.

/var/run - 시스템에서 실행되고 있는 작업들(특히 daemon들)에 관한 다양한 상태 정보가 저장되어 있는 곳.

/var/tmp - /tmp와 같이 프로그램들이 임시 데이타를 저장하는 곳. 어떤 프로그램들은 이 곳을 사용하고, 또  어떤 것은 다른 곳을 사용하기 때문에 Mac OS X에서는 두 곳 모두를 제공하고 있다.

/var/vm - Mac OS X의 가상 메모리를 위한 바꿔치기(swap) 파일들이 저장되는 곳.

/var/vm/app_profile - 다양한 어플리케이션들의 가상 메로리 사용 현황에 관한 정보가 있는 곳.

/Volumes - /Volumes 디렉토리는 시스템에 접속되어 있는 (시동 볼륨을 제외한) 모든 장비들의 마운트 포인트(mount point)가 된다. Finder에서는 Volumes 디렉토리 자체는 숨기지만, 그 내용물은 컴퓨터에서 보여지게 된다.

왜 7 개나 되는 바이너리 디렉토리들이 필요한가?

Mac OS X의 터미널에서 명령어를 치면, 적당한 프로그램을 돌리기 위해 모두 7 군데의 디렉토리를 찾게 됩니다. 왜 이리 많냐고 생각하실겁니다. 글쎄요, 설명하자면 이들은 몇 가지의 서로 다른 특성들에 의해 구분되어져 있고, 또한 이런 특성들은 더 많은 조합들의 가능성을 가지고 있기 때문에, 결국은 다양한 서로 다른 구분들에 의해 프로그램들이 나뉘어지게 되었습니다. 여기에는 비교적 일정한 형식으로 구분될 수 있는 6 개의 디렉토리들이 있으며, 나머지 하나는 어떻게 잘 구분될 수도 없는 것이 있습니다. 먼저 처음의 6 가지의 디렉토리들에 대해 이야기해 보겠습니다.

첫 번째 구별법: "bin"과 "sbin". 이 6 개의 일정한 디렉토리들은 "bin"과 "sbin"의 이름들이 서로 쌍으로 존재하고 있다. "bin" 버전에는 일반적으로 사용되는 프로그램들이 포함되어 있으며, "sbin" 버전에는 통상 시스템 관리를 목적으로 하는 프로그램들이 포함되어 있다. 이것의 구별은 어쩌면 제멋대로일 수도 있으며 (예를 들어, IP ping 도구는 sbin 디렉토리에 있지만, 이것의 AppleTalk 버전은 bin 디렉토리에 위치한다), sbin에 위치한 프로그램들은 (비록 몇몇은 관리자 혹은 root 권한이 아니면 실행되지 않을 수도 있지만) 모든 사용자들에게 접근 가능하다.

두 번째 구별법: / 와 /usr/ 그리고 /usr/local/. 이들 각각의 디렉토리들은 bin과 sbin의 하부 디렉토리들을 포함하고 있다. 대부분의 프로그램들은 /usr/ 버전에 위치하고 있으며, 몇몇의 더 중대한 핵심 프로그램들(특히 시동 작업에 필요한 것들)은 대신 / 디렉토리들에 위치한다. 이러한 이유는, /usr 디렉토리를 네트워크의 매 컴퓨터들마다 독자적인 복사본을 저장해 둘 필요없이 파일 서버에 보관할 수도 있기 때문이다. 그래서, 클라이언트 컴퓨터가 /usr 디렉토리에 접근할 필요 없이도 서버에 접속해서 접근 가능할 수가 있게 되며, 절대적으로 필요한 프로그램들은 언제나 사용 가능한 /bin 혹은 /sbin에 위치해야 한다. 마지막으로, 컴퓨터에서 직접 설치한(에를 들어, Apple에 의한 일반 시스템 설치가 아닌 시스템 관리자에 의해 설치된) 프로그램들은 /usr/local/에 위치하게 된다. 그래서 만약 표준 OS X 시스템에선, /usr/local 디렉토리가 완전하게 비어있는 것을 확인할 수가 있다.
주의: 10.2에서는, /usr/local/bin과 /usr/local/sbin 디렉토리는 터미널의 기본 검색 경로에서 제외되어 있어서, 기본적으로는 별 쓸모가 없게 되었다.

마지막으로, bin/sbin 쌍을 이루는 형식에도 맞지 않는 독특한 성질의 디렉토리가 있는데, 그것은 바로 ~/bin/powerpc-apple-macos라는 이름을 가진 (이제는 존재하지 않는) 사용자의 개별 bin 디렉토리입니다. 왜 이런 이상한 이름을 가졌냐구요? 원래는, 만약 홈 디렉토리가 네트워크 상에서 몇몇의 서로 다른 구조의 컴퓨터들(Linux, Solaris...)과 공유되어 있을 경우를 대비해서 존재하고 있습니다. 일반적으로 사용하고자 하는 어떤 한 바이너리 프로그램은 서로 다른 구조의 컴퓨터들에서는 작동하지 않을 수도 있기 때문에, 어떠한 특정 컴퓨터를 사용하느냐에 따라 또 다른 바이너리들 준비해 두고 싶을 때가 있을 것입니다. 그 때 이 디렉토리가 사용되는데, 10.1에 와서는 기본 검색 경로에서 삭제되었기 때문에, 지금은 단지 과거 기록으로서만 남아있습니다.

숨겨둔 이유들

Mac OS X는 Finder에서 파일과 폴더를 감추는데 세 가지의 방법이 사용됩니다. - 예전의 Mac OS 시스템들에서는 "안보이는" 파일 속성이 있었고, 유닉스 시스템들에서 사용되는 것 처럼 파일 이름이 "."로 시작되거나, 혹은 파일이 /.hidden file의 목록에 포함되어 있을 수 있습니다. 위에서 설명된 많은 파일들과 디렉토리들은 실제로 여러가지 방법들로 감추어져 있습니다. (예를 들어, /bin은 /.hidden 목록에 포함되어 있으며, 또한 안보이는 속성을 가지고 있습니다.)

주의할 것은 OS X는 오로지 시동 볼륨의 .hidden 파일들만 인식을해서, 만약 다른 디스크에서 시동을 하게 되면, 정상적으로는 보이지 않았던 파일들이 갑자기 나타나게 됩니다. 또한, Mac OS 9과 같은 예전 버전들에서는 안보이는 파일 속성만을 인식하기 때문에, Mac OS 9으로 시동하면 더 많은 파일들(주로 /.vol, /mach, /mach.sym, 그리고 몇몇 .DS_Store)이 보여지게 됩니다.

추가 참고 글 - OS X Server의 파일 디렉토리 구조

388

(178개의 댓글, Mac OS 글에 작성됨)

직접 손쉽게 추가하실 수 있는 7even이라는 이름의 아이콘 꾸러미를 달아놓습니다. 7even.zip(764 KB) 내려받기  wink

http://appletree.or.kr/forum/files/7even_iconset_preview.png

389

(178개의 댓글, Mac OS 글에 작성됨)

바깥 날씨 widget에서 사용하고 있는 아이콘 꾸러미들은 아쉽게도, 제가 가진 재능의 모자름으로 인해, 제가 직접 만든 것들이 아닌 다른 사람들이 공개한 아이콘들을 사용하고 있습니다. 하지만, 이미 웹 상에 멋진 아이콘 꾸러미들이 다양하게  배포되고 있기 때문에, 이들 중 마음에 드는 아이콘 꾸러미를 바깥 날씨 widget에 추가하는 것도 그리 어렵지는 않답니다.

여기에서 예를 들어 추가할 아이콘 꾸러미는 Samurize.com의 포럼에 공개되어 있는 아이콘들 중에서 Yahoo! Widget으로 통합되기 전 Arlo Rose씨가 제작한 Konfabulator의 날씨 widget에 사용되었던 아이콘 꾸러미를 추가해 보겠습니다.

먼저, 다음은 바깥 날씨 widget에 적용된 날씨 아이콘들의 이름과 해당 이아콘들의 번호입니다.

큰 아이콘들
thunderstorm-rain - 0
rain-windy - 1
thunderstorm - 4
rain-snow - 5
hail - 6
rain-snow-icy - 7
drizzle freezing - 10
rain-icy - 10
drizzle - 11
rain - 12
snow grains - 13
snow - 14
rime - 15
snow shower - 16
dust - 19
sandstorm - 19
fog - 20
mist - 21
cloudy-windy - 23
cloudy - 26
most cloudy-moon - 27
most cloudy-sun - 28
partly cloudy-moon - 29
partly cloudy-sun - 30
sunny-moon - 31
sunny-sun - 32
funnel cloud-moon - 33
funnel cloud-sun - 34
sunny-sun-hot - 36
rain shower - 40
blowing snow - 43
snow-windy - 43
na - na

작은 아이콘들
rain and snow - 5
rain - 12
snow - 16
fog - 20
mist - 21
cloudy - 26
most cloudy - 28
partly cloudy - 30
sunny - 32
thunderstorm - 38
rain shower - 40

그림파일들의 형식은 모두 .png 파일이며 아이콘들의 크기는 큰 아이콘들의 경우 120x120 pixels, 작은 아이콘들의 경우는 28x28 pixels입니다.

이제, 내려받은 아이콘들을 각 번호에 해당하는 이름들로 고치고, 작은 아이콘들은 해당하는 번호의 큰 아이콘들의 아이콘을 적당한 그래픽 편집 어플리케이션을 사용해서 알맞은 크기로 작게 만든 후에 사용합니다.

새로운 아이콘 꾸러미를 담아 놓을 Konfabulator라는 이름의 새로운 폴더를 만든 후에 큰 아이콘들을 넣고, 작은 아이콘들은 이 폴더 속의 새로운 small_icons라는 이름의 폴더 속에 집어넣습니다. 이렇게 하면 새로운 아이콘 꾸러미의 준비는 끝나게 됩니다.

이렇게 해서 준비된 아이콘 꾸러미를 바깥 날씨 widget을 선택하고 마우스의 오른쪽 클릭하면 보이는 "패키지 내용 보기"로 열어서, weather_icons 폴더 속에 집어 넣습니다.

다음은 패키지 속의 JavaScript 파일인 WeatherOutside.js를 적당한 문서 편집기로 열어서 다음과 같이 코드를 수정해 주어야 합니다.

38 번째 줄에 있는 다음과 같은 코드를 적당하게 수정해 줍니다. (바깥 날씨 widget 2.5.3 이후의 버전 기준)

var weatherIconNames = { 0: "Simple", 1: "Shiny", 2: "Samurize", 3: "Kapsules", 4: "Konfabulator", 
5: "Jivesucker", 6: "Babasse", 7: "Epona", 
8: "새로운 아이콘 꾸러미의 이름", noOfIcons: 아이콘_꾸러미들의_총_갯수 };

이렇게 해서 새로운 날씨 아이콘 꾸러미를 추가하는 작업이 끝났습니다.
마지막으로 widget을 다시 실행시키면 새로운 아이콘 꾸러미를 선택해서 보실 수 있을 겁니다. smile

http://appletree.or.kr/forum/files/weather_outside_new_icons.png

390

(1개의 댓글, 오순도순 글에 작성됨)

잘 오셨습니다. smile

PunBB, 참 괜찮지요.
잘 설치해서 멋진 포럼 운용하시길 바랍니다.