Quel répertoire pour les exécutables en espace utilisateur ?

Support Debian
#1

Je souhaite installer des exécutables en espace utilisateur (userspace), principalement des outils qui ne sont pas proposés sous forme de paquet debian.

J’ai un peu cherché sur internet et je vois qu’il existe 2 répertoires destinés à cet usage :

  • ~/bin
  • ~/.local/bin

Mais en essayant les 2 répertoires, je constate qu’aucun des deux n’est automatiquement intégré dans le PATH.

Un bug debian 820856 maintenant corrigé indique qu’avec bash 4.3, seul ~/bin était ajouté automatiquement au PATH, mais qu’avec bash en version ultérieur les deux répertoires sont maintenant automatiquement ajoutés au PATH.

Utilisant debian stretch, avec bash 4.4.12, je constate que le bug est toujours présent.

Est-ce que j’ai loupé un truc ou bien est-ce que vous faites le même constat que moi ?

#2

Pour ma part, c’est ~/bin

vim .bashrc

tu rajoute ceci pour ton utilisateur.

PATH="$HOME/bin:$PATH"
#3

Débat : vaut-il mieux ajouter le chemin vers ~/bin au début ou à la fin de $PATH ?

#4

Salut

dans mon .profile je vois ça:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
#5

Ta methode est la meilleure, elle s’applique à tous le monde.

#6

Tant que ça fonctionne, je me pose pas de question.

#7

je n’y suis pour rien, c’est dans le paquet bash

cat /etc/skel/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

apt list bash
En train de lister... Fait
bash/testing,stable,now 4.4-5 amd64  [installé]
#8

Même .profile dans jessie…

Si ~/bin est bien présent alors @ploc n’aurait pas dû rencontrer de problème.

#9

oui si on veut y mettre un binaire

mkdir ~/bin

est conseillé :grinning:

#10

Oui par defaut le bin n’est pas présent.

Peut etre préciser qu’il faut se délogguer pour que ça fonctionne

#11

Justement, si tu mets un exécutable de même nom qu’un exécutable qui existe dans un répertoire système le résultat n’est pas le même.

#12

Je vais mettre un script shell appelé cd dans le ~/bin d’un collègue, après m’être assuré que ~/bin est bien en première place dans $PATH. Le contenu du script sera : rm -rf $1
Je vous tiens au courant :innocent:

EDIT: ah mince, ça doit pas fonctionner avec les commandes built-in de bash

#13

Depuis des lustres je mets mes scripts dans /usr/local/bin/, et des programmes non Debian dans /opt/
Mais je suis seul utilisateur.

Dans une debian partagée, je pense qu’un répertoire ~/bin/ est logique, l’idée étant de reproduire pour ce seul utilisateur l’arborescence générale dans ~/ (idem pour les man, lib…)
Pour les fichiers de configuration dans /etc/ , l’usage est souvent de faire ~/.nomdecommande.cfg ou ~/.rep/ (comme c’est fait pour .bashrc, ou .vim/)

Bien entendu il faut que ces chemins soient dans .bashrc ou .profile

Par exemple, pour avoir une distribution TexLive à jour au lieu de celle de Jessie, mon fichier ~/.bashrc se termine par ces lignes:

# Pour LaTeX TexLive local
PATH="/usr/local/texlive/texmf-local/bin/x86_64-linux:${PATH}"
export PATH
#TODO# Création de 2 variables PATH invisibles du shell.
INFOPATH="/usr/local/texlive/texmf-local/texmf-dist/doc/info:${INFOPATH}"
export INFOPATH
MANPATH="/usr/local/texlive/texmf-local/texmf-dist/doc/man:${MANPATH}"
export MANPATH

ainsi, le premier chemin exploré est celui de /usr/local/texlive/texmf-local/, (le premier dans la définition de PATH), et donc celui qui est choisi.

#14

Je cherchais une solution out-of-the-box. Mais pour le moment, je fais comme toi !

#15

Vous avez raison, mes tests devaient être foireux. Merci à @grandtoubab pour avoir cité le fichier adéquat.

SI je crée ~/bin/ et que je place mes exécutables dedans, ça fonctionne (il suffit d’ouvrir un nouveau terminal pour le constater).

#16

@Sputnik93 a raison. L’ordre des paths dans la variable PATH a une importance capitale.

Si on met ~/bin/ avant le reste, cela signifie qu’il sera possible de surcharger le comportement des exécutables systèmes par des exécutables perso. C’est peut être le but recherché, mais cela implique une vraie faille de sécurité.

Le plus sécurisé voudrait qu’on mette ~/bin/ à la fin pour être sûr de ne jamais surcharger les exécutables du système, et donc garder le niveau de sécurité du système à son maximum.

Mais ce qui m’inquiète, c’est justement le contenu du fichier .profile par défaut (tiré de /etc/skel/) : pour avoir adopté le principe que je considère comme le moins sécurisé ? (j’ai peut-être loupé quelque chose…)

1 J'aime
#17

En résumé, pour avoir des exécutables en espace utilisateur automatiquement intégrés au PATH, il suffit de créer un répertoire bin dans le home de l’utilisateur (soit dans /home/<user>/bin/ et d’y déplacer les exécutables.

mkdir ~/bin
chmod u+x myexe
mv myexe ~/bin/

Et voilà, c’est aussi simple que cela.

Et pour info, j’ai également testé cela sur Ubuntu, et bien Ubuntu intègre à son path aussi bien ~/bin que ~/.local/bin. L’avantage de ce dernier étant qu’il est caché, donc bien plus discret à l’usage.

Personnellement, je préfère me calquer sur le standard XDG et privilégier le répertoire ~/.local/bin/ quitte à devoir rajouter une ligne personnelle dans mon fichier .bashrc.

Le bug debian 839155 indique que bash 4.4.18-1 prend maintenant en compte le répertoire ~/.local/bin/ (en fait, il le prenait en compte par le passé, mais une régression est venue casser cette fonctionnalité). Actuellement, debian stretch propose bash 4.4-5.

#18

pas à la racine , mais dans le /home de l’utilisateur représenté par le caractère ~

#19

Toujours au début pour moi, vu que je me sers de ~/bin essentiellement pour modifier le comportement de certaines commandes. Un exemple tout bête :

dave@HAL9000:~$ cat ~/bin/heroes-chronicles-1
#!/bin/sh

killall conky
xrandr -s 800x600
conky -d
/usr/local/games/heroes-chronicles-1
killall conky
xrandr -s 0
conky -d

exit 0
#20

Petite rectification : “espace utilisateur” n’a pas du tout la signification que tu sembles lui donner. Au sein du système, l’exécution en espace utilisateur s’oppose à l’exécution en espace noyau. Bien évidemment, les instructions de tous les programmes exécutables “normaux” s’exécutent en espace utilisateur, par opposition au noyau et à ses modules.

Cf. https://fr.wikipedia.org/wiki/Espace_utilisateur