아장아장 프로그래밍2

catalina.out을 데일리로 파일롤링하고 싶었다. 

헤맨 경위 

찾으려니 잘 안된건 처음엔 dateext 옵션을 주지 않아서. 

그리고 처음에는 catalina.sh만 수정하면 되는 줄 알았음. (http://linuxism.tistory.com/298)

그런데 안돼서...dev/null로 하는건 로깅을 하지 않는다는 내용이었음. 

결과적으로는 logrotate를 설정하고, (sudo) 

이걸 crontab에 등록해서 매일 실행되도록 한다. 

참고: http://wizardee.tistory.com/150

http://blueskai.tistory.com/101

foreground / background

Background

- background 실행 명령을 하려면 & 를 명령행 마지막에 붙인다. 

- background 에서 실행되고 있는 프로세스들을 보려면 jobs 를 명령한다

- background에서 실행 중인 프로세스를 foreground로 되돌리려면 fg %<작업식별자>를 입력한다. 

작업 식별자란 jobs 의 수행 결과 나온 작업 순번이라고 생각하면 쉽다. 

Foreground

- foreground 에서 실행중인 작업을 중단시키려면 컨+z를 누른다. 

- 이 방법은 프로그램을 잠시 멈추게 할 때도 사용할 수 있다. 

- 컨+z로 멈춘 작업을 백그라운드에서 실행하게 하려면 bg를 명령행에 넣는다. 

- 작업을 중지하려면 jobs의 결과로 나오는 작업식별자로 프로세스를 중지할 수 있다. 

추신. 

백그라운드에서 작업중이던 내용이 데이터를 입력받아야 할 경우 반드시 포어그라운드로 끌어올린 후 입력을 마쳐야 한다. 그렇지 않으면 진행이 되지 않는다. 

https://dogfeet.github.io/articles/2012/git-merge-rebase.html

지금까지는 아예 로컬 데브를 최신으로 갱신하고 직접 데브에 머지해서 올리는 방법으로 풀리퀘스트를 제대로 써 본 일이 없다. 그런데 풀리퀘스트를 사용하니까 이렇게 충돌이 나는 상황을 개선할 방법이 마땅치가 않다. 

홀더 패턴이라는 것을 처음 이용해보았다. 거의 받아쓰기 하듯이 짝코딩을 했는데, 하고 나서 찬찬히 보고 문서를 살펴보니 좀 이해할 수 있게 되었다. 그리고 이건 좋지 않다. 키보드를 치면 화면이 너무 많이 흔들린다. 

홀더 패턴이라고 검색하면 잘 나오지 않고, Initialization on demand holder idion이라고 정의되어 있는 것 같다. 

간단히 훑어봤을 때 장점은 lazy loading이다. 형식은 아래 문서들을 참고하면 쉽게 이해할 수 있다. A클래스에 대한 getInstance()함수를 수행하면 A클래스의 싱글톤 객체를 리턴한다. 그렇지만 내부를 살펴보면 A클래스의 Inner class인 B클래스의 필드를 리턴하는 것으로부터 A클래스의 싱글톤 객체를 가져다 쓸 수 있게 되는 것이다. 

정리하자면 

- 검색해서 이해하기 좋았던 문서 2개 

1. http://gampol.tistory.com/entry/Double-checked-locking%EA%B3%BC-Singleton-%ED%8C%A8%ED%84%B4

2. https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom

구두로...

살다살다 별일을 다 겪는다고 생각했다. 무엇을 고쳤는지 생각나지 않을만큼 로그 수정을 많이 하고 나서 마침내 깃 커밋앤 푸시 버튼을 눌렀는데, 커밋은 잘됐는데 푸시가 원격지와 차이가 나서 충돌이 발생하는 것 같았다. 

- 커밋은 했으니 자신있게 깃 풀을 당겼다. 

- 깃 풀이 되었는데 내가 커밋해놓은 내용이 아예 사라졌다. 충돌 내역도 없어서 이상하다 싶었는데 내가 수정한 로그들이 원복되었다. 

---삽질---

- 로그 밖에 수정 안했으니까 처음부터 다시 하지 뭐, 라고 생각했는데 

1. stash를 확인했다. (비어있었음)

2. ctrl-v를 누르면 나오는 show history에 들어가 보니 내가 커밋한 커밋로그가 "n분 전" 하면서 살아있었다. 그런데 파일 하나로는 컨버트를 하면 안되고 프로젝트 최상위 폴더에 활성화 시켜놓은 채로 show history를 해서 원복하려는 상태를 선택하고 revert를 했더니 원복됐다. 

- 원인으로 추측하는 것

IDE. 즉 인텔리제이의 버그. 커밋로그는 남아있는데 커밋이 안 되어있을 수가...! 깃을 3년 썼지만 이런 일은 또 처음 겪었다. 나름 깃에 익숙하다고 생각하기 때문에 특히나 이해할 수 없었다. 

아래쪽에 보이는 Commit Changes: logger 정리해서 다시 푸쉬..가 내가 처음에 커밋한 내용이다. commit changes라고 있는데 커밋 내용이 없다는 것을 믿을 수 없었음...-_-

결국 한 칸 씩 눌러보면서 내가 복귀시키고 싶은 상태에 활성화 시킨 채로 좌측 상단에 있는 revert 버튼을 눌러서 복구했다. IDE에 적응하면서 상당부분 편하다고 느낀 점이 많았는데....버그가 있다는건 쇼킹하다. 가능하면 앞으로는 git diff 같은 것은 IDE를 사용하고, push commit 은 그냥 터미널을 이용해야겠다. 

로그가 이렇게나 개떡같이 구구절절하고 길 수도 있구나 하고 깨달았다. 간결하고, 정확한 정보를 전달해야 한다. ㅠㅠㅠ

명령어의 위치를 알고 싶다면 which를 사용할 수 있다. 

단점은 path에서 처음 발견된 which에 관한 위치만 나온다는 점이다. 

이를 보완하고 싶을 경우 -a 옵션을 주면 해당하는 모든 위치가 나온다. 

 whereis는  명령어의 실행파일위치, 소스위치, man 페이지파일의 위치를 찾아주는 명령어라고 한다. (출처: http://webdir.tistory.com/158)

-p 옵션은 parent 옵션.mkdir 을 할 때 실제로 존재하지 않는 디렉토리가 확인될 경우 생성해준다. 

-m 옵션은 보호 모드를 설정해서 디렉토리를 순차적으로 생성해준다. 

cut 명령어에서 

- d, --delimeter와 같아. 뒤에 나오는 캐릭터로 문자열을 배열 형태로 파싱한다. 

- 위의 예시에서 세미콜론 앞에 역슬래쉬가 붙어있는 이유는 파싱 기준이 세미콜론이라서. (명령어 종료로 인식)

- -f 는  cut -d의 결과로 나온 배열의 field를 의미. -f 3 하면 3번째 필드가, -f 3,4 하면 3번째, 4번째 필드가 출력된다. 

- 단, 이 필드의 순번은 0 이 아니라 1번부터 시작한다. 싱-기-

+덧붙임