Et dans mon humble expérience, les rares fois où l'on est réduit à Vi brut de décoffrage en rescue mode, on arrive toujours à se démerder. (“Hé m***e c'est vrai y'a plus de :split ici”).
Je comprend, par contre ca me conforte dans l'idée que :x est plus intéréssant dans beaucoup de cas de figure.
L'edition simple d'une part, et de l'autre, on evite la demande de confirmation.
Merci pour les explications en tout cas :)
« Ce genre de tutorial ne sert à rien […] Quand je dois manipuler des gros fichiers, j’utilise d’autres moyens comme un IDE. » -> Les tutos plus lourds servent justement à utiliser Vi(m) comme un IDE =)
Après chacun a son usage, connaître juste les bases c'est bien aussi, par exemple pour pouvoir se démerder sur n'importe quelle station Unix de moins de 30 ans (puisque du coup c'est bien de Vi l'ancêtre qu'il s'agit je crois).
En relisant, je me dis que mon explication n'est peut être pas clair, du coup :)
“:x” ne sauvegarde que si le fichier a été modifié dans vi.
Donc dans l'exemple :
“:x” n'écrase pas le fichier, mais quitte simplement, comme “:q”.
“:wq” tentera d'écrire, et demandera une confirmation, puisque le fichier a été modifié hors vi entre temps.
Ya un timer sur le serveur du coup ça envoie une alerte avec les derniers logs envoyés par le client (processus, % d'utilisation du cpu, du cgu, users loggés…) s'il a pas reçu de notif depuis un certain temps :)
J'ai implémenté un algo de plus court chemin via la méthode de Dijkstra et celle de Bellman pour les cours, et je suis en train de créer un logiciel de visualisation de l'état de machines sous linux (le serveur est réalisé sous flask, première fois que je touche à un truc comme ça :D) et les sondes sont en bash et envoient les infos via wget. C'est rigolo :)
Hum; interessant ce point, donc, imaginions la chose suivante :
vi /var/log/syslog
[2min se passe … des lignes sont rajouté dans dans le syslog]
si à ce point là, je fais :x (ce qui biensur, est assez couillon, tout autant que le :wq) je n'aurais PAS les lignes rajoutées ?!
J'ai continué à bosser sur un site de vente de vidéos pégagogiques en ligne.
Et là depuis hier je migre toutes les machines du lycée privé de Saint-Hippolyte-du-Fort (un routerboard, deux serveurs, vingt postes clients) vers CentOS 7.
Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose.
(attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)
C'est le but de ce tuto : le minimum pour se démerder :)
Que dire de plus !?! Bravo
C'est fait :) Merci pour le soutien ;)
Ils se sont rendus compte qu'il y a pas vraiment de pare-feu dans OpenOffice, du coup ça les intéresse moins. :o)
Sinon, le meilleur formateur pour Vim, c'est Vim lui-même.
https://blog.microlinux.fr/vim/
Et dans mon humble expérience, les rares fois où l'on est réduit à Vi brut de décoffrage en rescue mode, on arrive toujours à se démerder. (“Hé m***e c'est vrai y'a plus de :split ici”).
Cet article mentionne cette association https://www.automotivelinux.org et la met sur le même pied d'égalité que la fondation Linux.
Lors du Fosdem 2017, j'avais découvert cette fondation très active autour de l'informatique embarquée dans l'automobile.
Voilà une piste pour lever un peu de tes doutes :-).
J'ai commencer a developer un jeu vidéo sur Unity3D ! C'est un jeu d'arcade en 2D. Le project avance bien :)
Je comprend, par contre ca me conforte dans l'idée que :x est plus intéréssant dans beaucoup de cas de figure. L'edition simple d'une part, et de l'autre, on evite la demande de confirmation. Merci pour les explications en tout cas :)
« Ce genre de tutorial ne sert à rien […] Quand je dois manipuler des gros fichiers, j’utilise d’autres moyens comme un IDE. » -> Les tutos plus lourds servent justement à utiliser Vi(m) comme un IDE =)
Après chacun a son usage, connaître juste les bases c'est bien aussi, par exemple pour pouvoir se démerder sur n'importe quelle station Unix de moins de 30 ans (puisque du coup c'est bien de Vi l'ancêtre qu'il s'agit je crois).
En relisant, je me dis que mon explication n'est peut être pas clair, du coup :) “:x” ne sauvegarde que si le fichier a été modifié dans vi.
Donc dans l'exemple : “:x” n'écrase pas le fichier, mais quitte simplement, comme “:q”. “:wq” tentera d'écrire, et demandera une confirmation, puisque le fichier a été modifié hors vi entre temps.
Ya un timer sur le serveur du coup ça envoie une alerte avec les derniers logs envoyés par le client (processus, % d'utilisation du cpu, du cgu, users loggés…) s'il a pas reçu de notif depuis un certain temps :)
Marrant de faire ça dans le sens Client => Serveur Et si le client n'est pas en capacité d'envoyer?
J'ai implémenté un algo de plus court chemin via la méthode de Dijkstra et celle de Bellman pour les cours, et je suis en train de créer un logiciel de visualisation de l'état de machines sous linux (le serveur est réalisé sous flask, première fois que je touche à un truc comme ça :D) et les sondes sont en bash et envoient les infos via wget. C'est rigolo :)
L'année du postes client Linux??
Hum; interessant ce point, donc, imaginions la chose suivante :
vi /var/log/syslog[2min se passe … des lignes sont rajouté dans dans le syslog] si à ce point là, je fais :x (ce qui biensur, est assez couillon, tout autant que le :wq) je n'aurais PAS les lignes rajoutées ?!
Il y a une très légère différence entre les deux : “:wq” sauvegarde, puis quitte. “:x” sauvegarde si le fichier a été modifié, puis quitte.
Dans le cas où le fichier a été modifié par une autre application entre temps, le résultat final sera différent ;)
plutôt les PCs sous Debian :)
c'est bon ça !
J'ai continué à bosser sur un site de vente de vidéos pégagogiques en ligne.
Et là depuis hier je migre toutes les machines du lycée privé de Saint-Hippolyte-du-Fort (un routerboard, deux serveurs, vingt postes clients) vers CentOS 7.
Est-ce bien compatible VI (et non VIM) ?
Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose. (attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)