macOS 12.3 n’est plus fourni avec nano, un éditeur de texte populaire pour le terminal
Apple continue de faire le ménage parmi les apps destinées au terminal et aux développeurs intégrées à macOS. Avec macOS Monterey, l’entreprise a retiré deux langage de développement qui étaient jusque-là fournis par défaut : PHP dès la première version, puis Python 2 avec macOS 12.3.
Comme prévu, macOS Monterey n’intègre plus PHP par défaut
Développement : Python 2 n’est plus fourni avec macOS 12.3
macOS 12.3 a aussi retiré une autre ressource, cette fois un éditeur de texte à utiliser dans le terminal : nano. Si vous n’avez jamais travaillé dans le terminal, vous ignorez peut-être qu’il faut tout faire sans interface graphique. Pour modifier des fichiers, il faut utiliser un éditeur de texte qui s’adapte au terminal, comme vi, emacs ou encore nano qui a gagné en popularité par sa plus grande simplicité d’utilisation. Apple l’intégrait jusque-là au système, mais il a désormais été remplacé par Pico, qui est en réalité l’ancêtre de nano.
On ne sait pas pourquoi Apple privilégie pico à nano, mais l’entreprise a quoi qu’il en soit fait le maximum pour éviter de casser les habitudes. Depuis le terminal de macOS 12.3, vous pouvez toujours utiliser la commande nano suivie du chemin du fichier à ouvrir et vous n’aurez pas d’erreur. Pico s’ouvrira à la place de nano et puisque ce dernier est un fork (clone qui a dérivé par la suite), vous ne serez pas dépaysé par son fonctionnement similaire, en particulier pour ses raccourcis clavier basés sur la touche ^ (control).
Néanmoins, nano est plus complet et surtout mieux maintenu, avec la dernière version qui date de février 2022 quand pico est resté bloqué en 2009. Selon vos besoins, la configuration par défaut de macOS peut vous suffire, mais vous pouvez aussi regretter nano pour l’une de ses fonctions supplémentaires, sa coloration syntaxique ou encore la traduction en français. Comme avec tous les outils en ligne de commande, réinstaller nano est facile, par exemple avec le gestionnaire de paquets Homebrew et la commande brew install nano.
Quant à savoir pourquoi Apple préfère pico à nano, la réponse est peut-être à chercher du côté de la licence de chaque outil, respectivement GPL et Apache. Cela fait des années maintenant que l’entreprise élimine tout ce qui relève de la licence GPL v3, jugée problématique suite à l’ajout de clauses strictes qui vont à l’encontre d’un système propriétaire comme l’est macOS.
Apple poursuit sa purge des logiciels sous licence GPL
En changeant la licence de CUPS, Apple poursuit sa purge anti-GPL
Le retrait de nano répond peut-être à cette problématique, tout comme le choix de zsh au détriment de bash pour les sessions de terminal par défaut de macOS, depuis Catalina :
macOS Catalina : zsh par défaut, Python et Ruby dépréciés
Il reste vi, donc tout va bien ;-)
@julien74
Si t’arrives a en sortir :p
C'est sûr que ça demande un peu d'apprentissage, mais ensuite on se rend vite compte que c'est bien plus puissant et pratique à utiliser.
Et éventuellement ça évite de se retrouver comme un con le jour où on se retrouve devant un Unix un peu dépouillé avec juste vi et sans possibilité d'installer autre chose (ah mes souvenirs de début de carrière...).
@idhem59
Je plussoie, c’était juste pour vanner :)
A l'école j'ai appris l'usage de vi et, très franchement, dès que j'ai un terminal unix, je n'utilise que lui (et je suis très sérieux). La dernière fois que j'ai eu affaire à pico j'ai tenté par tous les moyens de faire le 'ESC' ':q!" avec très peu de succès.
Habitude, quand tu nous tiens.....
@Seb du 95
Pareil, appris à l’école. Quand je suis sous nano je suis en stress…
@idhem59
Je suis tjrs épaté quand je vois que certains arrivent à en faire un ide très complet avec quelques plugins tout en restant pour le coup tellement léger
@radeon
Un IDE ? Carrément ?!
Un éditeur de code plutôt non ?
@joneskind
https://jcarpizo.github.io/vim-as-php-ide.html
@idhem59
« mais ensuite on se rend vite compte que c'est bien plus puissant et pratique à utiliser. »
Phrase maintes fois répétée par les barbus de la ligne de commande, mais jamais expliquée ni accompagnée d’exemples. Personnellement, c’est mon psychiatre qui adore vi pour toutes les séances que je dois prendre après chacune de ses utilisations…
Les macros, le support des regexp plus évolué je trouve, peut être scripté assez facilement, les trèèèèèèèèès nombreux raccourcis qui permettent de faire à peu près n'importe quelle manipulation sur un fichier en une seule frappe, son support du multi-document, etc.
Après c'est sûr que si tu en as besoin 3 fois dans l'année, tu seras perdu à chaque fois. Mais sur un usage quotidien, les habitudes viennent très rapidement et le gain de productivité est énorme quand on se retrouve à taper tous les raccourcis machinalement et à scripter des manipulations. Evidemment il faut avoir besoin de faire un peu plus que simplement taper ou modifier du texte pour que ce soit intéressant.
Et surtout, c'est le seul éditeur que tu es certain de trouver sur n'importe quel Unix. Donc c'est un peu le passage obligé quand c'est ton métier et que tu veux pouvoir manipuler des fichiers facilement quelque soit le contexte.
@idhem59
Haaa ! Enfin des arguments et pas le silence condescendant de ceux qui sachons !
Ok. Je comprends donc mieux, même si je reste persuadé que vi n’est pas un outil pour moi, notamment pour les raisons que vous invoquez…
Merci.
@ radeon : « Si t’arrives a en sortir :p »
Pas :p, :q. 😉
@BeePotato
C’est juste ^^
@radeon
C'est son prénom, c'est juste?
@Khrys
C’est ça c’est juste Leblanc 😂
@radeon
Ah bon il n’a pas de prénom?
@ BeePotato
> Pas :p, :q.
Si tu as des modifs que tu veux oublier, :q! 😜
Si tu veux les enregistrer, :wq
(Write Quit - en fait la plupart des lettres de commande a une signification et la connaître permet de s'en souvenir plus facilement. a = append, i = insert, b = before, e = end, etc.)
Edit : Un truc super cool de vi sur Mac (je ne sais pas ailleurs), c'est que quand tu est en mode "saisie de texte", tu peux faire un cmd-V pour coller du texte au point d'insertion.
@ marc_os : « Si tu as des modifs que tu veux oublier, :q! 😜
Si tu veux les enregistrer, :wq »
Ben oui, mais ça fait une blague tout de suite bien moins drôle. 😛
(Pour être clair : je faisais de l’humour, pas un cours sur vi.)
« Edit : Un truc super cool de vi sur Mac (je ne sais pas ailleurs), c'est que quand tu est en mode "saisie de texte", tu peux faire un cmd-V pour coller du texte au point d’insertion. »
En fait ça n’a rien à voir avec vi, ça vient juste du terminal — et c’est donc la même chose partout où on utilise comme terminal une application gérant le presse-papiers de l’OS.
D’ailleurs, juste pour chipoter : on n’a pas systématiquement droit à ce comportement sur Mac. En effet quand on démarre la machine en mode mono-utilisateur, un coup de ⌘+V ne mènera à rien. 😉
(Un peu comme quand on est sur la console d’un serveur Linux.)
@ BeePotato
> mais ça fait une blague tout de suite bien moins drôle
J'avoue humblement que je ne l'avais pas vue !
En prononçant ta réponse, évidemment...
@radeon
🤣🤣🤣
@julien74
Tout a fait, on fait tout avec vi, je l’utilise depuis 1988 (Domain OS sur Apollo)
@melaure
« Vi c’est la vie »
@ melaure
> Domain OS sur Apollo
Oh, quelqu'un qui connait les stations Apollo !
Dire qu'elles avaient un processeur de la famille des Motorola 68000... (si je me souviens bien)
A l'époque j'ai programmé en Common Lisp dessus avec un truc qui s'appelait KEE. Et découvert aussi Emacs, mais vi, c'était un incontournable.
Edit : Je me souvenais bien :
https://fr.wikipedia.org/wiki/Apollo_Computer
Je ne me rappelle plus de "Domain OS", mais ce que je me rappelle c'est que c'était une variante de BSD chez nous.
Ah oui, Aegis - lecture de l'article ;-)
On y faisait de la CAO pour la micro-électronique...
Article plus complet:
https://en.wikipedia.org/wiki/Apollo_Computer
Y a-t-il moyen de le remettre ?
Tout est indiqué dans l'article.
Hum, souvent très alarmistes, vos titres… « Pico remplace Nano, l’éditeur de texte populaire pour le terminal » ça serait plus juste, non?
Ce ne serait pas plus exact comme titre car pico a toujours été là, donc on ne peut pas dire qu'il vient remplacer nano.
Par contre je vous rejoins sur le côté excessivement alarmiste du titre, d'autant que les adeptes de nano, normalement, savent comment le réinstaller en quelques secondes (comme indiqué en fin d'article)
@r e m y
Pareil, je vois pas là. Le titre ne dit pas que macOS 12.3 n'est pas compatible avec nano, voire qu'Apple le supprime à distance sur tous les Mac ou que sais-je, juste qu'il n'est plus fourni avec le système…
@jerome74
Hein ? En quoi est-ce alarmiste de dire que nano n'est plus fourni avec macOS, ce qui est strictement factuel… 🤔 Il n'y a aucun jugement de valeur derrière.
@Nicolas Furno: c'est factuellement exact; pour autant, il y a un remplaçant qui est peut-être moins bien, mais qui le remplace de façon transparente dans bien des cas. Apple supprime souvent des trucs purement et simplement (au hasard, 32-bits, ou subversion) et là c'est une autre paire de manche pour les utilisateurs et/ou les développeurs.
@r e m y: si je ne dis pas de bêtises, avant macOS était fourni avec nano, puis pico l'a remplacé (la commande nano invoquant alos pico à la place), et maintenant c'est l'inverse.
On connaît très bien la raison du retrait de Nano. Il utilise depuis 2007 la licence GPL 3, et Apple se refuse à intégrer des logiciels open source utilisant celle-ci. C’est pour la même raison qu’Apple avait abandonné Samba avec OS X Lion. MacG en avait d’ailleurs parlé à l’époque : https://www.macg.co/2012/02/apple-poursuit-sa-purge-des-logiciels-sous-licence-gpl-57086
@SteamEdge
Et à nouveau dans cet article ! 🙃
@SteamEdge
j'allais l'ajouter.
> C’est pour la même raison qu’Apple avait abandonné Samba avec OS X Lion
A propos de Samba, font chier Apple de ne pas proposer netFS dans tvos.
@nicolasf ça m’apprendra à lire en diagonal 😅
encore une des énièmes décision agressive d'Apple.
A son lancement (jusqu'à au moins Tiger), MacOs était ULTRA pratique :
on déballait un mac et on avait un outil surpuissant : autant bureautique/loisir avec ilife (puis iwork) qu'Unix (python,perl, ruby, tout BSD , et du Gnu, etc)
De toute façon, je n'ai toujours pas avalé la suppression de samba pour en être resté à ce truc fait main par Apple stagnant et laissant encore le Mac à la marge de Windows. Les performances sont médiocres, et si on pousse son usage de manière intensive, rapidement on en atteint ses limites et bugs. HA ben faut bien les services de JAMF pour s'en sortir !
LEs gens disent "on s'en fout, pfiulalala"
chacun son truc, mais ce genre de décisions (et le tout soudé) est pourquoi je n'ai plus acheté de mac depuis 2013 même si en soi j'apprécie une informatique radicale et des machines soignées. C'est devenu trop chiant.
Windows est devenu PLUS FACILE pour y foutre de la Unixerie et de la gnuserie que MacOS ! (mais entre windows 11 et MacOs actuel, le contrôle par son éditeur est tel qu'on se demande qui en est le vrai utilisateur des fois...)
triste monde tragique.
@ oomu : « A son lancement (jusqu'à au moins Tiger), MacOs était ULTRA pratique :
on déballait un mac et on avait un outil surpuissant : autant bureautique/loisir avec ilife (puis iwork) qu'Unix (python,perl, ruby, tout BSD , et du Gnu, etc) »
Rappelons tout de même qu’au début, toute la partie avec les outils BSD était une installation optionnelle. On ne l’avait donc pas d’emblée en déballant un Mac. 😉
@oomu
"Windows est devenu PLUS FACILE pour y foutre de la Unixerie et de la gnuserie que MacOS ! "
Ouch... un peu de démagogie?
En quoi est-il compliqué d'installer aujourd'hui sur macOS n'importe quelle application Unix/Linux?
@oomu
Windows c’est bien le bac à sable pour s’entraîner à faire de l’escalade de privilèges c’est ça ?
@oomu
> « chacun son truc, mais ce genre de décisions (et le tout soudé) est pourquoi je n'ai plus acheté de mac depuis 2013 même si en soi j'apprécie une informatique radicale et des machines soignées. C'est devenu trop chiant. »
Merci, oomu !
Merci en mon nom aussi.
Merci d'expliquer pourquoi j'ai dû, moi aussi (comme tous les collègues de mon groupe, sauf les débutants), délaisser progressivement macOS pour continuer à bosser convenablement, avec les outils dont nous avons besoin. Puis dû renoncer au Mac comme machine de production, tout court. Après 35 ans de compagnonnage.
Comme vous le dites : c'est devenu trop chiant.
Finalement, la teneur comme la tonalité des réponses à votre post — et elles sont largement au-dessus de la moyenne — expliquent pourquoi ça fait des mois que je n'ai plus envie d'intervenir ici (sauf récemment, sur un sujet d'urgence : la sauvegarde des biens culturels numérisés en Ukraine) ; et plus le temps passe, moins ça me démange.
Portez-vous bien.
Tout n'est pas si noir mais je partage le ressenti !
Le M1 me semble être une belle révolution, mais je n suis pas attiré par l'enveloppe (encore que les MBP m1pro m'attirent bien plus que les précédent MBP, mais pas à la hauteur de mon premier MBP ou de mon iBook G3...)
Et puis j'en peux plus de la correction auto partout, de Mission Control et de la gestion absurde et aléatoire du plein écran. JE SUIS PLUS INTELLIGENT que la machine.
Personnellement j’ai toujours utilisé Vi. J’ai souvent installé less que je préférais à more et avec le couple less et Vi, roule ma poule.
Mais vu que MacOS est un système ouverts, on pourra remettre nano facilement.
Oui je sais le side-loading, c’est moche, dangeureux et je vais le regretter car Apple le dit…
Donc pour réinstaller nano il faut installer Homebrew. 🤪
@FrDakota
Pas du tout, on peut aussi télécharger le code source et compiler l’app. Il faudra les outils développement fournis avec Xcode mais c’est aussi le cas pour Homebrew en fait.
@ FrDakota
> il faut installer Homebrew
Je l'ai fait pour compiler des projets open-source, c'est pas la mer à boire non plus !
Installer homebrew pour installer un outil de ce genre, c'est pas trop compliqué c'est vrai, mais ça nécessite d'installer Xcode ou les command line tools, d'avoir du temps, et surtout énormément de place disque. Et le truc n'est installé que sur ta machine, pas possible de le copier sur une autre! Donc non, je vais pas bouffer 1 Go de SSD sur chaque machine à laquelle j'accède par SSH pour bidouiller des trucs avec nano.
@ jerome74
> Installer homebrew pour installer un outil de ce genre, c'est pas trop compliqué c'est vrai, mais ça nécessite d'installer Xcode
Ben euh... réflexe de développeur en effet.
Je n'ai quasiment jamais utilisé vi que dans ce cadre.
Ou pour bidouiller le fichier host.
En même temps, quand on graphiste (métier pris au hasard), nano, vi et consort et même le Terminal, ce n'est pas le pain quotidien !
J'utilise souvent nano et j'ai découvert vis (https://github.com/martanne/vis) que je m'efforce d'utiliser...
Sinon Vi reste incontournable (tout comme sed, grep, >> et autre | )
(Sous FreeBSD, j'utilise ee, vis et vi)
Pages