Terminal: 기능 요청: Sixel 그래픽 지원

Sixel을 구현하는 동안 투명도가 포함된 이미지로 테스트하는 것이 중요합니다.
투명도는 다른 색상의 픽셀을 그려서 얻을 수 있지만 Sixel 색상의 일부 픽셀은 그리지 않고 배경색은 그대로 둡니다.
이것이 직사각형이 아닌 Sixels를 적절하게 그리는 유일한 방법이며 새로운 Windows 터미널의 배경 아크릴 투명도와 함께 특히 좋을 것입니다.

예를 들어 Ubuntu와 함께 WSL을 사용하여 테스트하면 mlterm에서 이러한 이미지가 투명 마스크가 있는 것으로 적절하게 렌더링되고 배경색이 유지되는 반면 xterm -ti vt340에서는 배경이 흰색인 경우에도 손대지 않은 픽셀이 검은색으로 그려집니다. 터미널 창으로 블리팅하기 전에 투명 마스크나 알파 없이 검은색으로 초기화된 메모리 비트맵에서 식셀을 렌더링한다는 의미입니다.

오오. Sixel은 매우 멋진 제품입니다.

나는 그것이 필요하다고 결정했습니다. 필요.

기쁜 마음으로 PR을 리뷰하겠습니다 :)

이 요청을 언급한 Build 2019 인터뷰를 오늘 포착했습니다. 나는 여전히 Sixel의 Xorg가 잘못된 것이라고 주장합니다. 그래서 _매우 잘못되었습니다_.

ffmpeg-sixel "Steve Ballmer Sells CS50" 데모 는 결코 질리지 않습니다. 비디오에 소리가 없는 것이 약간 실망스럽습니다(소리가 비디오 를 실제로 만듭니다). 콘솔에는 이미 사운드가 있습니다. 그들은 완전히 삐 소리를냅니다. 선례 세트. 우리가 정말로 _필요한_ 것은 프레임과 인터리브된 작품 클립에 대한 새로운 CSI 시퀀스 입니다, 아미라이트?

Ken, Sixels를 언급할 자격이 있습니다. ;)

보낸 사람:realkenc [email protected]
보낸 날짜: 2019년 5월 8일 수요일 오후 4:31:31
받는 사람: 마이크로소프트/터미널
참조: 구독
제목: Re: [microsoft/Terminal] Sixel 그래픽 지원(#448)

빌드 2019 캡처 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmybuild.techcommunity.microsoft.com%2Fhome%23top-anchor&data=01%7C01%7Cduhowett%40microsoft.com %7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=i8rfPCaN%2FxqdF%2F4qRtdN2Py 인터뷰를 언급했습니다. 나는 여전히 Sixel 의 Xorg가 잘못된 것이라고 주장합니다.

ffmpeg-sixel https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaitoha%2FFFmpeg-SIXEL&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374 %7C1&sdata=G%2F9mvw1EdADkwChSbHZ%2FI54k9xvXagV%2FxD9VbJtyw7g%3D&reserved=0 "Steve Ballmer Sells CS50" 데모 https ://nam06.safelinks.protection.outlook.3A.url=.com/?url=https% 스럽 습니다. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FANSI_escape_code%23CSI_sequences&data=01%7C01%7Cduhowett% 입니다. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOpus_ (audio_format) 데이터 = 01퍼센트 7C01 % 7Cduhowett % 40microsoft.com % 7C81f48be19f374665cd3408d6d40d4dc6 % 7C72f988bf86f141af91ab2d7cd011db47 % 7C1 및 SDATA = XOq6Acz4 % 2B7gQeTKQBQ2fYJPnoLvx6vUjmLRhgOX1eDo % 3D 및 예약 = 0 프레임, amirite 인터리빙 클립?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F448%23issuecomment-490688164&data=01 에서 확인하세요. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub한다. COM % 2Fnotifications % 2Funsubscribe-% 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ 인증 및 데이터 = 01퍼센트 7C01 % 7Cduhowett % 40microsoft.com % 7C81f48be19f374665cd3408d6d40d4dc6 % 7C72f988bf86f141af91ab2d7cd011db47 % 7C1 및 SDATA = % 2F4pMmm7bvPa % 2BbFmE1gyN8 % 2BoTZDKJyRksBrkJpDh % 2BLug % 및 3D = 0 예약 .

관련: #120

필요.

LOL 저는 스트림을 보고 있었고 나는 속으로 생각했습니다. "여기 내 상사가 스튜디오 청중 앞에서 라이브로 나에게 작업을 할당했습니다."

v1.0의 우선 순위를 지정하십시오!

3D 애니메이션은 v1.5일 수 있습니다 😛

어머나

이 요청에 찬성표를 던진다면 Sixels는 터미널에 있는 놀라운 기능이 될 것입니다.

이번 주말에 MIT 라이선스 Java 기반 TUI 라이브러리 에 대한 Sixel 읽기 지원 구현을 완료했으며 놀라울 정도로 간단했습니다. Sixel 데이터 문자열을 비트맵 이미지로 변환하는 코드는 여기 에 있으며 Sixel 클래스에 대한 클라이언트 코드는 여기 에 있습니다.

디코더에서 성능을 위해 거의 수행하지 않았습니다. 그러나 Swing 백엔드를 사용할 때 여기 에서 볼 수 있듯이 성능은 여전히 ​​양호합니다. (비잔즈가 데모 gif를 만드는 데 좋지 않은 팔레트를 사용했기 때문에 뱀 이미지가 좋지 않게 보입니다.) 나는 그것이 얼마나 빨리 합쳐지는지 약간 놀랐습니다. "6셀을 비트맵으로 디코딩" 부분은 쉬운 비트이고, 하드 비트는 "이미지 데이터를 텍스트 셀에 붙이고, 그것이 있을 때 문자가 아닌 화면에 이미지를 블리트"한다고 말하는 것이 매우 공정합니다.

Sixel에 대한 터미널 지원에 관심이 있고 도움이 되기를 바라는 다른 사람들에게 언급하고 싶습니다.

다른 누군가가 Jupyter 노트북 클라이언트를 작성한다면 나는 찬성표를 던질 것입니다 ;)

