bash 쉘을 gui로 구현하면 어떨까요?

작은 것이 아름답다!
하지만 불편하죠

아래 loscane의 글에서 본 scratch에서 문득 든 생각인데
bash가 작은 명령들의 조합으로 만들어지는 거니까
그걸 scratch 같은 레고 조립형태로 만들면 어떨까 하는 생각이 들었습니다

구글에서도 안드로이드 앱을 만들때 거의 비슷한 도구를 내 놓았다가
별로 인기가 없자 사라졌었죠

배쉬는 어떻게 될지 모르겠지만 그렇게 복잡한 스크립트를 만들게 아니라면
초보자를 위해서도 텍스트만 입력하는 방법보단 낫지 않을까 생각합니다

이제 개발툴도 화면 gui 요소는 디자인 도구를 사용하고 이벤트만 코드로
연결하는 추세이니 배쉬도 해볼만 할 것 같습니다
한참 전부터 대세는 gui+위저드 기능이니까요

글쎄요 저는 프로그램머 전력이 있어서 그런지 몰라도 쉘스크립트의 경우는 현재 같은 방식이 좋다고 봅니다.
GUI를 지향하는 MS에서도 최신의 쉘인 파워셀도 결국 텍스트 형식이죠.
사실 저는 그것도 맘에 안 듭니다. 자연어 방식으로 자꾸 가려고 하지만 껄끄럽죠.

미국인과 친하거나 미국인을 이해하려면, 한국어 보다는 영어를 사용하거나, 서양문화를 이해하는 것이 훨씬 원론적이고
훨씬 효과적인 것과 같다고 생각합니다.
컴퓨터 자체가 생물학적, 생체공학적으로 발전하지 않는 한,
보다 뛰어난 인간이 컴퓨터에 맞춰야 한다고 봅니다.
인간이 컴퓨터 보다 뛰어난 이상, 컴퓨터가 인간에게 맞추는 것이, 인간이 컴퓨터에 맞추는 것보다는 어렵지요.

사실 저는 단적으로 말할 수 있습니다
프로그램 언어를 배우는 것이 인간의 언어를 배우는 것보다는 쉽다 아니, 그냥 껌이다라고 말할 수 있습니다.
왜냐면, 컴퓨터의 인공지능 수준은 겨우 파리수준이고, 인간이 그것의 비위를 맞추는 것 또한 껌이다 라고요.

인간처럼 고등동물 고차원적 생물의 수천만년의 누적된 지식도 배우는 데, 그깟 몇 백년의 지식과 지능 떨어지는 컴퓨터에 비하겠습니까?
낯설고 경험이 부족해서, 관심이 없거나 적성에 안 맞아서 그럴 뿐 컴퓨터에 익숙해지는 것은 인간을 배우는 것에 비해면 우주안의 먼지 만큼의 노력이면 충분하리라 생각됩니다.

unix방식의 기존 체계를 바꾸는게 더 저변확대에 도움이 될듯하네요. unix자체가 너무 싫은 한사람으로서…물론 자유소프트웨어는 좋지만요…

사용해보시면 아시겠지만. 코딩 방식을 블럭 드래그로 바꾼것뿐입니다.
제대로 사용하기 위해선 규칙과 문법, 작동되는 시스템에 대한 이해가 필요로 합니다.
결과를 놓고 보면, GUI 블럭 드래그 방식보다는 텍스트로 입력하는 편이 더 빠르고 쉽습니다.
주관적인 느낌으론, GUI 보다 텍스트가 더 이해하기 편했습니다. GUI 드래그 방식은 상하좌우, 블럭숨김 내부 등 코드가 어디에 위치하는지 찾기 어려웠으나, 텍스트는 위 아래로 코드가 나열되어 있어서 어디에 코드가 위치할지 직관적으로 파악하기 쉬웠습니다.

[quote="february28":qbfkijte]unix방식의 기존 체계를 바꾸는게 더 저변확대에 도움이 될듯하네요. unix자체가 너무 싫은 한사람으로서…물론 자유소프트웨어는 좋지만요…[/quote:qbfkijte]

먼저 한가지를 생각해보세요.

