2025년 4월 2일 수요일

어쩌다 마주친 그대 2 - xfce Desktop Session 초기화/복구 하기

 update를 하다가 잘못 되어서 xfce desktop session에서 X window 테두리 등이 사라져서 창을 옮기지도 못하고, xterm 또는 xfce-term 같은 것을 실행해도 키보드 입력 focus 받기가 작동하지 않아서 타이핑을 해도 입력이 안되고, 오직 마우스 오른쪽 버튼을 눌러서 [붙여넣기] 기능으로만 입력하는 것이 작동하는 상황에 빠졌다. 전체 화면 아랫 줄에 메뉴 등의 taskbar도 왜 그런지 모르게 사라지고, 바탕-화면에서 마우스 오른쪽 버튼 클릭으로만 root 메뉴를 띄울 수 있었다. 다른 프로그램을 동작 시켜도 아까 썼듯이 창의 위치를 조정할 방법이 없어서 미칠 지경이었다. 

[xfce session]을 시작할 때에 나오는 session-관리자에서 이전에 쓰던 session상태들의 목록이 나올 때에 [+|-] 버튼 중에서 [-]버튼을 눌러서 기존에 저장된 session을 모두 없앤다. 그 직후에 이번에는 [+]버튼을 눌러서 새 session을 시작한다. 새로 시작할 session 이름을 넣으라는 요구가 나온다. 이 때에 적당한 아무 이름이나 넣고 새 session을 시작하면, 망가진 session말고, 초기화된 새로운 session이 시작되면서 복구가 된다 ! 

살아났다!

-

-

 

2025년 4월 1일 화요일

어쩌다 마주친 그대 ice-wm theme hangul problem

 일부러 그런 것은 아니지만, ( openSuse Slowroll ) upgrade 과정 중에 나름 중요한 설정으로 보이는 부분에 버전 충돌 현상이 있었고, 역시나 잘 모르는 무식한 자였지만 나름대로 아는 척하고, 서로 충돌 나는 것은 지우는 방식으로 진행했더니, 망가져서 원래의 XFCE desktop 환경이 없어지고,  ice-wm 환경으로 바뀌어 버렸다. 메뉴에 아무런 한글 명칭을 한 항목들이 안 보여서 한글 글꼴 설정이 ice-wm 환경에서 뭔가 잘못되었을 것으로 나름대로 추측하고 나름대로 노력을 해봤지만, 역시 문외한이 이미 살짝 망가진 환경에서 어찌하여 더 망가뜨리게 될 지는 잘 알고 있다. 잘 모르는 방식으로 한글 설정(특히 한글 글꼴 설정)에 문제가 생긴 듯했지만, 어쩔 수 없다. 안 보이는 메뉴 항목들이 너무 많아서 어찌할 엄두를 못 내고 있던 차에 우연하게도 [시작? 버튼] > 을 눌러서 나오는 theme 설정 기능 중에서 한글이 표시되는 theme 설정이 존재한다는 것을 알게 되었다. 한글이 기본적으로 화면에 표시되도록 하는 theme 설정에는 아마도 menu에서  글꼴을 설정하는 항목이 있을 것으로 추측된다.


 ---

ice-wm 설정 파일들이 들어 있는 곳 목록을 만들었다.

~/.icewm/

 /etc/icewm/

/usr/share/icewm/

특히 마지막(세번째) 위치에서는 

/usr/share/icewm/themes/

위치에 현재 사용되는 theme 설정 파일들이 모인 directory 가 있었다. 이것들 중에서 한글 메뉴가 

나름 잘 보이는 것들은,

CrystalBlue/ ,  Infadel2/ 및 그 sub-theme  Ergonomic/  ,   Overloaded/ ,,, NanoBlue/

이것들 중에서도 종료 메시지 상자까지 한글 글자가 정상적으로 표시되는 것은 오직 NanoBlue/ 한가지 뿐이었다. 이 theme에 지정된 font 들을 알아봐야 겠다.

  ---

