Forum Linux.général lancer un shell "vierge" dans un nouveau terminal

Posté par freem le 04 mai 2015 à 00:49. Licence CC By‑SA.

Étiquettes :

mai

2015

Bonjour.

Je cherche à lancer une nouvelle instance d'un émulateur de terminal, rxvt en l'occurrence, sans qu'il n'hérite de l'ensemble des variables définies par le terminal parent.
Le but, en fait, c'est de pouvoir lancer des shell dont la configuration serait spécifique à un projet (nombre de process pour compiler, emplacement des lib, définir le HOME en tant que dossier racine pour pouvoir y retourner d'un vulgaire cd, etc). Couplé avec un script pour générer un template qui correspond à mes goûts de dev, ça me ferait gagner un temps et un confort monstrueux. Je pourrai utiliser un IDE, mais je trouve les shell tellement plus puissants…

J'ai réussi à trouver un début de solution (env -i x-terminal-emulator -e bash), sauf que rxvt ne charge pas le fichier de configuration qui lui permet d'être présentable. Logique, $HOME n'étant pas préservée, il ne peut accéder à $HOME/.Xdefault…
Utiliser l'inverse (x-terminal-emulator -e env -i bash) ne fonctionne pas: la fenêtre s'affiche et se ferme immédiatement. Est-ce à cause d'un problème d'option non reconnue ou de bash qui se lancerait en mode non interactif? Aucune idée, j'ai pourtant bien essayé de grouper l'ensemble des paramètre dans des guillemets simples ou doubles, rien n'y fait!