화단을 정리할 때에는 모종삽 정도면 충분한데… 포크레인을 쓸 필요가 없죠.
유닉스 계열은 최소한의 필수적인 기능들을 가진 모듈들을 시스템 혹은 사용자가 적절히 조합하여 필요한 기능을 만들어 내는
효율성을 중요시 합니다.
GUI방식은 각각의 프로그램간의 소통이 원활하지 못할 뿐 아니라, 인터페이스를 각기 따로 만들게 되며…
종국에는 같은 기능을 가지는 작은 프로그램으로 시작하여, 사용자 인터페이스에 신경쓰고, 추가 기능들을 덧붙히다가
덩치가 커질데로 커져서, 원론적으로는 같은 기능을 하지만, 다른 프로그램들이 천차만별로 존재하게 됩니다.
윈도우즈에서는 그런 프로그램들을 팔지요.
또한, 그런 프로그램들에 익숙해지다 보면, 종속적이 됩니다.
왜냐면 통합적인 프로그램이 되니까 한개의 프로그램으로 왠만한 걸 다하려고 합니다.
그러나, 현실적으로 완벽하게 맘에 드는 프로그램은 존재할 수 없고,
그러한 관계로 유사한 프로그램들을 많이 설치하고 사용하게 되고, 어쩌다보면 한가지 기능이 아쉬워
설치는 해두었으나, 거의 사용하지 않는 프로그램들도 많이 존재하게 됩니다.

기억을 되돌려 보시면, 그런 프로그램들이 아주 많고, 공간을 많이 차지한다는 것을 알 수 있을 것입니다.

GUI 그래픽 유저인터페이스는 인간에게 컴퓨터가 맞춰가는 것이나, 덜 떨어진 컴퓨터와 결코 다른 인간을 완벽히 이해할 수 없는
인간이 만든 것이기에… 완벽히 만족할 수 없습니다. 결코 불가능한 일이며,
쉽게 가고자 해도, 언제나 불만은 존재하게 됩니다.
하지만, 덜떨어진 컴퓨터에 인간이 맞춰가면, 인간 스스로, 인간이 아닌 컴퓨터 임을 감안하고,
컴퓨터를 이해하고, 그것의 관점에서 조합하고, 자신에게 맞는 것을 선택하거나, 만들게 됩니다.

물론 컴퓨터의 인공지능이 아주 발달한다면 달라지겠지만, 지금으로선 그렇다고 봅니다.

개발자들은 물론, 덜떨어진 컴퓨터를 더 진화시켜, 인간에 근접하게 만들려고 노력하겠지만,
현실적으로 아주 먼 이야기 죠.
현실적으로 차가 사람에 맞추기 보다, 차에 따라 인간이 맞춰가는 것이 일반적인 것과 같은 이치라 봅니다.

어떻게 보면 익숙함의 차이일 수 도 있습니다.

십수년 전 윈도우즈를 사용하기 이전 도스시절 사람들은 도스방식이 당연하다는 듯 생각했었지요.
그리고, MS-DOS가 시장을 장악하고, 이후 윈도우즈 3.0을 발표할 당시 반응은 새롭다는 느낌은 있었으나,
그게 익숙지 않았고, 점차 흐름이 바뀌어 윈도우즈3.1시절에는 도스와 윈도우즈가 비슷한 비율로 사용되었다가,
윈도우즈 95,98등이 나오면서 많은 사람들이 GUI에 익숙하게 되었습니다.

시대를 앞서간 스티브 잡스가 넥스트스텝을 선보인것은 윈도우즈 보다 이전이었으며,
엑스윈도도 훨씬 전에 나왔습니다.

여기 유저분들께 감히 한가지가 물어보고 싶은 것은,
게임, 인터넷 뱅킹등의 일부 특별한 경우를 제외하고, 리눅스가 편하냐, 윈도즈가 편하냐 하고 물어보고 싶습니다.
또 무엇때문에 리눅스를 사용하는가 하구요.

저는 딱 잘라, 리눅스가 편합니다.
윈도우즈가 패셔너블한 새옷이라면, 리눅스는 착용감이 좋은 편안하고 늘 입던 헌옷같습니다.
한번 맛들이면 계속 사용하게 되고, 윈도우즈로 돌아가기 힘들죠.

담배를 끊기 힘들 듯, 베인 습관이나 익숙함을 벗어던지고, 새로움에 빠지기란 쉽지 않은 일이죠.
리눅스가 윈도우즈 보다 훌륭하고 좋은 운영체제라고 말할 수는 없을 지 몰라도,
적어도 그만큼 훌륭하고 가치가 있으며, 익숙해지면 그만큼 편리한 운영체제도 현재 없다고 봅니다.