한글 메뉴 항목이 제대로 표시되지 않는 theme에는 놀랍게도 font 지정 항목이 없었다. 말 그대로 theme와 관계없는 default 글꼴이기 때문에 한글이 표시되지 않았을 것이라는 것인데, 이 default 글꼴은 무엇일지 궁금했다.  

_(  /etc/icewm/prefoverride  )_파일에

#  Name of the menu font.
# MenuFontName="-misc-dejavu sans-bold-r-normal--10-*-*-*-*-*-*-*"

라는 항목이 존재했다.

한글이 제대로 표시되지 않는 theme 의 하나인 Helix/ theme의 설정에는 이 항목이 지정되어 있는데,

MenuFontName="-b&h-lucida-medium-r-*-*-12-*-*-*-*-*-*-*"
라고 되어 있고, 한글 메뉴가 표시되지 않는다.

반면에 한글이 제대로 표시되는 theme 중에 하나인 NanoBlue/  theme 에 지정된 이 항목은

# Menu font
MenuFontName="-*-sans-medium-r-normal-*-*-90-*-*-p-*--*-*"
MenuFontNameXft="sans:size=9:medium"

라고 지정되어 있다.


그리고, dialog window와 관련된 글꼴 설정이 있는지 찾아보니, 그다지 딱 들어맞지는 않을 것으로 느껴지는

# Dialog Label font
LabelFontName="-*-sans-medium-r-normal-*-*-120-*-*-p-*--*-*"
LabelFontNameXft="sans:size=12:medium"

항목이 지정되어 있다. 이것이 확신이 들지는 않지만, 종료 대화상자(dialog box window)를 제대로 표시되게 하는 설정인 듯하다.
메뉴에는 한글이 제대로 표시되지만 종료 dialog에 한글 메시지가 제대로 표시되지 않는 theme 의 하나인 CrystalBlue/ 에는
글꼴 설정(일부분)이 아래와 같다.
.. (이전 생략)
#Fonts
TitleFontNameXft=                       "sans-serif:size=8"
StatusFontNameXft=                      "sans-serif:size=8:bold"
MenuFontNameXft=                        "sans-serif:size=8:bold"
NormalTaskBarFontNameXft=               "sans-serif:size=8:bold"
ActiveTaskBarFontNameXft=               "sans-serif:size=8:bold"
ListBoxFontNameXft=                     "sans-serif:size=8:bold"
ToolTipFontNameXft=                     "sans-serif:size=9:bold"
QuickSwitchFontNameXft=                 "sans-serif:size=10:bold"
ClockFontNameXft=                       "sans-serif:size=8:bold"
..(이하 생략)

역시 LabelFontName 을 지정하는 항목은 없다.
이 글을 올린 다음에 나중에 다시 알아봐야겠다.

-

-

 

 

2025년 2월 4일 화요일

Pied piper

pied 흰색과 검은색이 교차하는
pipe 피리  --er 부는 사람.
--
독일 hameln 지방의 전설/민화이고 그림형제의 동화집에 나오며 유명해졌다. 이런 이야기를 밑바탕에 깔면, ..
pied 는 (알록달록한 )_ 이라고 해도 될 듯하며
알록달록 피리쟁이(!) 쯤이 적당할 듯?
--
-

2024년 11월 30일 토요일

publish__netbsd도 다뤄보기

 netbsd 를 v..box에 설치해서 소박하게 돌려보는 중이다. 조금이라도 적은 공간을 차지하도록 요즈음 대세인 64bit가 아닌 32bit를 선택해서 하고 있고, 어차피 PC라서, i386, 이것은 요즈음 역시 대세라는 arm 환경은( 이것도 32bit/64bit 를 선택할 수 있고, 이것도 bit가 대세인 눈치이지만, 뱁새의 다리가 짧아) 아직은 ... 뱁새가 어찌어찌 얻은 samsung gal.tab-10에서 돌아가는 android/termux 를 보면 적어도 배터리 절약에 대해서 만큼은 엄청난 성능(? 안 돌아가고 쉬면서 배터리 수명 늘리는 것도 성능!이라면.(쉬는 능력?)...)을 경험하게 되었으니, 그래도 아직은 android/termux에나 만족하면서...

