Forum général.cherche-logiciel Gestionnaire de shell persistant

Posté par  . Licence CC By‑SA.
Étiquettes :
1
10
jan.
2022

Salut,
Je cherche un utilitaire qui permettrai de mémoriser et restituer plusieurs session bash en parallèle.
En gros, un "xterm" correspondrai à un historique de commande, un ensemble de variable globales et un répertoire courant de travail.
J'ai regardé, de loin, Tmux et Srceen, je suis pas certain que ça réponde à mon besoin.
Dernier détail, quand je parle de persistance, c'est pour supporter les reboots intempestif de Win10, c'est pour un environnement cygwin.

Des conseils, des idées?

  • # Cas d'usage ?

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

    Ton besoin n'est pas très clair (mais je pense en effet que Tmux ou Screen n'est pas la bonne réponse), tu pourrais nous montrer comment tu utiliserais l'utilitaire idéal ? Ou nous expliquer concrètement à quoi ça te servirait ?

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

    • [^] # Re: Cas d'usage ?

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

      Mmmm… je crois que j'ai compris.

      1/ lancement du bash

      $ pwd
/home/moi
$ cd toto
$ pwd
/home/moi/toto
$ reboot

      2/ reboot

      3/ lancement bash

      $ pwd
/home/moi/toto

      C'est ça ?

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

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2. Dernière modification le 10 janvier 2022 à 10:19.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Cas d'usage ?

        Posté par  . Évalué à 2.

        C'est effectivement quelque chose comme cela, un rechargement automagique de toute les sessions précédente, un peu comme les sessions de Firefox après un reboot du navigateur.

        • [^] # Re: Cas d'usage ?

          Posté par  (Mastodon) . Évalué à 2. Dernière modification le 10 janvier 2022 à 11:11.

          Rien à ma connaissance, mais par contre tu dois pouvoir bidouiller un truc autour de PROMPT_COMMAND.

          Tu te fais une fonction Bash qui sauve tout dans un fichier, et ce sera automatiquement appelé après chaque commande que tu tapes.

          Au démarrage, dans ton .bashrc tu récupères ce fichier et tu te remets le contexte.

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

          • [^] # Re: Cas d'usage ?

            Posté par  . Évalué à 1.

            La solution suggérer par xenom (tmux et les plugins continnum/resurect) semble plus simple à mètre en place.
            Merci pour les réponses.

  • # virer win10 ?

    Posté par  . Évalué à 2.

    Ok, je sors …

    • [^] # Re: virer win10 ?

      Posté par  . Évalué à 1.

      c'est tentant, mais je fais de la cross compil pour FreeDos avec DJGPP au quotidien et la chaine en usage est sous cygwin…

  • # tmux ou screen avec les bonnes options ?

    Posté par  . Évalué à 2.

    tu ouvres un SSH sur ton serveur distant,
    tu lances tmux

    tu fais ce que tu as a faire
    ca coupe

    tu te reconnectes à ton serveur,
    tu lances tmux attach
    ca te remet sur la précédente session
    tu continues à travailler comme s'il n'y avait pas eu de coupure

    à voir avec les options de tmux pour ouvrir une session spécifique par exemple

    screen peut faire la meme chose, mais tmux a bien amélioré le principe.

    à l'époque avec screen, je faisais :
    screen -RdS mon_nom_de_session à l'ouverture
    et je refaisais la meme commande pour réouvrir la session si elle existe, en ouvrir une nouvelle si elle n'existe pas

  • # tmux continnum/resurect

    Posté par  . Évalué à 6.

    C'est possible de sauvegarder et restaurer des sessions avec tmux et les plugins tmux-continuum et tmux-resurrect
    D’après leur doc ça fonctionne aussi sous Cygwin.

    • [^] # Re: tmux continnum/resurect

      Posté par  . Évalué à 1.

      Merci pour cette réponse,
      Cette solution est en cours de test, car elle semble correspondre au besoin.
      Cordialement

  • # Je me posais la question

    Posté par  . Évalué à 3. Dernière modification le 10 janvier 2022 à 16:02.

    Il y'a une raison pour utiliser cygwin plutôt que WSL ?

    Car en terme de perfs et de comportement alternatif, cygwin c'est pas vraiment le top. J'avais fais des scripts (sous win 7) qui faisait des find | grep | sed -i… les perfs étaient vraiment pas au rendez-vous et il me semble qu'en plus le sed -i plantait et je devais passer par des fichiers intermédiaires.

    avec WSL, j'ai pas ces soucis là.

    Le seul intérêt que j'ai avec cygwin c'est la commande cygpath, et le fait qu'on puisse faire un cd "c:/machin/truc/bidule", c'est plus simple pour les chemins. Notes bien maintenant que j'y pense je pourrais faire un dossier WinDrive qui contient des liens symboliques vers le bon endroit (nommé évidemment c: d: … et l'ajouter au CDPATH.

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

    • [^] # Re: Je me posais la question

      Posté par  . Évalué à 1.

      Sauf erreur de ma part, c: est accessible automatiquement dans /mnt/ sous WSL (et probablement l'ensemble des disques locaux)

      Julien_c'est_bien (y'a pas que Seb)

      • [^] # Re: Je me posais la question

        Posté par  . Évalué à 3.

        Oui c'est ce qui me semble, mais le soucis c'est que le système cohabite avec windows, et que les chemins que te présente le système hôte c'est du c:\

        déjà remplacer les \ en / c'est pas pratique, mais ensuite faut changer le C: en /mnt/c.

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

    • [^] # Re: Je me posais la question

      Posté par  . Évalué à 2.

      C'est un choix historique,
      mon outil de travail principal, un cross-compilo pour freeDOS, a été fait dans un environnement cygwin 32Bits à l'époque de la migration vers des OS 64bits ne supportant plus l’exécution de programme DOS natif.
      Une migration est à envisager aujourd'hui, cygwin 3.3 est la dernière version à supporter le 32 bits. WSL sera peut-être testé à ce moment-là.

      • [^] # Re: Je me posais la question

        Posté par  . Évalué à 3.

        Je comprends tout à fait, je fais cohabiter aussi 2 systèmes pour la même raison car sous 7 j'avais fais mes scripts & alias pour compiler les script papyrus pour skyrim & fallout 4, et je les ai pas migrés;

        Note bien, je pourrais ne plus m'en servir vu que j'ai fait un .bat sur le bureau qui compile les fichiers qu'on lui dépose dessus et place les outputs dans le dossier parent du premier script passé en paramètre, mais les habitudes ont la vie dure et je continue de compiler vie cygwin ;)

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

Suivre le flux des commentaires

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