배쉬가 불편한건지 문자 기반의 환경이 불편한 건지 구별 해야 합니다.

터미널(문자 기반) 환경은 GUI에 비하여 불편하지 않습니다. 불편하지 않다기 보다는 서로 장단점이 있습니다. 섞어서 상황에 맞춰 쓰는 게 좋습니다.

터미널 환경에서 기본 쉘로써 배쉬가 불편한가? 저는 불편 하다고 생각 합니다.

기본 설정이 별로 초보자에게 친절하지가 않습니다. 매뉴얼 뒤져 보니까 추가적으로 설정할 수 있는 굉장히 생산적인 기능 들이 많더군요. 문제는 이런 설정 작업이 초보자에게 녹록치 않다는 겁니다.

그래서 얼마 전까진 zsh(oh-my-zsh)을 사용해 보다가 요새는 fish라는 쉘을 씁니다.

fish는 좋은 점이 설치하고 바로 쓰면 bash 쓸 적에 이것 저것 설정 파일에 설정해 놨던게 대부분 기본 설정 입니다. 손이 덜 가죠. 배쉬 설정 파일 백업 했다 복구 하는 작업? 어려운 건 아닙니다. 하지만 초보자에겐 어렵죠. 저는 언제나 그래왔듯이 초보자라 그냥 기본 설정이 더 친철한 fish가 낫더군요.

배쉬가 불편하신 분은 zsh이나 fish 같은 새로운 시도도 있으니 한 번 살펴 보세요.

GUI환경으로 배쉬에서 하던 일을 해보자는 문제는 사실 배쉬와는 상관 없습니다. 배쉬는 그대로 두고 새로 어떤 툴이나 프로그래밍 환경을 만들면 됩니다. 스크린샷으로 보여주신 것과 같은 GUI 환경에서 하는 프로그래밍은 아주 오래전 부터 시도되어 왔고 지금도 시도되고 있습니다.

문자 기반 환경에서 기본의 bash로 대표되는 쉘의 패러다임을 뛰어 넘는 새로운 쉘이 나오는 것은 환영 할 일입니다. 하지만 단순히 문자 기반이어서 불편 하니 GUI로 해보자는 생각은 틀렸습니다. 둘이 서로 상충되는 환경이 아니거든요.

운영체제나 셸이나 각자 나름의 프로그램의 체계일 뿐이지 수학같은 진리가 아닙니다.
또한, 보다 효율적인 방식이 있더라 하더라도, 전문가들이 아닌 일반인들에게 그게꼭 적합하고 최선인것은 아니죠.
gui같은 사용목적은 보다 일반인들에게 친숙하고 편리한 수단을 제공하기위한것이고, 그런 목적이라고 한다면, 평소에 호불호에 불호였던
unix스타일의 시스템 체계나 코딩 체계에 있어서 그것을 좀 개선또는 개혁하는것 또한 보다 일반 친화적인 목적에 부합되는 면이 있기때문에 unix방식의 변경이라는 주장을 했던거죠…

이런 구이 형태의 구현은 별로라고 생각들 하시는군요
차라리 지금 상태에서 스크립트 에디터시 신텍스 하이라이팅은 대부분 지원하니까 명령과 옵션의 문맥 자동완성이 지원되는 형태가 필요한가요?
현재 배쉬는 너무 구닥다리 아닌가 싶습니다
이름도 70년대 본쉘을 다시 사용하자니까요

그건 그렇고 마잇님이 소개한 fish 튜토리얼 보고 있는데 정말 기막히는 쉘이네요
원하던 쉘이 바로 이것 같습니다 :shock:
이름도 참 멋지게 지었네요 쉘 피쉬 - 사회과학 용어로는 합리적인으로 해석되는 - 이기적인 기능이 너무 멋집니다
따로 설정도 필요없고 설치되는 패키지도 그렇고 왜 여태 이걸 몰랐을까요 ㅠㅠ

[quote="oseb":1w2zeocq]
배쉬는 어떻게 될지 모르겠지만 그렇게 복잡한 스크립트를 만들게 아니라면
초보자를 위해서도 텍스트만 입력하는 방법보단 낫지 않을까 생각합니다
[/quote:1w2zeocq]