역시 gui를 사용하고, 인터넷 연결은 확실한 상태에서 web browser / 한글 / 영문 모두 잘 작동하면서 창을 이리저리 왔다갔다 하고 screen-shot/긁어-붙이기/등등이 자유로운  v...box를 쓰니 너무너무 편하다. 그냥 컴퓨터 한 대에 통째로 무작정 os를 설치하고 업그레이드하고 콘솔에서 씨름하고, network 연결 안되어서  헤매는 것보다 훨씬 편하다.

최근에 9에서 10으로 upgrade 했다.

참고한 정보는 아래에 있다.

https://www.netbsd.org/docs/guide/en/chap-upgrading.html

그런데, 업그레이드 할 때에 그냥 boot com 이라는 iso 를 받아서 한꺼번에 편하게 하려고 했으나, 막상 이것으로 부팅하여 설치하려고 하니, 그냥 iso 에 있는 것으로 하지 않고, 거의 다 ftp로 새로 받아서 하는 짓거리를 하더라. 그래서 그런지 매우 천천히 진행이 되었고, 문제는 이것으로 끝난 것이 아니라는 것. 아래의

그런데, pkgin repository 설정이 10 이 아닌 9 에 그대로 머물러 있었다.

 

억지로 9로 설정되어 있던 pkgin의 repository를 10으로 바꿔주고 _(  pkgin update )_를 하니, 한참 시간이 걸리더니 upgrade를 할 것이 거의 (1개정도만?) 없고, 최신인데, 그런데 ....

refresh 

라는 것을 거의 모든 설치 package에 다시 해야 한다고 하면서 하나 하나 download 다시하고 다시 설치하고 있는 꼴을 보니 (이것도 천천히 천천히... 아까 iso로 할 때에도 안된다면서 하나하나 다시 다운로드해서 하더니... ) 열 받는다. 원래 이렇게 돌아가는 것인가... 무슨 refresh가 upgrade를 새로 하게 하는 것인다... 

어쨌든 시간이 계속 흐르고 있다.


---

-

--


2024년 11월 25일 월요일

리눅스 최근 배포판 ( 2024년 현재 기준) root 로그인이 안된다 싶을 때??

최근의 리눅스 배포판 ( 예: gooroom(구름), hamonikr(하모니카), opensuse, ubuntu, linux_mint, ... )은  설치할 때에 일반 사용자의 id/password 는 설정/확인을 하지만, root 사용자를 설정하는 절차는 생략되는 추세인 듯하다. 뱁새처럼 기억력이 가물가물하는 사람은 예전에 root 사용자를 어떻게 설정했는지 가물가물하다. 나름 password manager를 사용해 보기도 하지만, 거의 결정적일 때에는 이것에 소홀히 하다가 개고생하기 일쑤이다. 반복적으로 1년에 한두번 정도씩은 의도했든 하지 않았든 이런 상황에 마주하게 된다. 이럴 때마다 뱁새의 미련함에 한탄하지만, 바꿔나가는 것이 쉽지 않은 상황이다.

