bash 설정 중 builtin 'cd' 명령을 override하여, 특정 디렉토리로 이동시 임의의 동작을 실행 할 수 있다.

특정 디렉토리로 이동하여 매번 같은 명령을 실행하는 경우 매우 유용하다.


나의 경우 다음 fuction을 이용하여 'cd'를 override 하였다.


function cd {

    # actually change the directory with all args passed to the function

    builtin cd "$@"

    # if there's a regular file named "todo.txt"...

    if [ -f "todo.txt" ] ; then

        # display its contnets

        cat todo.txt

    fi

    # if there's a shell script named ".enc"...

    if [ -f ".enc" ] ; then

        # run script

        source .enc

    fi

}



'cd' 함수는 builtin cd "$@" 명령줄을 실행하여 기존 cd 명령을 수행한 후.


1) todo.txt 파일이 있다면 이를 보여 주고, (banner로 사용할 수 있겠다.)

2) .enc 파일이 있다면 이 파일을 실행한다. (특정 동작 실행)


다양한 용도로 사용할 수 있으니 참고하자.

레퍼런스는 stackoverflow였던 것 같은데, 정확한 url을 잊어버렸다. 향후 추가 예정​

지난 번 포스트에서 git log --graph가 한글로 표시될 때 줄바꿈 문제를 언급했었다.



이 때 사용한 git log 옵션은 다음과 같은데,


git log --graph --oneline --abbrev-commit --decorate [--all]


이번에는 --decorate 옵션 사용시 tag가 너무 많아서 보기가 힘들 때의 정리 tip이다.


우선 LESS 환경변수에 -S 옵션을 추가한다.

-S 옵션은 --chop-long-lines 옵션으로 긴 줄을 접어서 아래로 내리는(fold) 대신 잘라(chop)버린다.


-S option, see also the man-page.

    http://superuser.com/questions/272818/how-to-turn-off-word-wrap-in-less 참조


그러면 길게 한 줄로 내용이 표시되는데 decorate 의 표시 순서가 {hash, refs, log} 순이어서 log가 나오지 않는 문제가 발생한다.


* ca5f427 (tag: merge_18500, tag: VA-v2.0.0.0.8-rc3, tag: VA-v2.0.0.0.8-rc2, tag: VA-v2.0.0.0.8-rc1, tag: MII-v2.0.0.0.7-rc3.DB99  <-- log가 없음


이제 --decorate 대신 --format 옵션을 사용하여 decorate 옵션에 의해 생기는 화면과 유사하게 만들어 줄 차례다.


format 옵션에서 사용되는 변수 중 deocrate에 유사한 포멧은 "%h %d %s" 이다.

이 중 %d가 refs를 담당하고 있으니, 순서를 바꾸어 "%h %s %d"로 하면 log도 보이고 tag도 일부 보이는 상태가 된다.


* ca5f427 R #19294 kernel header include 경로 수정  (tag: merge_18500, tag: VA-v2.0.0.0.8-rc3, tag: VA-v2.0.0.0.8-rc2, tag: VA-v2   <-- log가 등장, tag는 여전히 일부만 출력


그냥 그대로 두면, 색깔이 너무 칙칙하다. 색은 format 옵션에 %C(색)으로 주고 %Creset 으로 취소 가능한데, docerate와 같이 tag, branch, remote 별로 다른 색을 주려면 git 버전이 1.8.3 이상이어야 한다.

As of git 1.8.3 (May 24, 2013), you can use %C(auto) to decorate %d in the format string of git log.

From the release notes:

 * "git log --format" specifier learned %C(auto) token that tells Git
   to use color when interpolating %d (decoration), %h (short commit
   object name), etc. for terminal output.)

    http://stackoverflow.com/questions/12694510/how-to-emulate-git-log-decorates-different-colors-per-branch-type 참고

    http://stackoverflow.com/a/16844346/55948 참고


따라서 다음과 같이,


"%C(auto)%h%Creset %C(auto)%s%Creset %C(auto)%d%Creset"


옵션을 주면 색색의 옷을 입은 log를 볼 수 있다.


완성된 git log 는 다음과 같다.


git log --graph --format="%C(auto)%h%Creset %C(auto)%s%Creset %C(auto)%d%Creset" [--all]