우리는 이미 C(자바의 경우)로 작성된 민티에서 Sixel 지원의 예를 가지고 있습니다. 필요한 것은 C++에 대한 리팩터링뿐입니다(최소한 초기 지원의 경우). 여전히 다른 프로젝트에서 어떻게 구현되었는지 보는 것이 좋습니다.

우리는 이미 C(자바의 경우)로 작성된 민티에서 Sixel 지원의 예를 가지고 있습니다. 필요한 것은 C++에 대한 리팩터링뿐입니다(최소한 초기 지원의 경우). 여전히 다른 프로젝트에서 어떻게 구현되었는지 보는 것이 좋습니다.

민티 라이선스(GPLv3 이상)에 문제가 있습니까?

https://github.com/mintty/mintty/blob/master/LICENSE

https://github.com/mintty/mintty/blob/master/LICENSE

해당 링크에서:

Sixel 코드(sixel.c)는 GPL에 따라 mintty와 같이 라이선스가 다시 부여됩니다.
저자의 허가(kmiya@culti)

정확한 코드를 C++로 음역하는 경우 파생 작업은 해당 조건에 따라 GPLv3 이상 라이선스가 필요하거나 전혀 배포되지 않아야 합니다. (또한 kmiya @culti 에게 다른 라이선스로 Sixel.c를 제공할 의향이 있는지, 또는 한때 다른 라이선스로 제공되었던 적이 있다면 해당 소스에서 사본을 찾을 수 있는지 물어볼 수도 있습니다.)

Windows 터미널에 포함하는 것이 허용되는지 여부를 모르겠습니다. Windows 터미널을 간단히 살펴보면 MIT 라이센스가 있다고 나와 있으므로 mintty의 GPLv3+ Sixel.c의 직계 자손을 사용하여 링크/로드하는 방법에 따라 다음이 발생할 수 있습니다. 라이센스 문제에.

어쨌든 여기에서 다른 사람의 프로젝트를 방해해서 죄송합니다. 이제 동굴로 돌아가십시오...

Windows/Linux용 C/C++로 작성된 Sixel 가능하고 겸손한 터미널 에뮬레이터 위젯이 있으며 사용할 수 있는 SixelRenderer 클래스가 있으며(약간의 최적화가 필요하지만) BSD-3 라이선스가 있습니다. 틀림없이 가장 큰 단점은 특정 C++ 프레임워크용으로 작성되었다는 것입니다. 그래도 IMO SixelRenderer의 코드는 약간의 노력으로 번역할 수 있습니다. (저는 이 글의 저자이기 때문에 이것을 압니다. :) )

https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

Sixel을 구현하는 동안 투명도가 포함된 이미지로 테스트하는 것이 중요합니다.
투명도는 다른 색상의 픽셀을 그려서 얻을 수 있지만 Sixel 색상의 일부 픽셀은 그리지 않고 배경색은 그대로 둡니다.
이것이 직사각형이 아닌 Sixels를 적절하게 그리는 유일한 방법이며 새로운 Windows 터미널의 배경 아크릴 투명도와 함께 특히 좋을 것입니다.

예를 들어 Ubuntu와 함께 WSL을 사용하여 테스트하면 mlterm에서 이러한 이미지가 투명 마스크가 있는 것으로 적절하게 렌더링되고 배경색이 유지되는 반면 xterm -ti vt340에서는 배경이 흰색인 경우에도 손대지 않은 픽셀이 검은색으로 그려집니다. 터미널 창으로 블리팅하기 전에 투명 마스크나 알파 없이 검은색으로 초기화된 메모리 비트맵에서 식셀을 렌더링한다는 의미입니다.

