Notiz GNU nano 6.0: Open-Source-Editor blendet auf Wunsch die Titelleiste aus

[Spike Py]

Es gibt exakt zwei Usecases für einen Kommandozeileneditor:

• Config-Files schnell anfassen, dann reicht ein BENUTZBARER Kommandozeileneditor (aka Nano)
• Mehr machen, dann per SCP oder was sonst verfügbar ist die Datei in einem Editor mit vernünftiger GUI öffnen (Notepad++/Kate/Atom... you name it)

Wie du siehst, kommt in keinem Usecase Emacs (oder, Gott bewahre, vi(m)) vor

Ah doch, einer meiner Kollegen sein die mit vim rumprollen und deswegen für jedes config file ewig brauchen

VIM ist also nicht benutzbar weil .... DU ihn nicht benutzen kannst? Sorry aber das ist kein Argument für mich (eher ein Armutszeugnis, jedenfalls wenn du in meiner Operations-Abteilung wärst).

Schon mal eine Datei in einem Kubernetes-Container über SCP bearbeitet?

 

[LochinSocke]

Ich nutze auch Emacs, mir fehlt leider noch ein guter Editor. Wer kann mir sagen wie ich Nano installiere?

 

[bnoob]

sudo apt nano

Ergänzung (17. Dezember 2021)

Schon mal eine Datei in einem Kubernetes-Container über SCP bearbeitet?

Wenn du in Kubernetes mehr als config files anpasst hast DU ein Operations-Problem, nicht ich

 

[LochinSocke]

Aber Vi(m) kennen ist schon sinnvoll. Ich habe mit schmalbrüstigen Geräten zu tun wo BusyBox draufpasst. Kein Nano dabei.

 

[Spike Py]

sudo apt nano

Ergänzung (17. Dezember 2021)

Wenn du in Kubernetes mehr als config files anpasst hast DU ein Operations-Problem, nicht ich

Dann sagt dir sicher alpine etwas: kein nano dabei und container lässt man idealerweise auch nicht als root laufen

Klar könnmte ich auch bei jeder kleinen Änderung bei der Problemsuche den Container neu bauen, kostet halt nur sehr viel zeit. So kannnst du schnell eine Datei anpassen, config/code neu laden und wenns funzt im Code persistieren.

Aber zurück zu deiner Aussagen, nur weil dir kein sinnvolles Szenario einfällt und du vim nicht bedienen kannst, sollte jetzt niemand mehr vim verwenden?

Ich hab da ne tolle Idee: Schreib mal ein Distributoren an und erzähl ihnen sie brauchen vim nicht mehr auszuliefern, weil du hast rausgefunden das braucht niemand! Das spart denen ja auch Pflegeaufwand und so. Ich bin auf dier Antwort gespannt

 

[bnoob]

Dass wir irgendwelche Cases haben in denen im default image kein brauchbarer Editor dabei ist habe ich doch gar nicht bestritten

In Docker-Images die ich nicht selbst gebaut habe benutze ich auch einen Editor der halt da ist, was oft genug nur vi(m) ist, weil manche Devops-Leute den als... Verlängerung brauchen.

afaik ist aber in Alpine Linux im Barebones-Standard gar kein Editor drin, und ob ich jetzt

RUN ["apt-get", "-y", "install", "vim-tiny"]

oder

RUN ["apt-get", "-y", "install", "nano"]

in mein Dockerfile schreibe ist auch nicht von der Distro abhängig, außerdem sind beide im selben package repo (lasse mich aber gerne eines besseren belehren).

 

[Spike Py]

In Docker-Images die ich nicht selbst gebaut habe benutze ich auch einen Editor der halt da ist, was oft genug nur vi(m) ist, weil manche Devops-Leute den als... Verlängerung brauchen.

Sorry aber was ist das denn für ein Argumentations-Niveau? Ich dachte echt, dass das hier besser geht. Als hätte ein Entwickler ein bestimmtes Tool genutzt um seinen Schwanz zu kompensieren. Und dein Schwanz ist jetzt größer weil du nicht vim nutzt ja? Was für ein absurder Schwachsinn. (Mir ist auch durchaus bewusst, dass der Schwanz hier Symbolisch für "Skill" steht, ändert aber nix an der Tatsache).

afaik ist aber in Alpine Linux im Barebones-Standard gar kein Editor drin, und ob ich jetzt

falsche, führ mal folgendes aus: docker run --rm alpine which vi

 

[notnitro]

Ich benutze nano, weil es bequemer ist, und lese heraus, dass vi(m) Nutzer entweder steinalt sind und ihr verständliches Recht auf Gewohnheit ausüben wollen, oder einfach nur cool sein und auffallen wollen.

Und @ andere comments

Wow! That escalated quickly 😅

Natürlich ist Nano bequemer. U.a. weil die die Lernkurve deutlich geringer ist bzw. nicht vorhanden.

Weiter will ich nicht auf den Zug aufsteigen.

Aber frag egal welchen Sys Admin:
"Wenn nichts geht, vi geht (fast) immer"

 

[netzgestaltung]

eigentlich immer das erste nach einer git installation: automatischen editor von vi auf nano stellen. zur sicherheit mach ich aber lieber commit -m 'mein commit' ;-) ein textinput sollte eh reichen.

aber: jeder soll nutzen was er will. einfach genial, dass es so eine vielfalt gibt!

 

[bnoob]

falsche, führ mal folgendes aus: docker run --rm alpine which vi

I stand corrected

Für die Leute an den Rundfunkempfängern, das kommt raus

docker run --rm alpine which vi
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
59bf1c3509f3: Already exists
Digest: sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300
Status: Downloaded newer image for alpine:latest
/usr/bin/vi

 

[Vorgartenzwerg]

Frag doch mal Bill Joy, was es in den 70ern so an Editoren gab und wie es sich an den damaligen TTYs, VTxyz etc so gearbeitet hat. Dann weißt du, warum Damals gab es nur ed, Zeilenbasiert. Es gab keinen visual, nichts. Joy hatte dann die geniale Idee mit den 2 Modi. Damals natürlich auch etwas aus der Not heraus, aber das Konzept war so gut durchdacht, dass es auch im Jahr 2021 noch für viele das Nonplusultra ist. Bis elaboriertere Shells wie zsh, bash & co kamen, nutzte man auch bei der interaktiven shell gerne den vi mode (set -o vi), um zwischen command und insert zu switchen um in der History zu suchen etc.

Ich liebe solche Geschichten aus den Anfängen der UNIX Zeit. Einer meiner Favoriten ist die Entstehung von grep:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Ich finde die vim Modi auch genial. Wobei ich auf meinem Rechner eigentlich immer VSCode mit VIM Keybindings nehme.

 

[WillardBL]

Ihr Ungläubigen! Ihr Sünder! Es gibt nur einen wahren $EDITOR und der lautet:

Notepad

 

[mgutt]

Ohne ShellCheck von Visual Studio könnte ich gar nicht leben. Daher ist mein Liebling WinSCP + Visual Studio Code, auch wenn vim beim Bearbeiten von crontab oder innerhalb von Containern immer wieder in Nutzung ist. Die Konstellation hat auch den Vorteil, dass man lokal immer noch ein Backup von den Dateien hat. Muss man nicht den Host mit .bak Dateien vollmüllen. Und Copy & Paste geht auch leichter von der Hand, wie auch Dateien vergleichen.