제가 올린 글타레에 반응해주시고 새로운 아이디어 까지 던져주신 oseb님께 감사드립니다.

oseb님의 아이디어도, 제가 올린 글타레도 모두 '유저의 언어적 이해 괴리 현상’이라는 문제 에서 출발합니다. 컴퓨터는 지극히 '글’로 이루어지고 통제되는 반면 대부분의 사용자는 글을 전혀 읽을 줄 모르는 '까막눈’이기 때문입니다. 영국 교육계가 장기간의 고민 끝에 공교육 과정에서 프로그래밍을 가르치겠다는 결정 저변에는 국민 모두를 '문맹’에서 부터 벗어나게 하겠다는 인식이 자리 잡혀 있습니다.

페이스북에 스크래치 링크를 걸어주신 공정배 회원님 역시 '교유적 목적’으로 제안을 해주셨습니다. 이는 언어에 전혀 관심 없는 유저들에게 어떻게 언어에 대한 중요성을 일깨워주고 보다 언어와 가까워 질 수 있게 하느냐 일 것입니다.

일반 유저들에게 이 '언어’와 가까워 질 수 있도록 접근성을 높이기 위한 고민을 하는 것은 우리 모두에게 필요하다고 봅니다. 우리에게 익숙해져 있는 GUI 환경 속에서도 꾸준히 언어를 익히고 학습 할 수 있기 위한 아이디어들이 필요합니다.

저 역시 그러한 고민들이 내어놓은 결과물을 통해 GUI에서 CLI로 다시 넘어올 수 있었습니다. 많은 분들께서 유니티를 불편해 하시는 반면 저는 ‘키보드로도 조작하기 좋게 접근성을 높인’ 유니티 환경을 통해 키보드와 익숙해지고 이러한 과정으로 CLI로 들어오게 되었습니다.(이와 관련해서 이전에 제가 써놓은 글타레가 있어 참고삼아 걸어보겠습니다. [url:1w2zeocq]http://ubuntu.or.kr/viewtopic.php?p=105852[/url:1w2zeocq])

여러 회원님들이 지적하셨듯이 GUI틀을 통해 CLI를 조작하게 될 경우 CLI의 자유도가 GUI의 틀을 벗어나지 못하게 되는 한계에 부딧히게 됩니다. 또한 기존의 Bash와 같은 오래된 CLI보다 더 사용자 중심적인 틀로 다듬는 것도 중요하다고 봅니다. 허나 아무리 쉽게 글을 써놓더라도 사용자가 '문맹’이면 글 자체를 읽으려 하지 않습니다. CLI기반의 접근성을 높이더라도 사용자는 습관에 의해 CLI 자체에 접근을 하려 하지 않는 것입니다.

그래서 저는 oseb회원님의 말씀처럼 GUI기반의 코딩이 진행되면서도 CLI 화면 안에서 진행되게 하는 것이 좋지 않을까 생각합니다. 과거 몇몇 웹 에디터들 처럼 단추를 통해 기능들을 반영할 때 수정되는 코드들을 바로 화면 안에 노출 시키는 것입니다. GUI에 익숙한 사용자들은 처음에는 단추들을 클릭해가며 코딩을 하겠지만, 점점 코딩이 깊어질 수록 직접 소스 코드를 조금씩 수정해야 해야 할 상황들이 생길테고 그렇게 소스코드들을 만지다 보면 어느덧 GUI라는 목발을 짚어던지고 CLI라는 바다 속에 뛰어들어 첨벙 첨벙 수영하는 기쁨을 누리게 될 테니까요.

oseb님이 말씀하신건, 제가 제대로 이해한게 맞다면, 이미 애플에서 Automator라는 GUI 프로그램이 있습니다.

프로그래밍을 전혀 할 줄 모르는 사람이, 드래그&드랍으로 몇가지만 순서 짜맞추듯 넣으면 알아서 자동화시켜주는 툴인데 아주 널리 쓰이는 것으로 알고있습니다.

애플 오토메이터 유튜브 영상을 하나 봤습니다

오… 생각한거랑 많이 비슷하게 동작하네요
변수도 드래그해서 넣고 말입니다

화면 디자인이 순서도 같은 형태가 아니라서 그렇긴 하지만 작동 방식의 같은 거였네요
애플에 이미 이런게 있었군요 멋집니다