흠. 내가 앞에 있는 VT340은 DCS P1의 P2 매개변수를 존중합니다. P2 ; P3 ; q SIXEL 시퀀스를 시작하는 시퀀스. 반면 Xterm은 이를 무시하는 것 같습니다. 그러나 래스터 속성 시퀀스( " Pan ; Pad ; Ph ; Pv )를 사용하고 높이와 너비를 지정하면 배경이 지워져 검은색 픽셀이 표시됩니다.

나는 ttwin 에뮬레이터의 무료 평가판을 얻고 그것이 VT340 및 VT340으로 작동하는 Xterm과 어떻게 다른지 확인하려고 생각했습니다.

하지만... 일반적으로 SIXEL을 지원한다는 아이디어에 대해 +1, 호환성 테스트를 제안하는 아이디어에 대해 +10입니다.

iTerm2 인라인 이미지 프로토콜 에 대한 지원을 추가할 수 있습니다.

두 시스템 모두에서 내가 가지고 있는 한 가지 의문점은 정렬은 어떻게 됩니까? 이미지 너비 또는 높이가 너비 또는 높이의 배수인 경우 모든 것이 정상이지만 그렇지 않은 경우 패딩을 오른쪽 아래에만 추가해야 합니까, 아니면 이미지를 모든 면에 패딩을 추가하여 가운데에 추가해야 합니까?

여기 연구에 대한 몇 가지 관련 링크가 있습니다.

• terminal-wg의 " 좋은 이미지 프로토콜을 위한 기본 사항" (및 링크된 이전 토론 )
• Sixel 지원에 대한 이 방대한 스레드

iTerm2 인라인 이미지 프로토콜 에 대한 지원을 추가할 수 있습니다.

그것은 아마도 다른 작업일 것입니다. Sixel 및 ReGIS는 명시적으로 대역 내 그래픽 또는 문자 데이터용입니다. 나는 그것이 나쁜 생각이라고 말하는 것이 아니라 단지 다른 기능으로 취급되어야 한다고 말하는 것입니다.

두 시스템 모두에서 내가 가지고 있는 한 가지 의문점은 정렬은 어떻게 됩니까? 이미지 너비 또는 높이가 너비 또는 높이의 배수인 경우 모든 것이 정상이지만 그렇지 않은 경우 패딩을 오른쪽 아래에만 추가해야 합니까, 아니면 이미지를 모든 면에 패딩을 추가하여 가운데에 추가해야 합니까?

Sixel 및 ReGIS 그래픽 데이터의 정렬은 다양한 매뉴얼에 (잘못) 설명되어 있습니다. Sixel 이미지는 문자 셀 경계에 정렬됩니다. 이미지 주위에 검은색 테두리를 원하면 해당 검은색 픽셀을 직접 추가해야 합니다. HTML의 여백이나 패딩과 같은 개념은 없습니다. Sixel 데이터의 각 라인은 6픽셀 높이의 스트라이프를 나타냅니다. 터미널 에뮬레이터에서 Sixel 이미지 데이터를 텍스트 문자와 정렬하려는 경우, Sixel 데이터를 생성하는 소프트웨어가 각 문자 글리프의 높이를 몇 픽셀인지 알지 못할 수 있으므로 답답할 수 있습니다. 구식 xterm이 있으면 vt340 모드에서 시작하고 다른 글꼴 크기를 지정한 다음(다른 문자 셀 크기를 제공하기 위해) 이미지 데이터를 텍스트와 정렬하려고 시도하는 일부 Sixel 데이터를 인쇄하여 이를 볼 수 있습니다. 데이터. (여기에 내가 글꼴 서버에 96DPI를 사용하도록 지시하고 15포인트 글꼴을 지정할 때 올바르게 보이는 간단한 테스트 파일이 있습니다. 글꼴 크기를 수정하면 이미지가 점점 더 텍스트와 정렬되지 않게 됩니다. https://gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

원래 vt340에는 이 문제가 없었습니다. (물론) 터미널을 켤 때 글꼴 크기를 지정하지 않았기 때문입니다.

그 이미지에서 볼 수 있는 또 다른 것은 Sixel 문서에 잘 설명되어 있지 않지만 Sixel 데이터 행을 인쇄하면 이미지 데이터에 대한 "가상 왼쪽 여백"이 설정된다는 것입니다. '$' 또는 '-' 문자를 사용하여 CR 또는 CRLF와 같은 도덕적 기능을 수행하면 터미널 왼쪽의 실제 왼쪽 여백이 아니라 이 가상 왼쪽 여백을 기준으로 다음 줄이 인쇄됩니다.

도움이 되었기를 바랍니다.

마지막으로 다시 스크롤하여 이것을 읽으십시오. 답변이 늦어 죄송합니다.

예를 들어 Ubuntu와 함께 WSL을 사용하여 테스트하면 mlterm에서 이러한 이미지가 투명 마스크가 있는 것으로 적절하게 렌더링되고 배경색이 유지되는 반면 xterm -ti vt340에서는 배경이 흰색인 경우에도 손대지 않은 픽셀이 검은색으로 그려집니다. 터미널 창으로 블리팅하기 전에 투명 마스크나 알파 없이 검은색으로 초기화된 메모리 비트맵에서 식셀을 렌더링한다는 의미입니다.

xterm에서 투명성을 지원하는 것은 너무 어렵지 않아야 합니다. 다른 이유로 코드를 파헤쳤습니다. 어딘가에 누군가가 Xterm의 동작에 의존하고 있기 때문에 호환성 플래그 뒤에 두는 것이 좋습니다. 이 플래그도 간단해야 합니다. 그러나 기본값에 대한 질문이 있습니다. 기본값은 무엇이어야 합니까? 검은색 또는 투명합니다.

원래의 VT240, 241, 330 및 340이 무엇을 했는지 알고 있습니까? 실제 VT의 경험을 충실하게 표현해 보도록 제안할 수 있습니까?기본 동작으로? 반전된 공백 문자를 인쇄한 다음 그 위에 Sixel 그래픽을 레이어링하고 지정되지 않은 픽셀이 렌더링되는 색상을 확인하여 이를 테스트할 수 있습니다.

VT340을 에뮬레이트하는 Xterm과 같이 동작하는 기능이 있는 한 msft 터미널의 기본값이 무엇인지에 대해 너무 많은 관심을 갖고 있는지 모르겠습니다. 터미널 종류에서 ssh를 통해 로그라인을 수행하기 위해 작성한 코드는 위에서 설명한 "지정되지 않은 픽셀이 검은색" 동작을 가정합니다. 이렇게 변경하면 코드를 다시 작성해야 합니다.

터미널 에뮬레이터에서 Sixel 이미지 데이터를 텍스트 문자와 정렬하려는 경우, Sixel 데이터를 생성하는 소프트웨어가 각 문자 글리프의 높이를 몇 픽셀인지 알지 못할 수 있으므로 답답할 수 있습니다.

원래 vt340에는 이 문제가 없었습니다. (물론) 터미널을 켤 때 글꼴 크기를 지정하지 않았기 때문입니다.

터미널 에뮬레이터가 원래 DEC 터미널의 동작과 정확히 일치하도록 이미지 크기를 조정할 수 없는 이유가 있습니까? 따라서 VT340의 줄 높이가 20픽셀이면 높이가 200픽셀인 이미지는 글꼴 크기에 관계없이 정확히 10줄을 포함해야 합니다. 그것이 터미널 에뮬레이터의 요점인 레거시 소프트웨어와 합리적으로 호환될 수 있는 유일한 방법인 것 같습니다.

더 높은 해상도로 이미지를 렌더링하기 위해 해당 동작을 확장하려는 것을 이해할 수 있지만, 이는 선택적인 확장이어야 합니다(또는 기존 독점 형식 중 하나를 사용). 따라서 이상적으로는 Sixel의 기본값이 실제 DEC 터미널에서 얻을 수 있는 것과 최대한 비슷하기를 바랍니다.

여기 연구에 대한 몇 가지 관련 링크가 있습니다.
terminal-wg의 "좋은 이미지 프로토콜을 위한 기본 사항"

Sixel은 병렬 창이 있는 tmux에서 지원할 수 없기 때문에 손상되었습니다.

약간의 작업(실제로는 많은 작업 )이 필요했지만, Sixel을 사용하면 이미지로 만들 수 있는 거의 모든 "터미널의 이미지" 트릭을 수행할 수 있습니다.

• 터미널의 계층화된 셀별 마스크 이미지: https://jexer.sourceforge.io/images/sixel_many_images.png

• VT100 스타일 이중 너비 지원을 위해 Sixel을 사용하는 터미널의 부동(다중화) 터미널 창: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• 이미지가 있는 "tmux 스타일" 타일 터미널: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• 동일한 플롯을 표시하는 다양한 텍스트 셀 크기의 다중 헤드 공유 터미널 세션: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• Sixel을 사용하여 기본 터미널 글꼴에 없는 CJK 및 이모티콘 렌더링: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

참조된 "좋은" 프로토콜 스레드 에 관심이 있을 수 있는 몇 가지 다른 설명을 포함했습니다.

다른 것이 아니라면, Sixel은 그림과 텍스트가 혼합된 터미널 측 인프라를 만들기 위한 좋은 디딤돌입니다. 직접적인 경험에 따르면 터미널 측(이미지 저장/표시)은 멀티플렉서/어플리케이션 측(tmux/mc et al)의 약 1/4입니다.

Sixels는 실제로 대역 내 그래픽(예: ssh를 통한)에 이상적인 솔루션입니다. 많은 기존 도구에서 지원되므로 이동 중에 타임스탬프 동기화 문제를 플로팅하는 것과 같은 실용적인 목적으로 사용할 준비가 되어 있습니다.

realkenc에서 설명하고 640292222 에서 klamonte에서 추가로 설명하는 것처럼 모든 것은 Sixel로 처리할 수 있으며 심지어 나란히 있는 이미지까지 처리할 수 있지만 약간의 작업이 필요합니다.

얼마 전 저는 tmux의 대체 모드에서 다른 몇몇 사람들과 함께 고급 유니코드 그래픽 을 사용하여 Sixel을 지원하지 않는 터미널에서 Sixel 이미지를 표현하는 작업을 하고 있었습니다.

이것은 대부분의 글꼴에 있는 특수 블록 문자를 활용하는 자동화된 ANSII 아트와 약간 비슷합니다. 이 동등한 색상 유니코드 표현은 Sixel을 대체한 다음 나중에 실제 Sixel 이미지로 덮어쓸 수 있습니다(또는 그렇지 않을 수도 있습니다!). 또한 저충실도 유니코드 자리 표시자(예: 메모리 절약을 위해)로 대체하고 어떤 이유로든 표시할 수 없을 때 Sixel 이미지에 대한 자리 표시자를 사용하여 뒤로 스크롤하기 위해 모든 Sixel 사진을 유지하는 문제를 해결할 것입니다.

코드는 공개 도메인이었습니다. Sixel 지원을 위한 첫 번째 단계로 즉시 사용할 수 있습니다.

• Sixels 시퀀스가 ​​전송되는 시점을 감지한 다음 유니코드 텍스트 대체를 계산합니다.

• Windows 터미널에서 이미 지원하는 이 유니코드 시퀀스를 표시합니다.

• 나중에 Sixel이 구현되면 Sixel 시퀀스 위에 렌더링합니다.

관심이 있으실까요?

BTW 여기에서 내 친숙한 gnuplot x^2 sin 및 10 sin(x) 플롯 을 인식합니다.

제발.

@DHowett acac350 은 실제로 Sixel 그래픽을 렌더링하기 위한 첫 번째 단계입니까? ssh를 사용하고 내 lsix 프로그램을 사용하여 이미지 디렉토리를 보려는 사람들로부터 Microsoft 터미널에서 Sixel 지원에 대한 요청을 받고 있습니다.

소타. 이제 들어오는 DCS 시퀀스를 처리할 수 있습니다. 아직 핸들러를 연결하지 않았지만 이를 위한 인프라를 갖추는 것이 매우 중요했습니다. :웃다:

다음은 몇 가지 업데이트입니다. 여기 에 작업 지점이 있습니다. 초기 스크린샷은 다음과 같습니다.

원래 생각했던 것과 달리 식스엘 이미지를 렌더링할 때 가장 어려운 부분은 사실 conpty 레이어입니다. Sixel 이미지는 인라인 객체여야 합니다. Sixel 이미지의 렌더링은 캐릭터의 렌더링 크기에 따라 다릅니다. 그러나 추가 conpty 레이어로 인해 실제로 Sixel 시퀀스를 처리할 때 문자의 렌더링 크기를 얻을 수 없습니다. 이것은 매우 추상적이고 모호하게 들립니다. 이것에 관심이 있는 사람은 내 지점을 확인하고 완료되는 방법을 볼 수 있습니다.

전반적으로 conpty 레이어는 Sixel 이미지의 스크롤 및 크기 조정을 처리하는 것을 매우 어렵게 만듭니다. 내 지점에서는 표시해야 하는 경우에만 작동합니다. 그러나 스크롤과 크기 조정이 완전히 깨졌습니다.

아직 보지 않았지만 통과 모드를 사용하여 터미널 자체에서 구현할 수 있습니까? 여전히 OpenConsole에 추가하지만 코드 공유가 불가능한 것처럼 들립니다. Windows 터미널은 어느 시점에서 OpenConsole에서 분리되어야 하므로 두 코드 모두에 대해 단순히 코드를 복제하는 것이 가장 좋습니다. 또한 매개변수에 대해 귀하와 j4james PR을 기반으로 하고 있습니까? 그것도 도움이 될 것입니다.

@WSLUser 관심을 가져주셔서 감사합니다. 이 스크린샷은 실제로 j4james의 환상적인 매개변수 PR이 존재하지도 않았던 약 한 달 전의 것입니다. 내 작업은 전적으로 Windows 터미널 내부에 있으며 conhost가 아닙니다. 이 PR을 내부적으로 콘솔 팀에 보여줬고 그 이후로 약간의 진전이 있었습니다. 그러나 나는 conpty 문제 때문에 붙어 있습니다.

예, 마스터에서 리베이스하고 https://github.com/microsoft/terminal/pull/7578 및 https://github.com/microsoft/terminal/pull/7799를 추가합니다. 거기에서 통과 모드에 대한 ConPTY에서 누락된 항목을 확인할 수 있습니다. Mintty가 ConPTY 모드에 통과를 사용하고 있는지 궁금합니다.

Mintty가 ConPTY 모드에 통과를 사용하고 있는지 궁금합니다.

확실히 민티는 conpty를 전혀 사용하지 않습니다 😜

conpty의 트릭은 연결된 터미널에서 실수로 콘텐츠를 지우지 않기 위해 콘솔(conpty)이 Sixel 콘텐츠로 채워진 셀에 대해 알아야 한다는 것입니다. 아마도 conpty는 sizel 그래픽이 있는 페인팅 셀을 무시하고 연결된 터미널이 해당 셀을 그대로 둘 것이라고 가정할 수 있습니다.

이는 일부 최적화를 망칠 수 있지만(예: Sixel 데이터가 있는 EraseLine 행을 삭제할 수 없음) 시작하기에 충분할 수 있습니다.

\

아마도 conpty는 sizel 그래픽이 있는 페인팅 셀을 무시하고 연결된 터미널이 해당 셀을 그대로 둘 것이라고 가정할 수 있습니다.

이것은 내 원래 계획이기도 했고 현재의 conpty 아키텍처에서 가장 좋은 솔루션일 수도 있지만 여러 가지 복잡한 문제가 있습니다.

1. 이것이 DCS 스트리밍과 어떻게 상호 작용할까요? (아직 솔루션이 없다고 생각합니다). conhost 버퍼로 전송되는 동시에 바이트 스트림을 conpty로 전달하는 일종의 분할 스트림 개념이 필요하다고 가정하고 있지만 이는 프로세스에 불필요한 오버헤드를 많이 추가하는 것처럼 보입니다.
2. 이것은 conpty 터미널의 픽셀 셀 크기를 알고 있는 경우에만 작동합니다. 내가 전에 Sixel에 대한 최상의 솔루션은 원래 VT 터미널의 셀 크기를 일치시키는 것이라고 생각하며, 우리가 그렇게 하면 문제가 되지 않을 것이라고 생각합니다. 그러나 내가 아는 한 다른 터미널 에뮬레이터는 그렇게하지 않으므로 다른 사람과 작동하지 않습니다.

@j4james 가 제기한 두 번째 문제는 다른 글꼴, 다른 글꼴 크기 및 글꼴 크기 조정을 고려하면 훨씬 더 복잡해집니다. 따라서 일반적으로 문제의 3가지 측면이 있다고 생각합니다.

• 첫 번째 conpty는 Sixel 내용으로 채워진 셀에 대해 알아야 합니다. 이것이 없으면 conpty의 백업 버퍼와 WT의 그리기 버퍼가 필연적으로 동기화되지 않습니다.
• 그렇게 하기 위해 conpty는 WT의 드로잉 레이어에서 처리하는 드로잉 컨텍스트의 픽셀 셀 크기를 알아야 합니다. conpty와 실제 DXRenderer 사이에는 큰 차이가 있어 이를 어려운 작업으로 만듭니다.
• 또한 글꼴이나 글꼴 크기가 변경되면 이상적으로는 Sixel 이미지도 그에 따라 변경되어야 합니다.
• 그리고 마지막으로 창, 대체 버퍼, 차등 그리기, 스크롤 등과 같은 다른 작업을 처리합니다.

@j4james 가 제기한 두 번째 문제는 다른 글꼴, 다른 글꼴 크기 및 글꼴 크기 조정을 고려하면 훨씬 더 복잡해집니다. 따라서 일반적으로 문제의 3가지 측면이 있다고 생각합니다.

분명히 하자면, 제 요점은 VT340의 동작과 정확히 일치한다면 그 중 어느 것도 문제가 되지 않을 것이라는 점이었습니다. 따라서 10x20 픽셀 이미지는 글꼴 크기에 관계없이 정확히 하나의 문자 셀을 차지할 것입니다. 다른 터미널 에뮬레이터의 동작을 일치시키려는 경우에만 문제가 되며, 이는 항상 나중에 남겨두는 옵션일 수 있습니다. 이 접근 방식에는 여전히 복잡한 문제가 있지만 개인적으로 이러한 문제는 덜 우려할 만하다고 생각합니다.

제 더 큰 우려는 DCS 스트리밍 문제를 무시하는 것 같으며 솔루션의 아키텍처를 근본적으로 바꿀 수 있다고 생각합니다. 내가 보고 싶은 단계는 다음과 같습니다. 1. 해결 #7316; 2. 셀 픽셀 크기에 대한 솔루션에 동의합니다. 3. conhost에서 작동하는 것을 얻으십시오. 4. conhost에서 모든 복잡한 문제를 해결한 후에만 conpty에서 작동하도록 만드는 방법을 고려하십시오.

DCS 스트리밍 문제를 떠나서 죄송합니다. 현재 구현에서는 전체 문자열을 저장하고 엔진에 전달합니다. 시퀀스가 더 클 때 성능 문제가 발생합니다. 그러나 적어도 작동합니다. 따라서 위의 내 의견은 대부분 그것에 기반을 두고 있습니다.

하지만 당신이 옳습니다. DCS 스트리밍 문제는 실제로 다른 사람이 이 문제에 손을 대고 싶어하는 경우 최우선 순위입니다.

iOS용 获取 Outlook https://aka.ms/o0ukef

https://github.com/microsoft/terminal/issues/57 의 토론에 따르면 conpty가 글꼴에 대해 전혀 신경 쓰지 않는다고 생각 했습니까?

wrt 크기 조정 가장 자연스러운 방법은 이미지가 도착하면 이미지를 문자 셀에 "앵커다운"하고 앵커 지오메트리를 기반으로 이미지 크기를 다시 계산하는 것입니다. 다른 것은 이미지 대 문자 셀의 불일치를 야기합니다.

@yatli 네. 그것이 문제를 어렵게 만드는 이유이기도 합니다.

10x20 픽셀 이미지는 정확히 하나의 문자 셀을 차지합니다.

이것은 불행히도 적어도 현재 글꼴 설정에서는 잘못되었습니다.

내가 틀렸다면 정정해 주지만 완벽한 픽셀 이미지 표시를 위해서는 글꼴에 신경을 써야 한다고 생각합니다.

@skyline75489 pls는 "앵커"에 대한 업데이트된 댓글을 참조하세요.

셀 데이터 구조를 char | sixel anchor 로 업데이트해야 합니다.

Sixel 앵커에는 다음에 대한 정보가 포함되어야 합니다.

• 이미지 객체에 대한 포인터
• 부동 숫자(예: 5.2줄 x 7.8열)에서 차지하는 char 셀 영역

좋은 생각이지만 conpty 레이어의 추가 번역으로 인해 구현 세부 사항이 나를 죽이고 있었습니다. 이메일로 사람들에게 스팸을 보내는 것을 방지하려면 관심이 있으시면 언제든지 Teams @yatli 로 저에게 연락하세요.

10x20 픽셀 이미지는 정확히 하나의 문자 셀을 차지합니다.

이것은 불행히도 적어도 현재 글꼴 설정에서는 잘못되었습니다.

내가 제안하는 것은 당신이 그렇게 해야 한다는 것입니다. 10x20 픽셀 이미지를 만들어 실제 DEC VT320 터미널에 출력하면 정확히 한 문자(적어도 80 열 모드에서)가 필요합니다. 따라서 해당 터미널을 에뮬레이트하려는 경우 동일한 작업을 수행해야 합니다. 현재 글꼴이 30x60인 경우 이미지를 확대해야 합니다. 글꼴이 더 작으면 이미지의 크기를 줄입니다.

이렇게 하면 모든 글꼴 크기에서 Sixel 이미지를 출력할 수 있고 항상 동일한 레이아웃을 얻을 수 있습니다. 화면의 특정 영역을 덮거나 주위에 텍스트 문자로 테두리를 그리려면 이미지가 차지하는 공간을 정확히 알 수 있습니다.

내가 틀렸다면 정정해 주지만 완벽한 픽셀 이미지 표시를 위해서는 글꼴에 신경을 써야 한다고 생각합니다.

이런 식으로 "픽셀 완벽한" 이미지를 얻을 수 없다는 것은 사실이지만 이것이 주요 목표가 되어야 한다고 생각하지 않습니다. 많은 최신 컴퓨터에는 이미지를 확대하는 것이 일상적인 높은 dpi 디스플레이가 있으므로 이것이 이상한 개념은 아닙니다. 그리고 사용자가 글꼴 크기를 변경할 때 레이아웃을 일관되게 유지하려면 어쨌든 어느 시점에서 이미지의 크기를 조정해야 하므로 처음부터 크기를 조정하고 예측 가능한 모든 이점을 얻을 수 있습니다. 크기.

물론 이런 식으로 작업을 수행하는 다른 이점은 conpty를 통해 실행 가능하게 구현할 수 있다는 것입니다. 이미지가 차지하는 영역이 글꼴 크기에 의존하는 경우 어떻게 conpty 작업을 할 수 있는지 알 수 없습니다.

이 접근 방식에 단점이 없는 척 하지는 않겠지만 긍정적인 부분이 부정적인 부분을 능가한다고 생각합니다.

글꼴의 가로 세로 비율이 10:20과 다른 경우 어떻게 합니까?

글꼴의 가로 세로 비율이 10:20과 다른 경우 어떻게 합니까?

터미널 에뮬레이터의 인라인 이미지와 관련된 일반적인 문제에 대한 이 길고 다소 "잔인한" 토론을 읽는 것이 좋습니다.

그것은 당신에게 일반적인 아이디어를 줄 수 있습니다.

친애하는

글꼴의 가로 세로 비율이 10:20과 다른 경우 어떻게 합니까?

이미지가 약간 늘어나거나 찌그러질 수 있지만 그것이 세상의 끝은 아니라고 생각합니다.

실제 사례를 통해 보여드리겠습니다. 내가 본드의 악당이고 VT340을 프런트엔드로 사용하는 오래된 보안 시스템을 가지고 있다고 상상해 보십시오. 지금은 코로나로 인해 집에서 락다운을 하고 있어서 윈도우 터미널로 원격으로 시스템에 로그인을 하고 있습니다. VT340과 정확히 일치하면 문제가 되지 않습니다. 터미널은 다음과 같습니다.

그러나 아마도 나는 이상한 종횡비의 글꼴을 선호합니다. 그래서 대부분의 것보다 더 넓은 _Miriam Fixed_가 어떻게 생겼는지 봅시다. 본드의 이미지는 이제 약간 찌그러진 것처럼 보이지만 여전히 쉽게 알아볼 수 있습니다.

대안은 픽셀 완벽한 이미지를 사용하는 것입니다(현재 conpty에서는 가능하지 않지만 잠시 가정해 보겠습니다). Bond는 더 이상 찌그러진 것처럼 보이지 않지만 이제 이미지는 예상 크기의 일부에 불과합니다. 그리고 모니터의 해상도가 높을수록 더 나빠 보입니다.

이것은 개인적인 취향의 문제일 수도 있지만, 저는 분명히 옵션 2보다 옵션 1을 선택할 것임을 압니다.

또한 글꼴 종횡비가 1:2가 아닐 때 정확한 동작을 조정할 수 있는 옵션이 없을 이유가 없습니다. 한 가지 옵션은 이미지가 차지할 것으로 예상되는 셀 내 중앙에 이미지를 배치하는 것입니다. 또는 전체 영역을 덮도록 이미지를 확장할 수 있지만 경계를 넘지 않는 가장자리는 자를 수 있습니다. 내 의견으로는 정확한 픽셀 렌더링보다 이러한 선택이 더 나을 것입니다.

이것은 개인적인 취향의 문제일 수도 있지만, 저는 분명히 옵션 2보다 옵션 1을 선택할 것임을 압니다.

나 역시 글꼴이 다른 종횡비를 가지고 있다는 것을 아는 것이 더 나을 것이므로 이미지가 스스로 조정되고 올바른 것을 유지할 수 있습니다.

한 가지 옵션은 이미지가 차지할 것으로 예상되는 셀 내 중앙에 이미지를 배치하는 것입니다. 또는 전체 영역을 덮도록 이미지를 확장할 수 있지만 경계를 넘지 않는 가장자리는 잘라냅니다.

중앙에 두는 것이 좋다고 생각합니다.

어쩌면 내가 이 스레드를 잘못 읽고 있는지도 모릅니다. 실제로 우리는 터미널이 Sixel 이미지에 대해 10:20 문자를 가짜로 만드는 것에 대해 이야기하고 있습니까? 본드 왜곡과 같은 많은 문제가 발생할 것이라고 생각합니다. 올바른 방법으로 수행하는 것이 더 어려울 수 있지만 내 겸손한 생각에 현대 터미널은 글꼴에 구애받지 않아야 하며 응용 프로그램 프로그래머가 Sixels 및 문자 셀을 처리하도록 해야 합니다.

이스케이프 시퀀스를 사용하여 사용자 실행 프로그램은 문자 셀 크기를 픽셀 단위로 결정하고 해당 응용 프로그램의 왜곡을 지능적으로 처리하는 방법을 결정할 수 있습니다. 내가 사용하는 이미지 보기 프로그램은 정확히 그렇게 작동합니다. 글꼴 모음이나 크기를 변경하면 표시된 축소판은 항상 정확히 5줄 높이로 업데이트됩니다. 너비는 특정(이 경우 다소 큰) 최대값보다 크지 않는 한 이미지에 비례하여 크기가 조정됩니다. 이미지 크기를 문자 셀에 기반하여 높은 DPI 화면에서 자동으로 작동합니다.

VT340은 에뮬레이트하는 고귀한 목표이지만 문자 셀 해상도를 10:20으로 고정하는 것(따라서 전체 화면의 해상도를 제한하는 것)은 실수입니다. VT340은 여러 Sixel 구현 중 하나일 뿐이므로 글꼴 크기가 반드시 더 정확하지는 않습니다.

10:20을 강요하는 것도 추악한 클러지로 이어질 것입니다. (예를 들어, 터미널 창의 크기(픽셀)에 대한 요청에 응답하는 방법. 사실을 말하세요. 창을 화면에 배치할 것이라고 가정합니까? 아니면 사용자가 Sixel 출력을 위해 이미지 크기를 조정한다고 가정하고 항상 800x480을 반환합니까? )

실제로 우리는 터미널이 Sixel 이미지에 대해 10:20 문자를 가짜로 만드는 것에 대해 이야기하고 있습니까?

네.

최신 터미널은 글꼴에 구애받지 않아야 합니다.

이 제안은 글꼴에 구애받지 않습니다. 응용 프로그램은 글꼴에 대해 알 필요가 없습니다. 그게 요점입니다.

이스케이프 시퀀스를 사용하여 사용자 실행 프로그램은 문자 셀 크기를 픽셀 단위로 결정하고 해당 응용 프로그램의 왜곡을 지능적으로 처리하는 방법을 결정할 수 있습니다.

어떤 방법을 사용하고 있는지 정확히 모르겠지만 이전에 본 방법은 독점 XTerm 쿼리를 사용하여 창 픽셀 크기를 가져오고 다른 쿼리를 사용하여 창 셀 크기를 가져온 다음 이를 사용하는 것입니다. 데이터를 사용하여 실제 셀 픽셀 크기를 계산합니다. 이러한 접근 방식의 단점은 다음과 같습니다.

1. 독점적이므로 실제 터미널이나 실제 터미널과 정확히 일치하는 터미널 에뮬레이터에서는 작동하지 않습니다.
2. 응용 프로그램이 실행되는 동안 사용자가 글꼴 크기를 변경하면 계산이 더 이상 정확하지 않고 이미지가 잘못된 크기로 렌더링됩니다(비실용적으로 보이는 글꼴 크기를 계속해서 다시 계산하지 않는 한).
3. 사용자가 고해상도 디스플레이 및/또는 큰 글꼴 크기를 사용하는 경우 해당 해상도와 일치시키기 위해 대용량 이미지를 보내야 합니다. Sixel이 처음부터 얼마나 비효율적인지 고려하면 많은 대역폭이 될 수 있습니다.

즉, 이것이 일부 사람들이 사용하고 싶어할 수 있는 모드라는 것을 이해하고 언젠가는 이를 지원할 수 있는 옵션이 최소한 있어야 한다고 생각합니다(위에서 논의한 이유로 현재로서는 불가능합니다). 그러나 제 생각에는 이것이 Sixel에 대한 최선의 접근 방식은 아닙니다.

나는 원자력 발전소에 300개 이상의 VT340을 가지고 있으며 궁극적으로 원합니다.
바꾸다.

우리가 사용할 수 있는 상용 터미널 에뮬레이션 패키지가 있지만 제 생각에는
하나를 제외하고 모두 EoL'd되었습니다.

우리는 그 중 일부를 XTerm(또는 그 이하)을 실행하는 Linux PC로 교체했습니다.
자주, Win10 + Hummingbird + XTerm을 실행하는 WSL),
중간 정도의 괜찮은 오픈 소스 Sixel 구현과 일종의 나쁜, 하지만
오픈 소스 RegIS 구현.

우리가 이 부분을 위해 새로운 소프트웨어를 작성할 가능성
Sixel 옥텟 스트림을 생성하는 시스템은 NIL입니다.

인라인 옥텟 스트림을 통해 그래픽을 보내는 것이 목표인 경우
다른 옵션입니다. 그러나 Sixel 그래픽을 지원하려면
이전과 절반 유사한 방식으로 Sixel 그래픽을 지원합니다.
구현. 이것은 불행히도 에뮬레이션해야 함을 의미합니다.
예시 시스템의 동작(예: VT240, VT241, VT330 및 VT340
터미널) 그래픽을 텍스트와 통합하는 경우에도 마찬가지입니다.

이것은 내가 말하는 종류의 모형입니다. 그것은 매우
새로운 Sixel 구현이 기존과의 호환성을 유지하는 경우 좋습니다.
이미지가 화면 가장자리에서 벗어나지 않도록 구현하거나
화면의 절반을 채웁니다.

https://vimeo.com/user32814426/review/467991744/ac5892fa7e

최신 터미널은 글꼴에 구애받지 않아야 합니다.

이 제안은 글꼴에 구애받지 않습니다. 응용 프로그램은 글꼴에 대해 알 필요가 없습니다. 그게 요점입니다.

나는 _terminal_이 모든 글꼴에 10:20을 부과하는 대신 글꼴에 구애받지 않아야 한다는 것을 의미했습니다. 응용 프로그램은 원하는 경우 실제 글꼴 크기를 알 수 있어야 합니다. 응용 프로그램이 표시하려는 영역을 알고 텍스트와 그래픽을 함께 표시하는 가장 좋은 방법을 파악할 수 있기 때문입니다.

이스케이프 시퀀스를 사용하여 사용자 실행 프로그램은 문자 셀 크기를 픽셀 단위로 결정하고 해당 응용 프로그램의 왜곡을 지능적으로 처리하는 방법을 결정할 수 있습니다.

어떤 방법을 사용하고 있는지 정확히 모르겠지만 이전에 본 방법은 독점 XTerm 쿼리를 사용하여 창 픽셀 크기를 가져오고 다른 쿼리를 사용하여 창 셀 크기를 가져온 다음 이를 사용하는 것입니다. 데이터를 사용하여 실제 셀 픽셀 크기를 계산합니다.

네, 맞습니다. 문자 셀 크기를 직접 가져오는 쿼리도 있지만 화면 크기를 가져와서 ROWS와 COLUMNS로 나누는 것만큼 널리 지원되지는 않는다고 생각합니다.

이러한 접근 방식의 단점은 다음과 같습니다.

1. It's proprietary, so wouldn't work on a real terminal, or any terminal emulator that exactly matched a real terminal.

그것은 단점이 아닙니다. 이는 프로그램이 어쨌든 수행했을 작업을 수행해야 한다는 것을 의미할 뿐입니다. $TERM=="VT340"은 문자 셀이 10:20임을 의미하고, "VT240"은 10:10을 의미하고, "mskermit"은 8:8을 의미하고, 등등.

또한 xterm 독점 시퀀스가 ​​아닙니다. 화면 크기를 얻는 것을 "dtterm" 이스케이프 시퀀스라고 하지만 실제로 SunView에서 처음 구현되었습니다(SunOS, 1986). 나중에 PHIGS 프로그래밍 매뉴얼(1992)에 문서화되었다고 생각합니다. "\e[14t"를 몇 개의 터미널 에뮬레이터에 보내면 널리 구현되었음을 알 수 있습니다.

2. If the user changes their font size while your application is running, then your calculations will no longer be correct, and images will be rendered at the wrong size (unless you're continuously recalculating the font size which seems impractical).

이것은 문제가 아닙니다. 프로그램은 단순히 SIGWINCH를 트랩하고 창이 실제로 변경된 경우에만 다시 계산합니다.

3. If the user has a high resolution display, and/or large font size, you're forced to send through a massive image to try and match that resolution. Considering how inefficient Sixel is to start with, that can amount to a lot of bandwidth.

예, Sixel은 매우 비효율적입니다. 그러나 최신 컴퓨터에서는 ssh를 통해서도 전체 화면 이미지를 보내는 것이 매우 유용합니다. Microsoft 터미널에 일종의 전송 속도 제한이 있습니까?

그건 그렇고, Sixel에는 모든 점이 너비와 높이가 두 배로 늘어나는 "높은 DPI" 모드가 있다고 생각합니다. 나는 그것을 사용한 적이 없으며 xterm이 그것을 구현한다고 생각하지 않지만 아마도 대역폭에 대한 우려를 완화할 것입니다.

즉, 이것이 일부 사람들이 사용하고 싶어할 수 있는 모드라는 것을 이해하고 언젠가는 이를 지원할 수 있는 옵션이 최소한 있어야 한다고 생각합니다(위에서 논의한 이유로 현재로서는 불가능합니다).

이 "모드"는 단순히 다양한 역사적 Sixel 터미널과 현재 에뮬레이터가 하는 것처럼 문자와 그래픽을 정렬하는 것입니다. 인정합니다. Microsoft 터미널에서 동일한 작업을 수행할 수 없는 이유를 이해할 수 없습니다. 이 10:20 kludge가 할 수 있는 최선이라고 말한다면, 나는 당신이 옳다고 믿고 그것을 해주셔서 감사합니다. 왜곡된 그림은 없는 것보다 훨씬 낫습니다.

이스케이프 시퀀스를 사용하여 사용자 실행 프로그램은 문자 셀 크기를 픽셀 단위로 결정하고 해당 응용 프로그램의 왜곡을 지능적으로 처리하는 방법을 결정할 수 있습니다.

@hackerb9 , 글꼴 크기를 얻기 위한 실제 이스케이프 시퀀스는 무엇입니까?

관련 XTerm 시퀀스는 https://invisible-island.net/xterm/ctlseqs/ctlseqs.html 에서 찾을 수 있습니다. -- XTWINOPS를 찾으십시오.

또한 Unix에서는 일반적으로 TIOCGWINSZ ioctl을 사용하여 셀 크기와 함께 터미널의 내부 픽셀 크기를 얻을 수 있습니다. openssh를 사용하면 원격으로도 작동합니다.

데이터 포인트와 마찬가지로 libvte의 Sixel 분기는 @hackerb9 가 말하는 셀 크기에 구애받지 않는 경로를 취하고 있습니다. 들어오는 Sixel 데이터를 "완벽한 픽셀"로 처리하고 일관된 셀 범위를 포함하도록 확대/축소 수준과 글꼴 크기에 걸쳐 이전에 받은 이미지의 크기를 조정합니다. 병합되면 이 구현은 GNOME 터미널, XFCE 터미널, 터미네이터 등을 포함한 많은 Linux 터미널 에뮬레이터에서 사용할 수 있습니다. 표면적으로 이것은 최소한 XTerm 및 mlterm과 상호 운용 가능한 것으로 보입니다.

libvte는 이미지당 가상 셀 크기를 기록하므로 상호 운용을 위해 고정된 가상 10x20 셀 크기로도 이 작업을 수행하는 것은 간단합니다. 그러나 프로그램이 예상 픽셀:셀 비율을 터미널에 전달할 수 있는 방법이 필요합니다(예: DCS 매개변수 확장). 위에서 언급했듯이 대역폭이 제한된 환경에서 일종의 픽셀 밀도 제어를 제공하기 때문에 일반적으로 매우 유용할 수 있습니다.

또한 Unix에서는 일반적으로 TIOCGWINSZ ioctl을 사용하여 셀 크기와 함께 터미널의 내부 픽셀 크기를 얻을 수 있습니다. openssh를 사용하면 원격으로도 작동합니다.

Linux 콘솔은 항상 0을 반환합니다... 수정해야 하지만 그렇게 하려는 것은 아닌 것 같습니다.-/