@ 주의할 점


 - refs는 tag, remote_branch, local_branch 순으로 표시되므로 tag가 많이 있으면 branch  정보가 가려져서 보이지 않는다. 기존 --deocrate 옵션과 병행하여 branch 정보를 빼 먹지 말자.

 - format 옵션에서 이미 oneline 옵션과 abbrev-commit 옵션을 override 하므로 graph 옵션만 넣으면 된다.

 - git 버전이 1.8.3 이하인 경우 %C(auto)가 먹지 않으므로 (auto) 자리에 직접 색을 넣든지 색을 빼든지 하도록 한다.



Embedded System 뿐 아니라, 데스크탑 또는 개발용 머신에서도 여러 버전의 binary를 관리하여 사용하고자 할 때가 있다.

이 경우, 직접 link를 관리하는 것 보다는 update-alternatives를 사용하는 편이 관리도 수월하고 낫다.


update-alternatives는 다음과 같이 사용 가능하다.


~#  update-alternatives --help

Usage: update-alternatives [<option> ...] <command>


Commands:

  --install <link> <name> <path> <priority>

    [--slave <link> <name> <path>] ...

                           add a group of alternatives to the system.

  --remove <name> <path>   remove <path> from the <name> group alternative.

  --remove-all <name>      remove <name> group from the alternatives system.

  --auto <name>            switch the master link <name> to automatic mode.

  --display <name>         display information about the <name> group.


<link> is the symlink pointing to /etc/alternatives/<name>.

  (e.g. /usr/bin/pager)

<name> is the master name for this link group.

  (e.g. pager)

<path> is the location of one of the alternative target files.

  (e.g. /usr/bin/less)

<priority> is an integer; options with higher numbers have higher priority in

  automatic mode.



몇 가지 옵션만 살펴 보면,


--display <name> : 해당 이름의 등록 정보를 보여준다.

--install <link> <name> <path> <priority> : <link>는 alternatives가 대표할 패스와 이름이다.

                <name> /etc/alternatives에 등록되는 그룹 이름이다.

                <path> 이번에 등록되는 실제 패스를 의미한다.

               <priority> 자연수로 표기되는 우선순위이며 클수록 우선순위가 높다.

--remove <name> <path> : 패스를 해당 그룹으로부터 제거한다.

--config <name> : 그룹의 사용 우선순위를 조정한다.


내부 동작은 다음과 같다.


1) --install 옵션을 통해 등록

2) <link>를 생성하고, link의 source를 /etc/alternatives/<name>으로 생성

3) /etc/alternatives/<name> 링크의 source를 등록한 <path>로 생성


즉, <link> -> /etc/alternatives/<name> -> <path> 형태로 링크된다.


상세 내용은 man update-alternatives 참조.


linux는 빠르고 효율적인 통신을 위해 다양한 socket option을 개발/소개하고 있다.

(물론 이러한 option이 linux에만 있는 것은 아니지만.)


이 글은 이러한 옵션을 찾을 때마다 추가 정리하여 관리하겠다.


1. TCP_NOPUSH

2. TCP_NODELAY

3. TCP_CORK

4. TCP_DEFFERED_ACCEPT

5. 

.bashrc와 .bash_profile은 구성과 용법에서 비슷해 구별이 어려운데, 다음과 같은 내용을 찾아서 기록해 둔다.


* .bash_profile : login 시 bash shell이 지정된 경우 한번 실행됨

* .bashrc : bash shell이 뜰 때마다 실행됨. 기본적으로 child shell은 parent shell의 속성을 공유하므로 path등은 여기에 둘 필요 없음.


요는 login시에 한번 실행되느냐, shell 생성시마다 실행되느냐.


reference는 https://kldp.org/node/38265


끝.

오랜만의 포스팅입니다.


회사에서 개발 도구의 하나로 git을 사용하는데, 남들은 GUI 형태의 멋진 툴들을 많이도 사용다더만 저는 옛날 사람인지 터미널에서 텍스트로 내리는 명령이 좋더라고요.


git log를 이용해서 이전 개발 이력을 많이 보는데, 


<pre>

git log --graph --decorate --pretty=oneline --abbrev-commit

</pre>


명령으로 graphical하게 보는 것을 좋하합니다.


