Bottom (htop windowson) Putty-ból

Microsoft Windows

Használ valaki Bottom -ot ami egy htop -szerű rendszermonitorozó tool windowsra, ssh-ról? A lényeg, hogy távoli gépről a windows gépre. 

https://github.com/ClementTsang/bottom

Sajnos putty-ból és linuxos ssh-nál is teljesen szétesik a karakteres kép. Lokálisan természetesen tökéletesen működik, de pont az ssh kapcsolatra kellene. Lokálisan ott van a task manager is. 

( NevemTeve | 2022. 12. 07., sze – 21:36 )

Most Windows-ból mész Unixba putty-val, vagy fordítva? Tudnád ábrával ilusztrálni a történetben szereplő komponenseket?

Szerintem Putty-ban csak simán meg kéne növelned a sortörést, hogy ne 80 karakternél törjön, hanem lényegesen többnél, jóval 100 felett. Illetve Windowson nem kell már Putty-t használni, a Windows Terminal (ez egy újabb eszköz, nem a cmd.exe-ről van szó) is elérhető már telepítésre a Store-ból, amin sanszosabban jobban fog működni az SSH, és a terminálos eszközök, mint ezer éve nem fejlesztett windowsos Putty-ból.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

mint ezer éve nem fejlesztett windowsos Putty-ból.

What?

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

This page contains download links for the latest released version of PuTTY. Currently this is 0.78, released on 2022-10-29.

Aláírás _Franko_ miatt törölve. 
Jákub egy .
neut @

Az tudtam, hogy fejlesztik, de azt nem hittem, hogy a WINDOWSOS bináris ilyen friss. Általában Winre ritkábban adnak ki, mert ott úgyis visszafelé kompatibilis minden, jobban lehet lustulni. De ez jó hír, akkor tuti, hogy a Putty-t is be lehet állítani normálisra, legalábbis ez nem lesz akadálya, hogy túl régi verzió.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Már pedig a legtöbb windowsos userben benne van ez a mentalitás, hogy az 5-10 éve letöltött .exe-ket használja. Új verziót nem tölt, mert az lassít, meg babzsákfejlesztős valami. Plusz mivel ezek unixlike, linuxos szoftverek, hiába multiplatformosak, kicsit pain in the ass MS/Intel vagy cygwin-es fordítóval lefordítani, ezért nem mindig van rá, aki vállalkozik, hogy rendszeresen fordítja és kitolja az új verziókat Windowsra is. Linuxnál nem gond, mert ott simábban forog forráskódból gcc-vel meg llvm/clang-gal, és amúgy is buildszerverken és tárolókkal megoldják, hogy mindenki a legfrissebbet használja.

Nyakamat tenném rá, hogy a témaindító is valami elég régi verziót használhat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Illetve Windowson nem kell már Putty-t használni, a Windows Terminal (ez egy újabb eszköz, nem a cmd.exe-ről van szó) is elérhető már telepítésre a Store-ból, amin sanszosabban jobban fog működni az SSH, és a terminálos eszközök

Én meg csak elindítom a WSL-be telepített Debiant, és a Linux shell-ből adom ki az ssh parancsot.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Bárki bármit mond hogy nem frissül/támogatott vagy elavult az OpenSSH Windowson, az nem ért hozzá. A Windows 10 és 11 beépített OpenSSH szervert és klienset tartalmaz, amit a Microsoft fejleszt, javít és támogat.

Ha ezt használod, akkor tökéletesen működik a btm.

Telepítsd fel a Windowsra az OpenSSH szervert 

https://learn.microsoft.com/en-us/windows-server/administration/openssh…

Ha ez megvan, akkor másold át a sshd konfigot a megfelelő helyre. Ez a konfig szabványos OpenSSH konfig.

copy C:\Windows\System32\OpenSSH\sshd_config_default C:\ProgramData\ssh\sshd_config

Majd indítsd el az sshd szervert

net start sshd

 

Ha ezt használtad idáig, akkor viszont elegendő beállítani a default powershellt az sshd-nek:

https://learn.microsoft.com/en-us/windows-server/administration/openssh…

 

