Pour en finir avec le bloc "corbeille"

Bien sûr :

shopt -s dotglob rm -rf "${HOME}/.local/share/Trash/"{files/,info/,metadata}* shopt -u dotglob
Les guillemets sont optionnels mais il ne doivent pas prendre la dernière partie (l’expression régulière qui génère l’ensemble des chemins), car ça empêcherais sont analyse et il tenterais de supprimer le fichier : ~/.local/share/Trash/{files/,info/,metadata}*

Non, je parlais de la totalité, jusu’à Trash/
variable="/home/ricardo/.local/share/Trash/"
de façon à faire ce que tu me demandes plus haut : le choix entre $XDG_DATA_HOME/Trash ou $HOME/.local/share/Trash.

EDIT :
si réponse $XDG_DATA_HOME/Trash = nul
test_xdg="/home/ricardo/.local/share/Trash/“
sinon
tes_xdg=”???/Trash
finsi

Je ne suius ptet pas très clair :unamused:

Ainsi, la ligne deviebndrait
rm -rf “$test_xdg”{files/,info/,metadata}*

[quote=“ricardo”]Ainsi, la ligne deviebndrait
rm -rf “$test_xdg”{files/,info/,metadata}*[/quote]
Tu peut très bien le faire, je n’ai juste pas voulu te donner d’exemple trop près de la solution.

On a une habitude les développeurs dans ce genre de cas à ne pas utiliser le else de la condition :

var=defaut
if test ; then
    var="autre valeur"
fi

Petite remarque en passant : en principe on évite de mettre le slash final dans les variables qui contiennent un chemin.

J’imagine que c’est entre autres pour une raison de clarté lorsqu’on utilise la variable plus tard, dans le premier cas on voit tout de suite qu’il s’agit d’un répertoire :

$HOME/fichier plutôt que ${HOME}fichier
Certaines commandes vont également se comporter différemment selon qu’il y a un slash final ou pas dans ta variable (répertoire lui-même, ou son contenu), et c’est beaucoup plus facile de le rajouter après coup quand il y a besoin, plutôt que de l’enlever !

De toutes façons quelle qu’en soit la raison exacte, c’est une convention qu’il vaut mieux respecter si tu veux que ton code soit lisible par d’autres. Étant donné que tu le publies sur le Wiki… Q.E.D. :wink:

Ce que je crois pouvoir traduire par :

chemin_trash="$HOME/.local/share/Trash"

if [ $XDG_DATA_HOME ] = “je ne sais pas comment écrire que ça répond quelque chose"
then
chemin_trash=”$XDG_DATA_HOME/Trash"
fi
"
"
"
rm -rf “${chemin_trash}”{files/,info/,metadata}*

???

Selon les spécifications Freedesktop (lien fourni par MisterFreez) il suffit de vérifier que la variable existe et n’est pas vide :

CORBEILLE="$HOME/.local/share/Trash" if [ ! -z "$XDG_DATA_HOME" ]; then CORBEILLE="$XDG_DATA_HOME/Trash" fi ... rm -rf "$CORBEILLE"/{files/,info/,metadata}*

Cela dit, j’aurais tendance à vérifier également que le répertoire existe :

CORBEILLE="$HOME/.local/share/Trash" if [ ! -z "$XDG_DATA_HOME" ] && [ -d "$XDG_DATA_HOME" ]; then CORBEILLE="$XDG_DATA_HOME/Trash" fi ... rm -rf "$CORBEILLE"/{files/,info/,metadata}*

Après quelques modifs perso, voilà ce que ça donne. Testé chez moi, ça fonctionne mais je ne peux pas tester dans le cas d’un $XDG_DATA_HOME/Trash.
Donc à vérifier si je n’ai pas fait de conneries.