Naturellement, placer simplement env -i dans un fichier utilisé ensuite avec --rcfile ne marche pas (env sert à lancer une commande, pas à nettoyer l'environnement…).

rxvt ne semble pas non plus avoir la possibilité de spécifier un fichier de configuration différent, ou alors j'ai raté la ligne dans son man très touffu, ou je l'ai lue mais mal comprise. C'est franchement étrange qu'il ne soit pas possible de définir un fichier de conf arbitraire, mais ça semble être ainsi…

# Peut-être qu'avec ça ...

Posté par totof2000 le 04 mai 2015 à 08:05. Évalué à 4. Dernière modification le 04 mai 2015 à 08:06.

d'après http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html

Invoked as an interactive login shell, or with --login

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
- [^] # Re: Peut-être qu'avec ça ...
  
  Posté par freem le 07 mai 2015 à 15:32. Évalué à 2.
  
  Le problème, c'est que ça ne supprime pas les variables. Le shell enfant hérite des variables de son parent, ces deux options permettent simplement de sauter les fichiers de configuration.
# BSD Owl, ton prochain système de build

Posté par Michaël (site web personnel) le 04 mai 2015 à 20:29. Évalué à 4. Dernière modification le 04 mai 2015 à 20:30.
As-tu essayé comme ça?
```
env -i HOME="${HOME}" x-terminal-emulator -e bash
```
Sinon, je remplacerais volontiers le bash par su - "${USER}" qui simule un nouveau login et utilise donc le bon shell.

Tu devrais regarder BSD Owl et sa fonction subshell:
```
% bmake subshell
===> Entering developper's subshell
…
```
Cela ouvre un shell pour le développeur qui fait une partie de ce que tu veux: le shell est attaché à la racine du projet et le macros make fournies dans BSD Owl s'en souviennent pour lire la configuration globale permanente dans Makefile.config — typiquement générée par ./configure — et les amendements locaux (i.e. non versionnés) et temporaires dans Makefile.local. Cela permet bien de définir les variables contrôlant le nombre de processus de compilation, etc…

Le but est bien d'ajouter une vision globale du projet au make typique qui se concentre sur les dossiers. Les fichiers que l'on écrit sont bien des simples Makefiles — c'est le but du projet: fournir un système de build solide qui se base sur un outil courant, make — la version BSD, pas GNU.

Tu peux regarder quelques exemples de projets (C, LaTeX, OCaml, shell) dans le dossier test. Pour prendre un projet complexe en C le fichier Makefile principal ressemble à:
```
PACKAGE= heat
VERSION= 0.1-current
OFFICER?= michipili@gmail.com
MODULE= langc.lib:librational
MODULE+= langc.lib:libfibonacci
MODULE+= langc.prog:goldenratio

.include "generic.project.mk"
```
qui indique deux bibliothèques et un programme les utilisant. Le fichier Makefile pour une bibliothèque ressemble à
```
LIBRARY= fibonacci
SRCS= fibonacci.h
SRCS+= fibonacci.c

.include "langc.lib.mk"
```
(Cela prépare même la page de man ! ☺)

Le fichier pour la compilation du programme est du même tonneau!

C'est porté sous Debian et Ubuntu (paquets non officiels mais il existent!), MacPorts et FreeBSD. J'espère que ça te plaira. Si tu as des questions n'hésite pas à me contacter sur le forum, l'issue tracker — ou par email si je ne réagit pas, il y a mon mail dans tous les fichiers ☺ — comme disent certains, c'est de la balounette en barre! ☺ Ça me fournirait un prétexte pour écrire des exemples plus détaillés pour le support du langage C — par exemple, et fermer les tickets correspondant!

Le projet Anvil est un exemple de petit projet utilisant ces macros.
- [^] # Re: BSD Owl, ton prochain système de build
  
  Posté par freem le 07 mai 2015 à 15:59. Évalué à 2.
  
  env -i HOME="${HOME}" x-terminal-emulator -e bash
  
  Comment ai-je pu ne pas penser à un truc aussi évident… Merci! Plus qu'a filer à bash les arguments pour spécifier quels fichiers de conf lire, et c'est nickel (trivial, bash à au moins un man clair).
  
  Tu devrais regarder BSD Owl et sa fonction subshell:
  
  Intéressant, j'y jetterai un œil, même si j'ai un mauvais apriori des Makefile. Ça pourra me filer des idées ou même me convaincre que finalement, «les Makefile,c'est trivial». Pointe d'humour, mais si je n'aime pas les makefile, c'est surtout que je les trouve illisibles. Sans parler du fait qu'il y ait une différence syntaxique entre les divers caractères blancs, c'est typiquement le genre de trucs qui me fait tiquer. Et la raison principale pour laquelle me suis pas encore essayé au python.
  
  la version BSD, pas GNU.
  
  Je ne savais pas qu'il y avait tant de différences que ça.
  
  Pour prendre un projet complexe en C le fichier Makefile principal ressemble à:
  
  Le pire, c'est que tu vas me convaincre… c'est bon ça! concis! lisible! maintenable (à première vue du moins)!! Bon, demain férié, rien à faire à part zoner sur le net ou coder, bah je pense que je vais tester. Sûrement tester ce soir aussi, pour le coup (je devrais être capable d'installer/tester netBSD sur une autre machine en même temps, ce que j'avais prévu comme programme pour la soirée héhé).
  - [^] # Re: BSD Owl, ton prochain système de build
    
    Posté par Michaël (site web personnel) le 07 mai 2015 à 18:20. Évalué à 2.
    
    Intéressant, j'y jetterai un œil, même si j'ai un mauvais apriori des Makefile
    
    Heu, et bien moi aussi… :D Make est très pertinents mais c'est assez bizarre comme façon de programmer par rapport au procédural du shell. En shell on décrit la grosse tache (Faruggia ou Chabat?) en termes de taches plus petites, mais en Makefile, tout est “local” on ne décrit que des petits traitements. Ce qui est important c'est qu'en Makefile on écrit un programme dont l'état est codé par le système de fichiers (pas le contenu des fichiers, mais plutôt les fichiers eux-mêmes).
    
    Sans parler du fait qu'il y ait une différence syntaxique entre les divers caractères blancs,
    
    Ce n'est pas très grave, tous les éditeurs sont au courant et puis aujourd'hui on sait qu'indenter le code avec des tabulations c'est mal, donc il n'y a pas trop de confusion possible. (Les TAB ça sert à créer des colonnes dans un tableau, indenter du code avec des TABs c'est comme créer un page vide à coups de RETURNs dans un traitement de texte.)
    
    Je ne savais pas qu'il y avait tant de différences que ça.
    
    Il y a des différences énaurmes: BSD est plus facile à programmer et mieux documenté, et il y a des examples de Makefiles complexes et lisibles.
    
    c'est bon ça! concis! lisible! maintenable (à première vue du moins)!
    
    Je te rassure, les macros derrière sont complètement illisibles. Ça reste de la programmation! :D Mais l'interface et propre, et c'est du Makefile donc c'est très facile à étendre avec des procédures personnelles – c'est l'intérêt d'utiliser make.
    - [^] # Re: BSD Owl, ton prochain système de build
      
      Posté par freem le 12 mai 2015 à 15:51. Évalué à 2.
      
      Je te rassure, les macros derrière sont complètement illisibles. Ça reste de la programmation!
      
      Des macros, surtout. Un inceste avec le C, peut-être? Faut que je trouve le temps de tester ton truc… toujours pas fait
  - [^] # Re: BSD Owl, ton prochain système de build
    
    Posté par Michaël (site web personnel) le 07 mai 2015 à 18:22. Évalué à 2.
    
    PS. N'hésite pas à poser des questions si tu en as pendant ton test!

Suivre le flux des commentaires

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