Az ssh kliens a Windows 10/11 része, csak ezért nincs szükség puttyra.

Így van. Kivételesen 2021-ben a MS eljutott oda, hogy tudott használható SSH szervert integrálni végre a szutykába. Plusz ami miatt nem kell Putty, hogy már normális a Windows Terminal is, rendes sok füles, ANSI színkódos, unicode-os, mindenféle támogatás, normálisan használható, nem kell 3rd party megoldást töltögetni, ha valaki Windowson is normális terminált akar.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezt eddig nem tudtam. Ez jó.

Kérdés: ha sshd-t futtatok windows-on, és valahonnan bejövök ssh-val, akkor milyen shell-t kapok alapból, illetve mik közül lehet választani?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Itt van példa (a Júzernév csere szükséges az utolsó kettőben)

command prompt:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\cmd.exe" -PropertyType String -Force

power shell:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Users\Júzernév\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe" -PropertyType String -Force

far manager:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Users\Júzernév\AppData\Local\Far Manager x64\Far.exe" -PropertyType String -Force

Nem a registry bejegyzésbe írod a környezeti változót, hanem a commandba, így feloldásra kerül mielőtt bekerülne a registrybe.

Közben észrevettem hogy PS commandokat írtál, abban meg így néz ki:

"$env:LOCALAPPDATA\Far Manager x64\Far.exe"

És hogy is nézne ki az a command? Mert ez nem oldja fel, és én nem tudom, de hagyatkoznék a tapaszalatodra, és lehet másnak is segítség

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "%LOCALAPPDATA%\Far Manager x64\Far.exe" -PropertyType String -Force

Rossz válasz.

[ -shell + terminál emuláció (terminfo) ] - (sshd vagy drót!!) - { ssh - terminál emuláció } vagy terminál

Ebben a kontextusban az ssh == drót, ami a legkevésbé sem befolyásolja a terminált. Sőt, shellt sem kötelező indítani. Ebben az esetben csak az jön ki, amit az elindított program küld. Pl. a [] közötti rész lehet gzip -c file és már jön vissza a csövön a tömörített file.

A {} között a putty funkciója szerepel. Ha a szerver oldali terminál emulációval nem jön össze a terminál, akkor egyiket, másikat vagy mindkettőt megfelelő módon konfigurálni kell!

Ez lehetetlen. Ha mindenki értené, akkor tényleg mindenki mindent tudna, tehát ez a topic sem jött volna létre. Esetleg a nekem működik releváns megálapításon kivül értelmesebb javaslat is született volna.

A végén kezdve: A putty egy terminál program, ami többek közott ismeri az ssh protokollt is. Van neki egy ilyenje is

PuTTY Configuration -> Terminal -> ...

No ugye, a blabla egy része máris világosodik! :-D

Terminál: Adatfeldolgozást végző számítógéphez kapcsolt kisebb számítógép, amelyen az adatokat beviszik, ill. amelyen az eredmények megjelennek. (Wikiszótár) Itt meg szó sincs valódi terminálról, hanem egy szoftverről, ami úgy csinál, mintha a fenti definíció szerinti szerkezet lenne.

Az igazi terminál pl. soros vonalon (alias drót) kapcsolódik a másik számítógéphez. Az ssh, ha elhanyagoljuk a sok-sok nyűgjeit, miszerint authentikál, tikosít, stb., stb., kapcsolódás után - szempontunkból csak egy drót, ami nem módosítja a rajta áthaladó adatokat.

Ezen a pálcikás ábrán a szerver (program) -> terminál kapcsolatot bontottam ki. Azaz

[ -shell + terminál emuláció (terminfo) ] - (sshd vagy drót!!) - { ssh - terminál emuláció } vagy terminál

de a magyarázat után csak ennyi marad:

shell + terminál emuláció - terminál

Eltűnt az ssh, aminek semmi köze sincs a megjelenített képhez.

Tehát a

Bárki bármit mond hogy nem frissül/támogatott vagy elavult az OpenSSH Windowson, az nem ért hozzá. A Windows 10 és 11 beépített OpenSSH szervert és klienset tartalmaz, amit a Microsoft fejleszt, javít és támogat.