이 때, commit에 tag가 많이 붙거나 커밋 로그가 긴 경우 윗 줄이 밀리는 현상을 발견하셨을 겁니다.

이 증상에 대한 해결 방법을 간략히 남기고자 합니다.


먼저, git log는 output을 다루기 위해 less를 사용하고 있습니다.

이 부분은 git config에서 core.pager로 설정할 수 있고요.

대부분의 linux 배포판에서 less의 옵션으로 '-r'을 사용하고 있는데, 이 부분을 '-R'로 바꾸어 줍니다.


<pre>

# echo $LESS

-r

# export LESS=-R

</pre>


다시 git log -- 를 실행해 보면, 이번에는 첫줄이 잘 나오는 것을 볼 수 있습니다만, 한글이 깨질 겁니다.

한글이 다시 나오도록 하는 방법은 LESSCHARSET을 'utf-8'로 설정하는 겁니다. 'euc-kr' 사용시에는

해당하지 않습니다만, 대부분의 배포판이 utf-8이지 싶습니다.


<pre>

# export LESSCHAR='utf-8'

</pre>


이제 끝났습니다.


매번 LESS와 LESSCHAR을 입력할 수 없으니


~/.bashrc 에 LESS와 LESSCHAR을 설정하고 종료합니다.


즐거운 개발 되시길 바랍니다.


# 참고 url


http://stackoverflow.com/questions/6983305/how-to-fix-git-log-output-missing-lines-in-less

http://divvun.no/doc/tools/utf-8-setup.html


저는 1.80KT 펌웨어에서 테스트했습니다. 개인적 용도와 목적으로 사용된 것이며 제가 인지하지 못한 저작권 문제가 발생하는 경우 글을 삭제하겠습니다. 혹여 아래 글을 보시고 따라 하시다가 문제가 생겨도 저는 책임을 지지 않으니 잘 판단하시기 바랍니다. 스토리가 워낙 내구성도 약하고 민감한 기계라고 하고 문제 발생시 A/S건 역시 힘드니만큼 사용자 개개인의 판단이 중요합니다.

잘 아시다시피 storyW는 olleh bookcafe 전용 기계라 다른 story 기계에서 가능한 기능(교보문고에서 구축한 도서관 - ebookcase 사용 - 에서 대출한 책 보기)이 지원되지 않고 있죠?

또한, 펌웨어 버전도 storyW 기준 1.80KT 즉 1.80의 KT향 버전으로 다른 story 기계(최신 1.88)와 다릅니다.

저도 포기하고 살던 차에 http://cafe.naver.com/ebook/126181 게시글을 보게 되었고요.
참고 문서인 http://openinkpot.org/wiki/Device/Story/RunArbitraryCode 에 따르면 임의의 명령을 root 권한으로 실행 가능하다고 합니다.
거기서 영감을 받아

"펌웨어 전체를 교체하기 보다 pdf를 실행하는 파일을 교체해 보자"

는 생각이 들게 되었습니다.

위 글에서 나온 참고 문서 http://vanderwijk.info/tags/hacking-e-reader-linux-hardware 에서 대략적인 story의 펌웨어 구조를 확인하고 제 storyW를 마루타삼아 가능성을 확인해 보았습니다.

http://cafe.naver.com/ebook/114774 에 보시면, 1.88 펌웨어에서 개선된 패치 펌웨어가 있습니다. 이 패치 펌웨어를 기반으로 작업을 진행했습니다.

참고 문서에 따르면 story 펌웨어는 zip으로 압축된 파일에 128B 헤더를 붙여 배포하는 것으로 보입니다. 분석에 따르면, 이 헤더를 제외하면 일반적인 zip 파일과 동일하다는 것이고 여기서 패치에 사용된 파일을 추출할 수 있습니다. (압축 파일에 암호가 걸려 있는데, 이 암호는 참고 사이트에서도 공개하지 않는 바 저도 공개하지 않겠습니다.)

압축 해제된 파일은 2개로 adoberm.feb와 tmp_comic.kbg 인데, 1.80KT 펌웨어에서 파일 구조를 받아 살펴본 바 adoberm.feb가 pdf 파일을 재생하는 실행 파일임을 추측할 수 있습니다. 따라서 이 파일을 교체시 별 문제가 없다면 교보문고 지원 pdf를 읽을 수 있다는 결론입니다.