최근에 하모니카의 업그레이드가 필요한 상황이 되었는데, 일반 사용자(나름 관리자도 일시적으로 될 수 있는 ( sudo사용까지는 되는... ) ) 상황이지만, _( su - )_ 명령에서 요구하는 관리자의 password 는 도저히 기억나지 않고 맞출 수 없는 상황을 겪었다. 나름 개인적인사정으로 몇 달을 컴퓨터에 접근하지 못하다가 다시 다루게 되었는데, 몇 달 전에 어떻게 설정해 놓았는지 까먹고, password manager에도 전혀 정보/hint가 들어있지 않았기에 더더욱 당황스러웠다. 몇날동안 고민하고 시도하고 헤매다가 어제 크게 결심하고 그냥 있는 os를 밀어버리고 다시 설치해 버렸다. 그런데, 이 과정에서 설치 프로그램이 root 사용자의 password 설정에 대해 묻지 않는다는 것을 알게 되었고, ( 기억이 가물가물하지만, 아마도 이전 version upgrade 할 때에도 비슷하지 않았을까, 그래서 당황하고 어떻게 할지 알아볼까 하다가 비상상황을 겪고 이렇게 되었던 듯한 가물가물한 기억이 있긴하지만, 확실하지 않다. ) 멀쩡했지만 root password를 몰라서 밀어버렸던 상황을 이제 새로 설치한 직후에도 바로 다시 겪어야 한다는 악몽같은 두려움에 싸였다. 

이것은 하모니카OS 만의 문제가 아니고, root password를 잊어 버려서 최든 몇 년 사이에 밀어 버릴 수 밖에 없었던 경험은 gooroom4.1 / opensuse / fedora / debian /  windos / freebsd / netbsd / dragonfly bsd 등등 헤아릴 수 없이 두루두루 많이 반복적으로 겪어서 매우 창피할 정도이다. 6개월에서 1-2년 정도만에 로그인해 보는 거의 모든 OS 의 상황에서 이런 일을 겪게 된다. 그것도 꼭 password manager에 등록하는 것을 소홀히 하게 된 직후, 갑자기 보안에 대한 염려가 생기고 새로운 형태의 password를 만들 아이디어가 떠오른 직후에 바꾸는 사고를 친 후, 빠르면 1시간, 오래 기억하면 2-3일 안에 그 기억을 잊어버리고, 헤매게 된다. 새로운 password 형태가 생각이 나면, 이제 또 뱁새가 사고를 칠 때가 되었나하는 느낌을 가지게 된다. --

 

그런데, 이번에는 분명히 새로 밀어버리고 설치하는데 일반 사용자 password만 저장했을 뿐, root 사용자는 설정 절차를 거치지 않은 것을 확실히 기억하고 있고, os를 밀어버리기 전의 기억이 있어서 이번에는 이렇게 _( su - )_ 명령을 해 보면 어떨까하고 해 봤다. 바로 아래처럼 하는 것이다.

_(      sudo su -   )_

이렇게 명령했더니 현재 사용자인 일반 사용자의 password를 묻고는 root 사용자로 바뀌어 있었다 !!

어쩌면 어제 그 멀쩡했던 OS에서도 똑같이 하면 되었을지도 모를 일이다. 이미 밀어버렸기 때문에 돌아가서 확인할 방법은 없지만 말이다.

...

---

-

-


2024년 5월 29일 수요일

Perl__PerlOldDoc 번역해보기?? 번역도 되는 것이었나?

encoding 을 지정할 수 있고, 사용된 것은 아래의 주소에 나오지만,

https://perldoc.perl.org/perlko

소스코드는 일본어 번역 작업이 참고된 듯 하고... ( 일본인들 부지런한 것은 그나마 인정.. )

https://gypark.pe.kr/wiki/Perl/POD#H_3

github에는 같은 이름이 3개의 다른 저장소에 있던데...

keedi (Mr./Ms./님)판...

         https://github.com/keedi/perldoc-kr

JEEN (Mr./Ms./님)판...

         https://github.com/JEEN/perldoc-kr

gypark (님) 판... 이것은 JEEN 님)판으로부터 fork해 온 것이라는 정보가 표시되어 있다, 그리고 aanoaa (님)이 _( PSGI::FAQ 번역중 집중력 저하 )_라는 (2024년 현재 기준으로 14년 전에 작성된) 작업 기록이 남겨져 있다. ( PSGI::FAQ 근처는 번역이 진행이 된 것일까? )

        https://github.com/gypark/perldoc-kr

        작업기록:         https://github.com/gypark/perldoc-kr/commits/master/

----