rossz válasz, köze nincs hozzá. Csak azzal keverted össze, hogy mindkét oldalon MS program fut.

A terminfo (lásd: man terminfo) a terminal capability data base, képes elmagyarázni szerver oldalon, hogy pl. a PuTTY hogyan valósítja meg az egyes terminál funkciókat. (leánykori nevén: termcap) Ez *nix rendszereken így van. Ha egy adott rendszeren nincs terminfo, akkor is csinálja valahogy. ;)

Amit tudunk a terminálokról:

  • PuTTY = xterm-256color
  • Windows Terminal (ms-terminal) = xterm

Szóval minden rendben! Hiszen a megvalósított terminálok egyformák. Azaz , mégse, mert számtalan rendszer van és mindenki másképp csinálja. Éppen ezért építették be a putty terminál konfigurációs lehetőséget, amivel elvégezhető a finomhangolás.

Háát, ebből meg nem mondom (egyik terminfo.src-ből idézve)

ms-terminal|Windows10 terminal,
        npc,
        cud1=\E[B, kcbt=\E[Z, rmkx=\E[?1l, rmm@, smkx=\E[?1h, smm@,
        Cr@, Ms@, use=xterm+256color, use=xterm+pcfkeys,
        use=ansi+rep, use=xterm+sm+1006, use=ecma+index,
        use=ecma+italics, use=ecma+strikeout, use=xterm-basic,
        use=xterm+tmux,

Ha ezek között van olyan, ami tudja a 24 bit colort, akkor igen. Tehát a "vonalon" küldött szekvenciákkal tudod váltani a színeket.

Ámbár ezen leírás szerint tudod állítani a palettát, de csak annak az elemeit 24 biten.

A sejtésem az, hogy legfeljebb a grafikus terminálok tudják a 24 bitet. Bár a terminálokból majdnem annyi létezik, mint a linux disztrókból. Szóval sok.

Viszont bevallom, hogy az ms-terminal abszolút hidegen hagy és (már megint!! :-D) úgy kiheréltem a vindózomat, hogy képtelen lennék felrakni a Windows Terminált.

A színes dolgok abszolút hidegen hagynak, és munkához vim/vi editort használok (vindóz alatt is) fekete + 3 zöld vagy fehér árnyalattal, mint egy valódi monokróm terminál.

Ezt most nem értem, hol írják ezt a not to be confused részt?

Én ilyenről nem tudok, hogy Windows Console. Csak cmd.exe-ről tudok, ezt Command Prompt-nak hívják elvileg. Meg a külön telepíthető Windows Terminal-ról, ami a Store-ból elérhető (ennek semmi köze a cmd.exe-hez, egy teljesen külön álló, új fejlesztés, ami a Win10 óta elérhető, de külön kell telepyteni). Most hogy ez a Console micsoda, fogalmam sincs, szerintem csak valami kitalációs hülyeség.

Egyébként ez azt a konzol-terminál keverést Linuxon, BSD-ken is utálom. Sokan szinonimaként használják teljesen következetlenül. A konzol az a text alapú konzol, igaz modern OS-eken már ez is grafikus módban megy, és nem a klasszik VGA/BIOS módú text mód, ez az a konzol, ahová a betöltődő kernel írogatja bootkor a kimeneteit. Ami grafikus felületek alatt van, azok terminál emulátorok, rövidítve terminálok, de azok nem konzolok. Épp így több ember nem szokta érteni, hogy a termináltól teljesen különböző dolog a shell is, sőt, még a shell-ekből is vannak különböző szintek, más lehet a user login shellje, más a script elején megadott feldolgozóshell a shebang-ben (ez ha /bin/sh, az néha symlinkelve lehet valami másra), és más az az interaktív shell, amit a user a terminálban nyit, ezek mindegyikét külön is lehet állítani. Nálam a login shell a Bash, a shell scriptjeimben használt /bin/sh a Dash-re mutat (ehelyett írhatnék mást, pl. /bin/zsh, vagy amit akarok, vagy a /bin/sh-t átlinkelhetném valami másra), az interaktív shellem meg a Bash, de beállíthatnék zsh-t vagy nushellt, vagy akármi mást is, pl. fish-t, vagy akár ksh-t, tchs-t (ezeket meg lehet adni a terminálra mutató .desktop fájlban, vagy egyéb menüben, vagy keyboard demonban). Látom Redmondban is kevergetik ezeket ezerrel, mondjuk nekik elnézem, náluk nem volt már régóta népszerű a terminál, így még régi windowsos meg DOS-os beidegződések alapján becézik mindenfélének, most is csak azért lett újra népszerű, mert kellett valami normálisabb a powershell meg a WSL alá, az a régi, elavult cmd.exe-t már senki nem tudta semmire használni. Reméljük egy ponton kitisztul nekik a kép.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Én ilyenről nem tudok, hogy Windows Console.

Pedig:

When the Windows GUI’s implementation started to arrive, the team needed a Console GUI app and thus, the Windows Console was born.

Továbbá:

Csak cmd.exe-ről tudok, ezt Command Prompt-nak hívják elvileg.

Nem (kiemelés tőlem):

Starts a new instance of the command interpreter, Cmd.exe.

Vagyis ez kb. ekvivalens a shellel, mint a bash vagy a zsh. Ha kiadsz egy cmd-t cmd alól akkor nem egy új ablakot kapsz, csak egy új parancsértelmező szintet. Mivel ez egy konzol alkalmazás, ezért amikor elindítod, alapból kapsz hozzá egy virtuális terminált. De semmi nem akadályoz meg abban, hogy másik virtuális terminálban használd, akár Windows Terminalban.

Egyébként ez azt a konzol-terminál keverést Linuxon, BSD-ken is utálom.

Akkor erre varrj gombot:

Generally, on *NIX based systems, when a user wants to launch a Command-Line tool, they first launch a Terminal. The Terminal then starts a default shell, or can be configured to launch a specific app/tool. [...]

Windows users never launch the Console (conhost.exe) itself: Users launch Command-Line shells and apps, not the Console itself!

A conhost.exe más terminál használata esetén is fut a háttérben.

Reméljük egy ponton kitisztul nekik a kép.

Remélem neked is.

Kösz, ilyen korrektül összefoglalva így már világos lett, de nem tudom, hogy a MS miért keveri ezt így meg. Bevallom lassan már olyan régóta linuxozok, hogy nem követem a Windows világát ilyen szinten. De komolyan, tegye fel a kezét, aki ezt tudta, hogy a cmd.exe csak egy shell, és egy sehol nem reklámozott Console-ban jelenik meg. A conhost.exe folyamatot láttam már, de arról sem reklámozták sehol, hogy micsoda. Ezt szerintem sehol nem kommunikálták le rendesen. Jó, lenne, ha egyértelműsítenék a dolgokat, meg összevonnák, és nem lenne 2 féle terminálalkalmazás (mert a Console továbbra sem konzol, ezt még mindig tartom, az egy grafikus terminálemulátor továbbra is). Mert így még tényleg olyan emberek is keverni fogják, akik pedig értenék a különbséget, ha nem lennének ilyen fütyiül elnevezve dolgok. A DOS korszakban még minden tiszta volt, tényleg volt text mode console (linuxos tty-nak megfelelő), és abban világos volt, hogy a command.com maga a shell, ami a Batch fájlokat is értelmezi/futtatja, és le lehetett cserélni 4DOS shellre.

Ezzel a mindenféle keveréssel csak azt érik el, hogy a userek és a poweruserek 99%-a is csak kevergetni fogja a dolgokat, és használják tovább az 5-10 évvel ezelőtt letöltött putty.exe-jüket. Nem az én kedvemért kéne rendbe tenni a dolgokat, hanem a masszív windowsos felhasználói bázisnak lenne fontos, hogy tisztán lásson.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ugyan nem néztem meg Wikipédián :-D, mert az első számítógép, amihez hozzáfértem, (TI57 kalkulátor nem ér!) egy Odra 1204 volt. Ott sem a konzolhoz, csak lyukszalagon keresztül, bár az operátoroknak már  képernyős konzoljuk is volt.

A konzol (gépeszet, mechanika -> tartó) itt (számítástechnika, mert akkor még nerm hívták informatikának) == (C shape) console (tele-)typewriter. Rövidítése: C.

Pl. ilyen: https://upload.wikimedia.org/wikipedia/commons/8/8f/Ken_Thompson_%28sitting%29_and_Dennis_Ritchie_at_PDP-11_%282876612463%29.jpg

Ha megfigyeled, Ken Thompson bácsi térgyekalácsa felé néz a C alakú konzol. A komplett szerkezetet konzolírógépnek nevezzük. Azért kellett komolyabb mechanikai tartószerkezet ezekhez a kütyükhoz, mert nemhogy Core i7, de egy fia tranzisztor vagy elektroncső sem volt bennük. Érdemes megnézni ezt a tündéri kis filmecskét: Using a 1930 Teletype as a Linux Terminal

A console (konzol) nem más, mint amivel a számítógépet (akármit) irányítjuk vagy kommunikálunk vele vagy megfigyeljük. Prédául odacsattintok az egérrel, hogy (Firefox) Eszközök -> Böngészőkonzol...

Tehát konzol == funkció.

A terminál egy olyan eszköz, amit a számítógép "nyúlványának" a végére dugunk. A számítógépnek bármilyen csatlakozója lehet, amire rádughatunk egy konzolírógépet. Tehát a drót végén csücsül a (tele-)typewriter. Innen jön a tty elnevezés, ami gyakran console funkciót lát el. Van is ilyen még a DOS device kategóriában is: CON:

Tehát terminál = eszköz.

Így aztán, ha egy olyan távolról is elérhető számítógép első soros portjára egy soros terminált dugsz, ami a konzol funkciót látja el, akkor naná, hogy kevered a konzol és terminál kifejezéseket!

Nomármost, a text alapú konzol helyesen ejtve: alfanumerikus terminál ;) Még akkor is, ha egy grafikus operációs rendszer képernyőjén vagy grafikus terminálon, vagy annak egy ablakában jeleníted meg. (Lásd: X terminálon megjelenített konzol vagy terminál, amikor a window manager nincs elindítva.)

Így aztán a terminál (kijelzője alias display) lehet alfanumerikus, félgrafikus vagy grafikus. A windows DOS ablak alfanumerikus, de a 1602 LCD félgrafikus, mert egyes karaktereket pixelenként definiálhatsz.

Tehát a terminál üzemmódja = képesség.

No, ez van leírva a termcap vagy terminfo adatbázisokban. (Termcap = terminal capability) Terminál helyett mondhatnánk terminál emulációt, de az hosszú lenne. A gyakorlatban még egy valódi soros terminál is egy egész csomó terinált tud emulálni. Ha egyszer a terminálodat átkapcsoltad pl. Wyse60 terminál(emuláció)ra, akkor az egy ilyen eszközként viselkedik.

Egyébként ez azt a konzol-terminál keverést Linuxon, BSD-ken is utálom.

Mert nem érted. ;) A konzol funkció elég régen átdefiniálható és átirányítható. Ha az említett rendszereket utálod, akkor néz meg, hogy AIX alatt sincs másképp: chcons swcons ;)

...rövidítve terminálok, de azok nem konzolok

Hacsak nem valami egyéb célú kozol, mint fent a firefox, vagy éppen arra a terminálra irányítottad a konzolt.

Látom a kavarodást - jogosan, hogy a konzolhoz nem minden esetben társul command processor és ez zavart okoz. Fokoznám. ;) Néha terminál sem tartozik. Ez egy ilyen játék.