[code]# Teste l’emplacement de la corbeille et si elle est pleine (présence de fichier(s) dans … /files). Si elle l’est, liste les fichiers qu’elle contient
echo -e “\033[4mCONTENU de la CORBEILLE\033[0m\n”

chemin_trash="$HOME/.local/share/Trash"

if [ ! -z “$XDG_DATA_HOME” ]
then
chemin_trash="$XDG_DATA_HOME/Trash"
fi

corbeille="$chemin_trash"/files

if [ -z $(ls -A "$corbeille") &> /dev/null ] 
then
	echo "LA CORBEILLE EST VIDE"		
else
	ls -a "$corbeille" 	
	read -p "on peut la vider  ? o/* : " vider	 
		if [ "$vider" = o ] 
		then	
			shopt -s dotglob
			rm -rf "$chemin_trash"/{files/,info/,metadata}*
			shopt -u dotglob
			echo "CORBEILLE VIDÉE"
		else
			echo -e "\033[4mCORBEILLE CONSERVÉE PLEINE\033[0m"
		fi		
fi 		

[/code]

Rien à redire juste deux petites modifications cosmétiques :

[code]# Teste l’emplacement de la corbeille et si elle est pleine (présence de fichier(s) dans … /files). Si elle l’est, liste les fichiers qu’elle contient
echo -e “\033[4mCONTENU de la CORBEILLE\033[0m\n”

chemin_trash="$HOME/.local/share/Trash"
[ ! -z “$XDG_DATA_HOME” ] && chemin_trash="$XDG_DATA_HOME/Trash"

plus court tu peut mettre (mais bon il manque tout de même l’opérateur ternaire …) :

[ -z “$XDG_DATA_HOME” ] || chemin_trash="$XDG_DATA_HOME/Trash"

ou alors avec un pseudo opérateur ternaire (attention pas d’espace après le ) :

[ -z “$XDG_DATA_HOME” ] && chemin_trash="$HOME/.local/share/Trash" \

|| chemin_trash="$XDG_DATA_HOME/Trash"

Bref comme tu le sens :slight_smile:

corbeille="$chemin_trash/files" # pour avoir les guillemets comme au dessus

if [ -z $(ls -A “$corbeille”) &> /dev/null ]
then
echo "LA CORBEILLE EST VIDE"
else
ls -a ~/.local/share/Trash/files
read -p "on peut la vider ? o/* : " vider
if [ “$vider” = o ]
then
shopt -s dotglob
rm -rf “$chemin_trash”/{files/,info/,metadata}*
shopt -u dotglob
echo "CORBEILLE VIDÉE"
else
echo -e "\033[4mCORBEILLE CONSERVÉE PLEINE\033[0m"
fi
fi [/code]

Je ne savais pas qu’on pouvait placer à la suite la variable et le reste du chemin : corbeille="$chemin_trash/files"
EDIT : je suis bête, c’est déjà le cas au desus :blush:

Pour le reste de tes propositions, je ne comprends pas ce qu’elles sont susceptibles de remplacer. Prenons, pour exemple la dernière :
[ -z “$XDG_DATA_HOME” ] && chemin_trash="$HOME/.local/share/Trash"
|| chemin_trash="$XDG_DATA_HOME/Trash"

Peux-tu me replacer ça dans le contexte, stp

syam a dit :[quote] les () lancent un sous-shell, c’est à dire un processus supplémentaire. C’est beaucoup plus lourd en ressources qu’en restant dans le même shell[/quote]Quand on utilise deux fois une commande externe (ls) au lieu d’un tableau, ça fait quoi ?

Si ça m’est adressé, enfin au script, sois gentil de le préciser car je suis assez “fermé” aux énigmes.

[quote=“Watael”]salut,

pour faire propre et concis en bash :

mdr !
sans avoir lu ce fil, j’ai ce que j’ai proposé dans l’ancien :wink:

Alors ricardo les 3 version que je présente sont :

chemin_trash="$HOME/.local/share/Trash" [ ! -z "$XDG_DATA_HOME" ] && chemin_trash="$XDG_DATA_HOME/Trash"
plus court tu peut mettre (mais bon il manque tout de même l’opérateur ternaire …) :

chemin_trash="$HOME/.local/share/Trash" [ -z "$XDG_DATA_HOME" ] || chemin_trash="$XDG_DATA_HOME/Trash"
ou alors avec un pseudo opérateur ternaire ([b]attention pas d’espace après le [/b]) :

[ -z "$XDG_DATA_HOME" ] && chemin_trash="$HOME/.local/share/Trash" \ || chemin_trash="$XDG_DATA_HOME/Trash"
Pour remplacer ceci :

[code]chemin_trash="$HOME/.local/share/Trash"

if [ ! -z “$XDG_DATA_HOME” ]
then
chemin_trash="$XDG_DATA_HOME/Trash"
fi[/code]

OK, là j’ai compris.
Tu dis de faire attention à l’absence de blanc après
J’en déduis que tout s’écrit sur une seule ligne, ça me fait bizarre, c’est pour “échapper” le ‘ou’ ?

[ -z “$XDG_DATA_HOME” ] && chemin_trash="$HOME/.local/share/Trash" || chemin_trash="$XDG_DATA_HOME/Trash"

Non c’est pour échapper le retour à la ligne.

Là, je comprends mieux
C’est pour mettre en exergue les deux possibilités
Tu écris si gros que ça ne tenait pas sur une même ligne :laughing:
Je vais le placer.

[code][ -z “$XDG_DATA_HOME” ] && chemin_trash="$HOME/.local/share/Trash" || chemin_trash="$XDG_DATA_HOME/Trash"

corbeille="$chemin_trash/files" [/code]

Une interrogation toutefois :
Pas de problèmes de fonctionnement, c’est OK,
mais on se sert sur la ligne suivante d’une variable créée en milieu de la commande du dessus.
Ce n’est pas très joli au niveau lecture pour celui qui découvre, non ?

Moi ça ne me choque pas …

C’est vrai qu’on n’est pas obligé de déclarer les variables préalablement en Bash.
Contrairement à ce qui se faisait en Pascal, si je me souviens encore ?

Oui, le pascal est un langage non permissif alors que le bash l’est.