그나마 (아직은 죽지만은 않은 ... 과연 언제까지? / ) 살아있는 / 한국 사회...  

       https://cafe.naver.com/perlstudy


FastCGI 또는 PSGI 또는  WSGI사용법 in stack_overflow

https://stackoverflow.com/questions/53339936/should-i-migrate-from-cgifast-to-something-else-in-light-of-cgi-pms-deprecate

--

거기에서 나오는 여러 방법들... 검토도 같이 해 줘야 하지? 어렵고 귀찮아서 못 알아 먹겠네..

easy PSGI article ?

https://perlhacks.com/2016/01/easy-psgi/ 

--

https://metacpan.org/pod/CGI::PSGI

--

https://metacpan.org/pod/Plack::Handler::FCGI

--

언제나 그랬듯이 이번에도 맨 밑바닥 결론은 ..  엉망진창 !

2024년 4월 28일 일요일

draft__texi2html 기본 설정 파일 위치 .... Config 은 기본 설정 파일 이름인가/아니면 폴더의 이름인가

 --

-

GNU 'ed' 매뉴얼 (html)의 상황이 amazon회사의 kindle 에 넣기에 그냥은 불가능하다는 사실을 알게 되었고, 여러가지 삽질을 하다가 결국 실패했는데, w3c의 html 점검 기능을 써서 검사를 해 봤을 때에 

 _(    https://validator.w3.org/    )_  html 문서 자체에 심각한 이상이 있다는 것을 그제서야 알게 되었고, ( 일반적인 web browser 로는 읽기는 잘 되었으니 이런 문제가 있다는 것을 모르고 있었다. ) 


처음에는 ( 그러니까, html 검사를 하기 전에는 )  ed_manual.html 도움말 파일이 일반적인  html이 아니라, email의 multi-part 첨부파일의 형식인 꼼수였다는 것은 알고 있었으나, 대충 간단하게 손을 보면 고칠 수 있을 줄 예상했으나 틀려먹었고, 내가 계속해서 수정했던 html 마저도 이상한 문자코드가 들어 있어서 완전히 (치명적 오류)를 발생하는 것과 여러 수정 version 들 마저도 (치명적 오류)까지는 아니어도 각종 구형 문서의 경고들이 난무하는 것을 보고, 처음부터 source  texi 파일 단계에서부터 재변환을 시도하기로 방향이 바뀌었고, ...

 texi2html 을 선택해서 정보를 알아봤는데, 그 과정에서 '기본 설정 파일 위치'인 곳에 결국은 Config  내용에 설정을 저장할 수 있다는 애매모호한 도움말 언급을 보게 되었고, 이 Config 이 디렉토리를 뜻하는지, ..디렉토리 내부에 기본 설정이 들어간 script 파일을 뜻하는지 도움말만 읽고서는 헷갈려서, 소스코드 거의 전체를 뒤져보게 되었다. 찾아 헤매다가 .... 결국 

texi2html.pl  메인 소스코드 내용 중에서 Config 를 검색해서,   204번째 줄에서 아래의 내용이 나오는 것을 확인했고, 설정 perl source file 이름이라는 것을 다시 _( $conf_file_name )_을 찾아보고 확신하게 되었다.

my $conf_file_name = 'Config' ;

이것은 아래에 언급한  _(  texi2html.pl  )_ 파일의  3684부터 3688 번째 줄에 아래의 내용을 보고, 이것이 perl 소스 파일이라는 것도 알게 되었다.

foreach my $file (locate_init_file($conf_file_name, 1))

 

내가 이것을 조금 고쳐서 지금까지 한 것과 같은 의문을 갖고 찾아보기를 하느라 헤매지 않으려면, 이 소스 코드에서 

my $conf_file_name = 'ConfigFile' ;

이라고, 뒤에 ...File 이라는 것을 덧붙이도록 고치고 싶다. 물론 내가 배포를 할 것이 아니기 때문에 그냥 알아서 적응할 것이다.

시간은 이렇게 지나가고 있다.

-

-