Nálam a login shell a Bash, a shell scriptjeimben használt /bin/sh a Dash-re mutat...

Minimum a következők vannak

  • default shell: "Ezzel működik" az operációs rendszer, a működéshez szükséges scriptek.*
  • default shell: Ez egy másik, ami a default user létrehozásához rendelhető login shell.
  • default shell: Ez a harmadik, ami (általában) az első default shell-re mutat.
  • Amiben éppen egy scriptet írsz.
  • És van a chsh parancs is.

* Úgy 30 évvel ezelőtt a *nix operációs rendszerekben a programok 70 százaléka script volt. Azóta egyre szaporodnak a bináris megoldások...míg eljutottunk a systemd-ig. :( Ez utóbbi megálmodója is előbb tanulmányozhatta volna az AIX system leírását ODM segítségével. (Object Data Manager) Egy példa: Választhattad a hagyományos rc módu hálózati konfigurációt (ha elég hülye vagy hozzá), vagy a beépített normál módot. Az utóbbi így néz ki: /etc/methods/cfginet

Én ilyenről nem tudok, hogy Windows Console.

Ha elolvastad volna az

Írja

linket, akkor nem írtad volna ide a felét a cikknek. :-D

Most pedig a nevezéktan tisztázása után még azt is fogod érteni, hogy ki kivel van.

Értem, amit írsz, de nem értek egyet simán. A konzol az konzol, tényleg az a nyers, szöveges (vagy grafikus módban emulált szöveges) mód (esetleg fizikai teletype, írógép), amiben a kernel indul, és egyes modern grafikus, GUI only OS-eken akár hiányozhat is (Windows, MacOS). DOS-on valóban volt konzol, és ott volt értelme a CON: eszköznek is, Windowson már csak emulálva van, meg fenntartva a CON: eszköznévnek, hogy fájlt ne lehessen így hívni.

A konzol teljesen más, más üzemmódokon megy (BIOS/VGA text mode, vagy VESA közvelten grafikus mód), máshogy kezeli a karakterkódolásokat, másfajta fontokat használ, máshogy támogatja a színeket, egész más driverek, protokoll van mögötte. A terminálemulátor viszont megint teljesen más, szintén a felsorolt jellemzőkben.

Azzal sem értek egyet, hogy a konzol a számítógép nyúlványa, meg a shellel működne az OS. Modern OS-en nem férsz hozzá a géphez, hardverhez, azt mindenképp csak a kernel hajtja, és azzal működik az egész OS. A shell max. értelmezi a parancsaidat, segít elindítani binárisokat, értelmezi a shell scripteket, de nem azzal működik az OS.

Tisztában vagyok vele, hogy mi a chsh, az pont a user default login shelljét állítja be. Az csak egy bináris, hogy a shell is csak egy bináris, szigorúan nem is része az OS-nek, anélkül is működik, max. csak interakció nem lenne lehetséges nélküle. Igazából a helyzet még bonyolultabb, mert nem csak hogy külön van ez a user login shell, interaktív shell, script fejlécében hívott interpretes shell, hanem pl. pont a témánál maradva, ha valahová be SSH-zol, akkor a célgépen lévő default user login shell-t kapod (meg abból indítva a távoli/célgépen lévő binárisok indulnak, nem a helyiek), de az a helyi gépen futó terminálemulátorban fog pl. Windowson megjelenni.

El sem tudod képzelni, hogy ez mennyi embernek nem világos, sokszor fejlesztőknek, rendszergazdáknak, adminoknak se. Nem viccelek. Volt itt a HUP-on is pár téma, meg a Stackexchange is tele van vele, hogy kérdezik emberek, hogy hogyan állíthatnának be a „konzolban színeket”, aztán kiderül hosszas eszmecsere alapján, hogy egyrészt semmilyen konzolról nincs szó, hanem terminálemulátort használnak X-en futtatva, és igazából még csak nem is ezt akarják állítani, hanem a shell promptot akarják csinosítani, mert látták valahol, hogy milyen kafa cifrázásokat lehet csinálni vele, vagy egy TUI program témáját akarják állítani (pl. vim). Csak épp a keverés megy miatta.

Ennek ellenére lehetne úgy is definiálni, ahogy te határozod meg, hogy a konzol egy funkció legyen, és ráhúzható legyen a tty-ra, terminálemulátorra, stb., de az csak arra lenne jó, hogy még jobban összekeverjen mindenkit.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Értem, amit írsz, de nem értek egyet simán. A konzol az konzol, tényleg az a nyers, szöveges (vagy grafikus módban emulált szöveges) mód...

A rossebeket érted! Olvasd el mégegyszer, amit írtam! (konzol == funkció) Hogy jön ide az emulált, szöveges, stb.? És ha fájlba irányítod? (El sem olvastad a chcons linket.) A grafikus rendszereken is van konzol funkció. A CON device a DOS kompatibilitás miatt maradt fenn. Pont olyan, mint: /dev/tty0 -> /dev /console. Ha mélyebbre ásol, akkor a UNIX kompatibilitás miatt lett a DOS-ban. :-D

Én: A console (konzol) nem más, mint amivel a számítógépet (akármit) irányítjuk vagy kommunikálunk vele vagy megfigyeljük.

Linus:  The system console is the device which receives all kernel messages and warnings and which allows logins in single user mode.

AIX: The /dev/console special file provides access to the device or file designated as the system console. ... The system console is typically a terminal or display located near the system unit. It has two functions in the operating system. First, it provides access to the system when it is operating in a non-multiuser mode. ... Second, the system console displays messages for system errors and other problems requiring intervention.

Abszolút nem látok ellentmondást a három meghatározás között. (Nem írtam, hogy a megvalósítás módja device, de hát mákosrétes mégsem lehet. :-D) Ha eddig megvan a dolog, akkor a konzolt oda irányítod, ahova csak jólesik - akár sehova. (/dev/null) Ettől kezdve bármelyik (fejlett, grafikus) rendszernek van konzola. Pl. MacOS, Windows Recovery Console. Annyiban szélesítettem a definíciót, hogy az app console is idetartozik, meg a HMC is. (Hardware Management Console és az utódjai). Az utóbbi Egy POWER szervernek van, ahol magán a szerveren fut a supervisor és a virtuális gépek. Ezen kívül van egy szervizprocesszora is, amelynek a konzolán pl. diszk vagy hálózati kártya cserét tudsz menedzselni. A csereberét a szervizprocesszor megdumálja a supervisorral, az az alatta futó rendszerekkel.

Tehát a konzol az konzol, de már megint nem mondtam meg, hogy hova van kötve vagy irányítva.

Használtunk úgy AIX szervereket, hogy a fizikai konzol soros terminál, de úgy is, hogy X terminál volt - alfanumerikus módban. A funkció ugyanaz, de a csatlakozás módja, a csatlakoztatott hardver és az emuláció más. Ha az utóbbin userként jelentkezel be, akkor indul a grafikus terminál és mint nem root tudsz dolgozni rajta. Ez összekever mindenkit?

...shell max. értelmezi a parancsaidat, segít elindítani binárisokat, értelmezi a shell scripteket, de nem azzal működik az OS.

Tehát van az operációs rendszer és vannak benne fájlok.

Úgy 30 évvel ezelőtt a *nix operációs rendszerekben a programok 70 százaléka script volt.

Ez csak akkor nem világos, ha elolvasol 17 különböző témáról szóló mondatot és másfél mondatban összegyúrod a diszjunkt állításokat. Senki sem mondta, hogy "shellel működne az OS". Van olyan linux is, ami kernel+(initrd+busybox) = 2 db fájl, bár az initrd diszk is, amin további dolgok is lehetnek. Ezzel szemben egy több ezer fájlból álló rendszerről beszéltem, ahol a programok 70%-a shell script. Ezek a programok az operációs rendszer részei, nem elválaszthatók tőle. A script futtatásához shell szükséges. Ilyen parancs pl. a chlv, ami shell script és az operációs rendszer része. Mégpedig ksh kell a futtatásához, mert arra írták. Ezt azért írtam le, mert egy másik topicban is írta veterán huptársunk: CURRENT_YEAR-ben, normal rendszeren (<32MB RAM-mal rendelkezo beagyazott eszkozoket kiveve) mi ertelme van bash helyett mast hasznalni? - Ezért válaszoltam rá: Értelme nem sok. Tán csak annyi, hogy működjön az operációs rendszer. Ezek szerint néhányan azt se tudják hogyan épül fel egy rendszer. :( Persze a tökös linuxos lecseréli az AIX default shell-t is bash-ra, mert annak van értelme. (Vagy mert mást nem ismer.)

Tudod azért látom kicsit világosabban a dolgokat, mert DOS - SCO - linux - közel 20 év AIX tapasztalat alatt, 10 év AIX után kezdtem a Windows lelkivilágával foglalkozni. Nem (csak) a zagyvasággal szembesültem, hanem gyakran felismertem a már régóta használt sémákat.

pl. pont a témánál maradva, ha valahová be SSH-zol, akkor a célgépen lévő default user login shell-t kapod...

Ez tévedés

  • beállíthatok az userhez másik shellt
  • beállíthatok semmit
  • megtilthatom, hogy shellt indítson
  • az ssh-nak is megtilthatom, hogy shellt indítson
  • megtilthatom, hogy terminált rendeljen hozzá
  • az ssh-nak is megtilthatom, hogy terminált rendeljen hozzá
  • ...

Ha egyszer valami valahogyan működött, attól még nem az az egyetlen és helyes módja a működésnek.

El sem tudod képzelni, hogy ez mennyi embernek nem világos, sokszor fejlesztőknek, rendszergazdáknak, adminoknak se. ...

De, elbírom. :-D

Lusták és érdektelenek "a szakemberek" vagy csak kedvez a világ a felületes ismereteknek. Történetesen írtam és javítottam néhány terminfót, 100+ ember dolgozott rajta. A terminálok egy részét én programoztam (Wyse60) 16k EPROM-ból BIOS extension-ként futott, de DOS parancssorban is működött, a többi IBM 3153 volt. A terminálok DEC terminál szervereken keresztül AIX clusterre kapcsolódtak. Az input 8, míg az otput csak 6 transzláción ment keresztül. (ESC, repülőékezet, karakter kódolás, stb.) Megcsináltam a Dataflex fejlesztői környezetet színes-szagos módban, ami egy lényegtelen billentyű híján pont úgy viselkedett, mintha pécén fejlesztenél.

Úgy vélem, nem túl sok újdonság maradt a számomra a terminálokkal kapcsolatban. ;)

Windowson grafikus terminál van csak. A Vista óta nincs text módú konzol a Windowsokban.

Megnéztem a Wikipedián, ott is azt írják, hogy a Windows Terminal tudja a truecolort. Így hallottam a ThioJoe csatornáján is a YouTube-on. Ennek ellenére lehet kamu infó, de kötve hinném, igaz én magam nem próbáltam még. Azt nem tudom, hogy állítani kell-e hozzá, terminfo-t mókolni, vagy alapból tudja. Windows alatt én cmd.exe-t használok, abban a neovim konkrétan hibátlanul megy. Mást még nem próbáltam, ilyen bottom és többiek. Fel tudnám telepíteni oda a Windows Terminalt, de nem érdekel, ritkán használok Windowst, akkor is csak offline játékkonzolnak, így nem spécizem fel a rendszert extrákkal. Terminálozni ott van fő rendszerként a rendes Linux, azon mind az Alacritty (ezt egy ideje dobtam), mind az st (suckless-féle simple terminal) és xterm tudja a truecolor-t is (xterm-be nemrég implementálták, sokáig csak 256 színt tudott), még ha a terminfo és a TERM változó szerint csak st-256color és xterm-256color a terminál neve.

A rendes truecolor terminál egyébként nem attól truecolor, hogy a palettát állítgatod, hanem rendesen ANSI escape szekvenciaként nem csak egy 1 bájtos színkódot tudsz elküldeni az előttérre, háttér színére, hanem mindkettőre komplett R/G/B értéket, amik egyenként egy bájtosak (ez lehet 0x00-0xFF hexa érték vagy decimális 0-255), így összesen 24 bit, és 16,7 millió szín, és ezeket meg is jeleníti.

“The world runs on Excel spreadsheets.” (Dylan Beattie)