다만, 이 실행 파일을 교체시 기존 olleh ebook에서 구입한 책을 읽을 수 있는가가 관건인데, 이 부분은 뒤에서 살펴보도록 하겠습니다.

http://cafe.naver.com/ebook/126181 에서 바탕화면 이미지를 교체하듯이 패치된 실행파일을 기존 디렉토리에 복사하는 방식으로 파일을 교체하였습니다. (만일을 대비하여 1.80KT 버전의 adoberm.feb는 SD카드에 복사하여 저장합니다.)

파일을 교체했으니 대출된 책이 읽히는지 확인합니다.

기존 펌웨어로는 ebookcase에서 stowyW로 복사한 파일이 열리지 않고 에러가 뜹니다만, 실행 파일을 교체한 후 잘 열리는 것을 확인할 수 있었습니다. 또한, 우려했던 사항인 olleh bookcafe에서 구입한 책도 잘 실행되는데 이 부분은 아무래도 epub와 pdf를 실행하는 파일이 달라서 문제가 안 된 것인지도 모릅니다. 또한 기존 adobe drm을 가진 파일의 실행도 무난히 잘 되었습니다. (첨부 사진 참조)

다만, 대출한 책 초반에 배경 이미지가 포함된 페이지를 여는 경우, 매우 긴 시간이 소요됩니다. 이 부분은 story EDU나 BASIC에서 동일한 지 확인이 필요합니다.

그럼 스크린샷 몇 장 첨부하며 글을 마칩니다.

01234567



# 이걸 펌웨어 해킹? 교체? 뭐라고 해야 할지 모르겠지만, 개인 사용에 있어 법적 문제가 없는지 또는 사용법 배포에 문제가 없는지 의문입니다. 이 문제가 해결되면 파일 교체에 사용된 상세 설정과 실행 파일을 공개하도록 하겠습니다.

# 이 글 공개 이후, iriver에서 파일 교체 가능한 위 방법을 막을 수도 있습니다. 물론 펌웨어 업그레이드를 해 줘야 가능한 얘기가 되겠습니다. ^^ 관계자의 빠른 펌웨어 업그레이드를 촉구합니다. ^^
google night에서 code review system인 mondrian을 보고, code review tool의 도입 필요성을 절감하고 있던 중, "못 살겠다 바꿔보자" 는 심정으로 스스로 찾아 나섰다.

우선 우리 project가 subversion을 사용하고 있기 때문에 다음과 같이

image0







검색하였더니,

image1






















와 같이 관련 사이트가 주욱 나온다.

대부분의 내용에서 검색되는 code review tool로


가 검색된다.

code review tool 각각의 설명을 곁들인

image2













사이트도 검색되어, 읽어보니 간단한 설명이 꽤 도움이 된다.









그 외에, programmer 전용 지식인 사이트인
stackoverflow
stackoverflow.com
을 알게 되었고, 이 사이트에서
웹기반 code review 사이트(?)인 refactormycode.com 등을 소개하였다.
eclipse 기반 jupiter 라는 code review 모듈도 소개되었다.

다음과 같은 메일링 리스트도 검색되었는데, 우리 상황과 비슷한 부분이 많아 참고가 되었다.
(코드 리뷰 전 commit 금지를 강제하고 싶은 환경, etc.)

이 중,

rietvelt는 mondrian을 만든 귀도가 apache2 라이센스로 내 놓은 것인데, subversion만 지원하는 것과 google app engine을 사용하고 있기 때문에 local install이 불가능할 것이라는 예상

code striker는 지원하는 VCS도 풍부하고 개발기간도 꽤 길어 안정성이 있을 것으로 보이는데, 다만 코드가 cgi/perl이라고 하여 local install에는 좀 무겁지 않을까 생각

review board는 vmware를 개발하면서 사용된 code review system인데, rietvelt과 마찬가지로 django와 python을 이용하였으며, local install이 가능할 것으로 예상.

따라서, evaluation 순서는 review board -> code striker -> rietvelt 가 되지 싶다.

상세 리뷰는 써 보면서 올릴 예정..


+ Recent posts