Loco.sh - programmez votre terminal comme un pro

Posté par  . Édité par Pierre Jarillon, palm123, Benoît Sibaud, Nÿco, gUI et volts. Modéré par Arkem. Licence CC By‑SA.
Étiquettes :
8
3
mai
2023
Administration système

Né de l'absence de solutions clés en mains et complètes pour la gestion de l'environnement utilisateur Unix (paquets, fonts, styles, scripts…), Loco.sh propose un framework bash complet pour coder son environnement, soit en YAML, soit en fichiers plats.

Loco.sh permet donc de centraliser la gestion :

  • des paquets (apt, snap, ppa, pip…)
  • des dotfiles (pour vim, zsh…)
  • du style (police, couleurs du term, fond d'écran)

Pour utiliser Loco.sh, c'est simple, facile et fourni avec des exemples.

Installation

Loco.sh est fourni avec plusieurs profils d'exemple (zsh, vim…) et peut s'installer en une commande :
Pour la version interactive :

bash <(echo https://bit.ly/l0c0-sh|(read l; wget -qO- $l 2>/dev/null || curl -L $l)); exit

Pour la version loco automatique (attention, écrase les dotfiles) :

bash <(echo https://bit.ly/l0c0-sh|(read l; wget -qO- $l 2>/dev/null || curl -L $l)) -Ya install -p full; exit

Titre de l'image

Comparaison de loco.sh avec les solutions de "configuration unifiée" existantes

Solutions d'orchestration comme Ansible

Loco.sh se distingue d'Ansible par son approche locale, si on peut installer un profil depuis une URL, la commande se passera depuis l'environnement local (contre un environnement distant préconfiguré à travers ssh avec Ansible). On pourrait imaginer utiliser Ansible pour installer loco.sh avec un profil orienté UX par exemple.

Loco.sh a très peu de dépendances (une obligatoire pour parser les fichiers YAML) et est écrit 100% en bash, ce qui le rend facilement maintenable et utilisable. L'installation d'un profil se fait en une seule ligne de commande.

OS avec solution intégrée comme NixOS ou guix

Si votre système supporte bash et expose ses propriétés à l'utilisateur (comme Gnome par exemple) vous pourrez créer un profil loco qui vous permettra de rejouer votre configuration (dans le cas d'une reinstallation ou d'un poste multi VMs).

Aller plus loin

  • # Sécurité de l'installation

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Bien sûr, curl|sh a toujours été dangereux mais, là, curl via le redirecteur d'URL lybien, c'est un record…

  • # echo | read

    Posté par  . Évalué à 5.

    Petite question, parce que je n'ai pensé à faire comme ça : quel-est l'avantage de echo|read l par rapport à l= ?

    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

    • [^] # Re: echo | read

      Posté par  (Mastodon) . Évalué à -1. Dernière modification le 03 mai 2023 à 11:00.

      C'est une tellement bonne question que même ChatGPT n'a pas la réponse :

      Q : Quel est l'intérêt en bash d'écrire "echo | read L" au lieu de simplement utiliser l'assignation de la variable L ?

      R : En Bash, la commande read permet de lire une entrée utilisateur depuis le clavier et de stocker la valeur dans une variable. La syntaxe générale de la commande read est la suivante :

      read [options] variable

      où variable est le nom de la variable dans laquelle stocker l'entrée utilisateur.

      Maintenant, pour répondre à votre question, l'utilisation de la commande echo | read L en Bash est un moyen de stocker une entrée utilisateur dans une variable sans avoir à taper quoi que ce soit. Cette technique peut être utile dans certaines situations, notamment lorsqu'il est nécessaire de stocker une valeur par défaut ou une valeur prédéfinie dans une variable sans avoir à interagir avec l'utilisateur.

      Cependant, il est important de noter que l'utilisation de echo | read L peut avoir des effets indésirables en fonction du contexte. Par exemple, si echo renvoie une sortie importante, elle pourrait écraser la valeur stockée dans la variable L. De plus, cette technique ne permet pas de gérer les erreurs de saisie de l'utilisateur.

      En général, il est préférable d'utiliser l'assignation directe de la variable dans la plupart des situations, car cela est plus simple, plus fiable et moins susceptible d'introduire des erreurs dans votre code.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: echo | read

        Posté par  (Mastodon) . Évalué à 7.

        Et d'une manière générale, echo c'est pas très gruik et pour éviter les surprises, c'est souvent mieux d'utiliser printf et de mieux controller sa sortie.

    • [^] # Re: echo | read

      Posté par  . Évalué à 8. Dernière modification le 03 mai 2023 à 16:10.

      faire un sous processus inutile ?
      pour avoir 'testé' la commande avec 

      l="urlALaCon";

      j'ai pas vu de différence notable (j'ai ajouté un echo devant chacune des commandes); cela pourrait avoir un sens pour "séparerer" et nommer est variables; et encore un 

      read un dos three <<<${trucASplif}

      fait bien le taf.

      De plus j'ajouterai que l, c'est un peut court, en plus d'être aisément confondu avec 1 et I; url aurait été plus pertinent bref le truc combiné au redirecteur d'url enchainé à une exécution direct dans bash (comme dit précédemment), ça fait pas super pro, et n'incite pas à la confiance.

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Ansible en local

    Posté par  . Évalué à 7.

    (contre un environnement distant préconfiguré à travers ssh avec Ansible)

    Ansible avec hosts: localhost et connection: local peut aussi se passer de ssh donc pas de différence a ce niveau.

  • # C'est fou !

    Posté par  . Évalué à 10. Dernière modification le 03 mai 2023 à 13:30.

    Personnellement, je considère que tous les projets qui veulent gérer l'environnement de l'utilisateur à sa place sont des projets un peu fous.
    Mais celui-là dépasse vraiment les bornes !

    (Oui, bah si tu ne sais pas que loco veut dire fou en espagnol, tu rates quelque chose.)

    L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès

    • [^] # Re: C'est fou !

      Posté par  . Évalué à 10. Dernière modification le 03 mai 2023 à 14:37.

      Mais malgré sa folie c'est un programme qui donne beaucoup d'entrain. Loco motive !

    • [^] # Encore un autre

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      (je l'ai su grâce à une chanson de Rick :-D)

      Ce que j'aurais apprécier, c'est une comparaison avec l'existant : (en vrac)
      - briefcase,
      - chezmoi,
      - Comtrya,
      - dfm,
      - divine-dotfiles (c'est du bash aussi et ça ressemble à du cdist),
      - dorothy (c'est essentiellement du shell),
      - dotbare (c'est du shell aussi),
      - dotbot,
      - dotbro,
      - dotdrop,
      - dotgit,
      - dotfiler,
      - dotfiles,
      - dotfiles (c'est du shell aussi),
      - dotfiles.sh (no comment),
      - Dotted,
      - dotly (c'est du shell aussi),
      - dotman,
      - dotsecrets,
      - dotsync (c'est du shell aussi et plus simple),
      - dfm,
      - dploy,
      - ellipsis (c'est du bash aussi),
      - ghar,
      - greatness,
      - GNU Stow,
      - hoard,
      - Homemaker,
      - home manager,
      - homesick,
      - jointhedots,
      - kody,
      - park,
      - Pearl,
      - pilgo,
      - punktf,
      - PSDotFiles,
      - rcm,
      - rotz,
      - strap (c'est du shell qui fait wrapper Ansible),
      - vcsh,
      - yadm,
      - etc. (ajoutez vos préférés)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Encore un autre

        Posté par  . Évalué à 3. 

        alias config='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'

      • [^] # Re: Encore un autre

        Posté par  (Mastodon) . Évalué à 5.

        (ajoutez vos préférés)

        Faudra que je documente le mien à l'occasion… bon c'est limité à un environnement Bash, mais par extension on peut faire tout le reste.

        Pour m'installer dans un nouvel environnement :

        scp -r <url_de_mon_site_perso>:.perso/ ~/

        Ensuite je peux exécuter un

        ~/.perso/install.sh

        Et zou! j'ai mon environnement Bash et mes dotfiles préférés qui s'installent.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Encore un autre

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Adepte aussi du script d'installation qui est interactif dans mon cas : selon le cas, je peux avoir besoin d'un outil/programme ou non (si pas besoin, faut pas bêtement l'installer —même si ça mange pas de pain, et si je l'installe, penser à récupérer la bonne conf que j'ai versionnée) <3
          Bon, si j'ai bien compris le README de loco.sh ça veut gérer divers profils aussi. J'ai rarement ce besoin mais je le gère avec des branches dédiées sur le gestionnaire de versions. :p

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Encore un autre

          Posté par  . Évalué à 2.

          Je trouve que c'est un peu embêtant pour les mises à jour personnellement.
          Je pensais me mettre justement à revoir ma façon de faire pour du ansible + git (+ git-crypt?) pour faire un git pull → ansible de manière automatique à la connexion de mes machines au réseau.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Encore un autre

            Posté par  (Mastodon) . Évalué à 3. Dernière modification le 05 mai 2023 à 10:26.

            Pour les mises à jour j'utilise rsync et mon bashrc custom me donne des alias perso_pull et perso_push

            J'étais parti sur rsync plutôt que git parce que rsync est une dépendance que j'ai estimé plus "simple" plus "courante" mais au final sur la plupart des systèmes tu n'as ni rsync ni git d'installés. Donc je devrais basculer sur git qui facilitera vraiment la gestion des mises à jours (version, conflits…)

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Encore un autre

              Posté par  . Évalué à 3.

              Je pensais surtout pour que ton script sois réentrant.
              Oui moi je vais installer git (et ansible du coup) quoi qu'il arrive et j'ai un nombre limité de machines, donc que ce soit un peu plus embêtant à initialiser ne m'embête pas vraiment.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Encore un autre

                Posté par  (Mastodon) . Évalué à 3.

                Je pensais surtout pour que ton script sois réentrant.

                Ça veut dire quoi "réentrant" ? Que je le relance à volonté et que ça permet la mise à jour ?

                En tous cas j'aime ce concept :)

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # mise en forme Markdown

    Posté par  (site web personnel) . Évalué à 4.

    c'est peu compliqué d'utiliser Markdown

    par exemple (oui, mots clés en bleu et affichage comme dans un terminal)

    bash <(echo https://bit.ly/l0c0-sh|(read l; wget -qO- $l 2>/dev/null || curl -L $l)); exit

    et là c'est la classe :p

    tout est référencé sur https://linuxfr.org/wiki/aide-edition

    pour les gens pressés c'est code avec coloration syntaxique pour améliorer vos nourjals :-)

  • # Corrections

    Posté par  . Évalué à 0.

    Bonjour à tou.s.tes,

    merci pour les très nombreux commentaires ! :)

    Pas de questions par rapport à Ansible qui est un produit d'industrialisation beaucoup plus complexe.

    J'ai modifié la redirection bit.ly par un redirect github pages avec un domaine custom en .dev. J'espère que c'est mieux en termes d'obfuscation.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.