Discussion :

[glarance]

Bonjour,

Je ne connais pas le bash et j'ai une manip assez compliquée à faire.

il me faut renommer un fichier sur une machine linux puis transférer ce fichier sur une machine Windows
via scp avec une connexion ssh sans mot de passe.

A l'aide du net j'ai pu réaliser un petit script qui fonctionne pour le renommage avec tous les éléments dans le même dossier.
Mais je n'arrive pas à le faire fonctionner avec le script dans un dossier SCRIPTS, avec un dossier ARCHIVES dans lequel sera déplacé tous les fichiers après transfert sur la machine Windows.
et avec un dossier LOGS lequel sera créé puis mis à jour le fichier.

J'ai du mal avec les chemins d'accès à ces différents dossiers.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
# Renommer export avant transf
#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
# renxpt.bash # GG #
#!/bin/sh
# 
################################################ Création fichier log si absent
gdate=$(date +"%d/%m/%Y à %Hh%M")             # Récupération de la date et l'heure a laquelle le script est lancé
if [ ! -f logrename.txt ];                     # Vérifie si absence du fichier log
	then
		touch logrename.txt                    # Si absent créé le fichier
		echo $gdate  >> logrename.txt          #  et ajouter la date à laquelle le script est executé
	else
		echo $gdate >> logrename.txt           # Sinon si fichier de log présent ajouter la date
fi
################################################
 
################################################ Renommage fichier par suppression préfix 9 caractères (aaabbbccc)
for nom_fichier in aaabbbccc*_973.txt          # Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt
	do
		nouveau_nom_fichier=${nom_fichier//aaabbbccc/} # Attribution à la variable nouveau_nom_fichier la valeur de nom_fichier sans le préfix aaabbbccc
													   # Pour supprimer le prefixe aaabbbccc ne rien mettre comme valeur de remplacement
		mv $nom_fichier $nouveau_nom_fichier		   # Renommage
		echo $nouveau_nom_fichier "est renommé"   >> logrename.txt   # Ecrire dans le log le nom du fichier renommé
		mv $nouveau_nom_fichier ARCHIVES                 # Archivage du fichier renommé
		echo $nouveau_nom_fichier "est déplacé dans dossier ARCHIVES d'archivage" >> logrename.txt
	done
############################################################################################################################################################

[N_BaH]

Bonjour,

le if ne sert à rien, parce que touch ne sert à rien, et, finalement, c'est la même commande qui est exécutée, quel que soit le résultat du test.
touch ne sert à rien, parce que la redirection créera le fichier s'il n'existe pas.

quant aux fichiers (les répertoires sont des fichiers) il faut toujours indiquer leur chemin absolu depuis la racine du système de fichier (/).

et, un seul mv doit suffire : mv -v "$fichier" "$Destination/$nouveauFichier" >>"$log".
où l'on voit que les echo aussi sont inutiles.

sans oublier qu'il faut toujours mettre les Développements de paramètres entre guillemets. TOUJOURS! à moins de savoir pourquoi.

[Flodelarab]

Bonjour

Je ne vois aucune question dans le message initial.
Je ne vois pas la commande scp.

Bonne chance

[N_BaH]

et, au fait, /bin/sh n'est pas toujours un lien vers bash, et certaines commandes internes peuvent ne pas être reconnues.

[Flodelarab]

Le shebang n'est pas sur la première ligne.

[N_BaH]

c'est moi qui ai ajouté les balises [CODE]. Je ne sais pas si les commentaires qui précèdent le shebang sont dans le script.

[Jipété]

à moi :

#echo "$gdate" >> "$log/$ficlog"
c'est quoi ce gdate ?

# Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt situé dans le dossier $SOURCE

abc.txt pour faire tes premiers tests c'était trop simple et trop lisible ? Résultat tu nous décourages et il faut s'accrocher pour essayer de te comprendre.
En plus il n'y a rien dans source...

J'ai modifié ta boucle for en rajoutant trois témoins, qui permettent de voir que tu n'as rien dans tes dossiers, donc tu ne moveras rien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
for nom_fichier in "$source/$prefix"*.txt
do
echo "ici $nom_fichier"
	# Attribuer à la variable nouveau_nom_fichier la valeur de nom_fichier sans le préfix aaabbbccc
	nouveau_nom_fichier=`echo $nom_fichier | sed 's/$prefix//g'`;
	# Renommer fichier
echo "là $nouveau_nom_fichier"
echo "dernier $archive" 
	mv "$nouveau_nom_fichier" "$archive" >> "$log/$ficlog"
done

Sortie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ici /tmp/source/aabbbccc*.txt
là /tmp/source/aabbbccc*.txt
dernier /tmp/archive
mv: impossible d'évaluer '/tmp/source/aabbbccc*.txt': Aucun fichier ou dossier de ce type

Et ton message d'erreur montre simplement que tu as un nom de fichier mais pas le fichier.

[Sve@r]

à moi :

Un appel à l'aide ou un cri de courage?

En plus il n'y a rien dans source...

Euh... pour mes tests je me suis arrangé pour qu'il y ait des trucs => for i in $(seq 20); do touch "source/aaabbbccc$i.txt"; done

[jack-ft]

le if ne sert à rien, parce que touch ne sert à rien, et, finalement, c'est la même commande qui est exécutée, quel que soit le résultat du test.
touch ne sert à rien, parce que la redirection créera le fichier s'il n'existe pas.

[CHIPOTAGE]
bon, normalement, ici, on est censé être sur du linux avec un bon vieux bash...

Cependant, pour ceux qui travaillent dans un environnement légèrement différent (genre macos avec un zsh...), il peut arriver que le >> ne crée PAS le fichier s'il n'existe pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
% echo coucou >> /tmp/coucou
zsh: no such file or directory: /tmp/coucou

C'est pourquoi je ne suis pas surpris de voir quelque chose comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if [ ! -f logrename.txt ];                     # Vérifie si absence du fichier log
	then
		touch logrename.txt                    # Si absent, crée le fichier
		echo $gdate  >> logrename.txt          #  et ajoute la date à laquelle le script est exécuté
	else
		echo $gdate >> logrename.txt           # Sinon si fichier de log présent, alors ajoute la date
fi

que l'on peut évidemment factoriser en:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if [ ! -f logrename.txt ];                     # Vérifie si absence du fichier log
	then touch logrename.txt                    # Si absent, crée le fichier
fi
echo $gdate  >> logrename.txt          #  puis, dans tous les cas, ajoute la date à laquelle le script est exécuté

et que l'on peut aussi simplifier en:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
test ! -f logrename.txt && touch logrename.txt # Si absent, crée le fichier
echo $gdate  >> logrename.txt          #  puis, dans tous les cas, ajoute la date à laquelle le script est executé

voire, comme on va de toute façon écrire dedans:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
touch logrename.txt # Si absent, crée le fichier
echo $gdate  >> logrename.txt          #  puis, dans tous les cas, ajoute la date à laquelle le script est exécuté

[/CHIPOTAGE]

[CHIPOTAGE GRAMMATICAL]
Habituellement, par souci de cohérence de style et d'homogénéité, dans les documents techniques, le rédacteur choisit un style de description des actions parmi {1:nom, 2:verbe à l'infinitif, 3:verbe conjugué}.

Ici, glarance a la bonne idée de mettre des commentaires, mais il alterne allègrement entre les 3 styles (1:"Création...", "Récupération...", 2:"ajouter...", "Ecrire...", 3:"Vérifie...")...
Et je ne sais pas trop où placer le "créé"... L'on peut supposer qu'il pensait peut-être à 2:"créer"...

Mais je peux admettre que cela n'a guère d'incidence sur la qualité du code lui-même.
[/CHIPOTAGE GRAMMATICAL]

[Sve@r]

bon, normalement, ici, on est censé être sur du linux avec un bon vieux bash...

Comme le montre son shebang

Cependant, pour ceux qui travaillent dans un environnement légèrement différent (genre macos avec un zsh...), il peut arriver que le >> ne crée PAS le fichier s'il n'existe pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
% echo coucou >> /tmp/coucou
zsh: no such file or directory: /tmp/coucou

Je viens de tenter avec un zsh de Ubuntu (zsh v5.8.1) et la redirection a créé le fichier. Différences de version probablement...

Mais bon, de toute façon le shebang est justement fait pour gérer ce souci des utilisateurs qui travaillent dans des environnements différents. Ainsi quel que soit mon shell de travail, si j'exécute un script commençant par #!/bin/bash alors le process généré (tout appel de script ou programme génère un fils et le script ou programme est exécuté dans ledit fils) sera celui de /bin/bash. Et le script sera interprété par /bin/bash et non pas par mon shell perso.
Sans ça on n'aurait aucune possibilité de mutualisation.
Et donc le script en question doit être écrit dans une syntaxe compatible /bin/bash. Et même si pour toi en zsh la double redirection ne crée pas le fichier, elle le créera dans un script bash

Après personnellement le touch ne me dérange pas plus que ça. Ce n'est pas le plus gros souci actuellement.

[jack-ft]

Je viens de tenter avec un zsh de Ubuntu (zsh v5.8.1) et la redirection a créé le fichier. Différences de version probablement...

Différence de version ou de configuration, je dirais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
% \rm -f /tmp/coucou           
% set +o appendcreate      
% echo coucou >> /tmp/coucou
zsh: no such file or directory: /tmp/coucou
% set -o appendcreate       
% echo coucou >> /tmp/coucou
% cat /tmp/coucou           
coucou

[glarance]

Bonjour,

il y a 2 erreurs, une pour le fichier de log qui n'est pas reconnu et la seconde concerne le renommage qui semble être réalisé mais le fichier renommé n'est pas créé dans $ARCHIVE

$ ./renCATExp.sh
touch: cannot touch '/home/toto/log/logrename.txt': No such file or directory
./renCATExp.sh: line 22: /home/toto/log/logrename.txt: No such file or directory
mv: cannot stat '/home/toto/source/20220926154455_973.txt /home/toto/source/20221003123055_973.txt': No such file or directory.


une idée?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
#!/bin/bash
#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
# Renommer export avant transfert"
#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
# renCATExpt.bash V0.1# GG #
 
# Declaration variables
 
SCRIPT="/$HOME/scripts/"
SOURCE="$HOME/source/aaabbbccc*.txt"
ARCHIVE="$HOME/archive/"
LOG="$HOME/logrename.txt"
 
 
# Si absent, crée le fichier
#test ! -f "$LOG" && touch "$LOG" 
# puis, dans tous les cas, ajoute la date à laquelle le script est executé
#echo $gdate  >> "$LOG"         
 
 
# Renommer fichier par suppression préfix 9 caractères
# Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt situé dans le dossier $SOURCE
for nom_fichier in "$SOURCE"
do
# Attribuer à la variable nouveau_nom_fichier la valeur de nom_fichier sans le préfix aaabbbccc
nouveau_nom_fichier=`echo $nom_fichier|sed 's/aaabbbccc//g'`;
# Renommer fichier 
mv "$nouveau_nom_fichier" "$ARCHIVE" >> "$LOG"
 
# Transferer fichier vers machine windows
#scp "$ARCHIVE"/*.txt toto@winserv:/~
done

[binarygirl]

Plutôt que saupoudrer son code en mettant ça partout >> logrename.txt pour alimenter un log, on peut aller plus loin et tirer parti de la redirection de fichier sous Linux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#!/bin/bash
 
LOG_FILE="/tmp/test.log"
exec > >(tee -a "${LOG_FILE}") 2>&1
 
# ceci devrait apparaître dans la console et dans le fichier log:
echo "Hello world"

En gros, tout ce qui écrit dans la console sera aussi dans le fichier log. On peut aussi faire tourner son script dans une session GNU screen ou tmux pour logger l'output vers un fichier. Très pratique pour troubleshooter les tâches automatisées.

Pour ce qui est de renommer les fichiers en masse, on peut effectivement faire une boucle avec un find avec par exemple sed derrière pour virer le préfixe non désiré dans le nom du fichier, ou utiliser la commande rename (sous réserve que la distro le propose), le cas échéant avec une expression régulière.
Ce serait bien d'avoir 2-3 exemples de noms de fichiers.

Bon courage avec l'apprentissage du bash, les pièges ne manquent pas. Je recommanderais l'utilisation de shellcheck pour une validation a priori du script.

[Sve@r]

Bonjour

Je ne connais pas le bash

Il ne tient qu'à toi de l'apprendre.

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if [ ! -f logrename.txt ];                     # Vérifie si absence du fichier log
	then
		touch logrename.txt                    # Si absent créé le fichier
		echo $gdate  >> logrename.txt          #  et ajouter la date à laquelle le script est executé
	else
		echo $gdate >> logrename.txt           # Sinon si fichier de log présent ajouter la date
fi

Alors déjà tabuler le "then/else" sert totalement à que dalle. Déjà que parfois les lignes de code sont trop longues si en plus tu gaspilles 8 espaces pour rien...
Ensuite, même sans connaitre le bash, quand tu écris "si tel cas alors faire telle action et sinon alors faire la même action" tu ne te dis pas qu'il y a un truc à revoir? Sans déconner, ça te semble intelligent comme code???? En tout cas moi quand je vois ça je ne regarde même pas le reste.
Accessoirement [ -f fichier ] ne vérifie pas la présence ou l'absence du fichier mais si le fichier est ou n'est pas de type "f(ile)". Ce qui n'est pas tout à fait la même chose. [ -f /tmp ] && echo ok || echo bad affichera "bad" alors que "/tmp" existe.

J'ai du mal avec les chemins d'accès à ces différents dossiers.

Pareil, ça aussi ça s'apprend. Déjà la base c'est que le dossier de départ du job n'est pas le dossier dans lequel se trouve le script mais le dossier dans lequel tu te trouves toi quand tu appelles le script. Et ce n'est pas la même chose. Ensuite ben il faut connaitre ton arborescence.

quant aux fichiers il faut toujours indiquer leur chemin absolu depuis la racine du système de fichier

Ca je ne suis pas d'accord. Les chemins absolus ont des avantages, et aussi des inconvénients. Et les chemins relatits (s'ils existent c'est aussi pour qu'on les utilise) ont d'autres avantages et d'autres inconvénients. Chaque cas est différent du précédent et du suivant et certains cas seront mieux (ou plus facilement) codés si c'est en relatif.

[glarance]

Bonjour,
je ne sais ni coder ni programmer. Je profite d'un petit projet pour apprendre le bash d'ou ma demande.
J'ai tenté de suivre les indications mais là avec le chemin d'accès aux différents dossiers ça passe plus.

Il y a l'erreur

./renCATExp.sh: line 17: `"$SOURCE/$nom_fichier"': not a valid identifier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#!/bin/bash
################################################ Renommage fichier par suppression préfix 9 caractères
LOG=/home/toto/logrename.txt
ARCHIVE=/home/toto/archive
SOURCE=/home/toto/source/
 
for "$SOURCE/$nom-fichier" in aaabbbccc_*_973.txt          # Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt
	do
		nouveau_nom_fichier="${$SOURCE/nom_fichier//aaabbbccc/}" # Attribution à la variable nouveau_nom_fichier la valeur de nom_fichier sans le préfix aaabbbccc
 
		mv -v "$nom_fichier" "$ARCHIVE/$nouveau_nom_fichier" >> "$LOG"		   # Renommage. Nouvelle valeur prend ancienne valeur
	done

[Sve@r]

Il y a l'erreur

./renCATExp.sh: line 17: `"$SOURCE/$nom_fichier"': not a valid identifier

Pourquoi tu as écrit ceci sous forme de citation? On ne peut pas la récupérer directement !!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#!/bin/bash
################################################ Renommage fichier par suppression préfix 9 caractères
LOG=/home/toto/logrename.txt
ARCHIVE=/home/toto/archive
SOURCE=/home/toto/source/
 
for "$SOURCE/$nom-fichier" in aaabbbccc_*_973.txt          # Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt
	do
		nouveau_nom_fichier="${$SOURCE/nom_fichier//aaabbbccc/}" # Attribution à la variable nouveau_nom_fichier la valeur de nom_fichier sans le préfix aaabbbccc
 
		mv -v "$nom_fichier" "$ARCHIVE/$nouveau_nom_fichier" >> "$LOG"		   # Renommage. Nouvelle valeur prend ancienne valeur
	done

Alors

• dans l'erreur tu cites "nom_fichier" mais dans ton code ta variable se nomme "nom-fichier"
• les noms de variables ne peuvent pas contenir de tiret
• tu ne sembles pas avoir bien saisi le sens d'écriture de la boucle for variable in liste_de_valeurs. J'arrive à peu près à comprendre l'idée de for "$SOURCE/$nom-fichier" in aaabbbccc_*_973.txt mais le shell, lui, en sera incapable. Peut-être que si j'écris ce commentaire # Boucle pour rechercher tout fichier debutant avec aaabbbccc suivi de _973 et une extension .txt situé dans le dossier $SOURCE cela te permettra de mieux percevoir l'idée...
• "${$SOURCE/nom_fichier//aaabbbccc/}: "nom_fichier" ne représente pas la valeur de la variable mais une simple chaine "nom_fichier"
• tu as le droit d'utiliser tes propres variables d'environnement comme $HOME pour remplacer "/home/toto"

Et ma remarque sur la tabulation inutile du then/else vaut aussi pour le do/done

[Jipété]

Salut,

Accessoirement [ -f fichier ] ne vérifie pas la présence ou l'absence du fichier mais si le fichier est ou n'est pas de type "f(ile)".

Euh, t'es sûr de ton coup, là ?

Parce qu'en tapant help test au prompt d'une Debian 11.6 avec un bash 5.1.4, il me vient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

      -f FILE        True if file exists and is a regular file.

EDIT
Démo

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
[ -f /tmp ] && echo ok || echo bad 
bad
[ -f /tmp/bidon ] && echo ok || echo bad 
bad
touch /tmp/bidon
[ -f /tmp/bidon ] && echo ok || echo bad 
ok

Mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[ -d /tmp ] && echo ok || echo bad 
ok

Alors même si tout est fichier sous Linux, Bash est capable de faire la différence,
/EDIT

[Sve@r]

Euh, t'es sûr de ton coup, là ?

Oui

Parce qu'en tapant help test au prompt d'une Debian 11.6 avec un bash 5.1.4, il me vient
-f FILE True if file exists and is a regular file.

Quand je dis "ne vérifie pas la présence ou l'absence du fichier..." je sous-entend "n'est pas fait pour vérifier la présence ou l'absence". Il est évident que pour qu'un fichier soit de type "f", il doive exister au préalable. Ou (corollaire inverse) s'il n'existe pas alors il n'est pas de type f.
Le fait que test -f en arrive à vérifier la présence ou l'absence n'est qu'un effet de bord de sa vérification principale "est-il de type f".
Or le but de glarance étant de vérifier l'existence (ou plus précisément la "non existence") de ce fichier, ce test ! -f ne peut pas convenir. Parce que si le fichier existe dans un autre type, le test passera correctement mais le code plantera.

Démo

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[ -f /tmp/bidon ] && echo ok || echo bad 
bad

Ce qui se traduit "/tmp/bidon n'est pas de type f". Rien, absolument rien dans ce résultat ne te permet de dire si /tmp/bidon existe ou n'existe pas.
Après si tu veux, on peut le démontrer mathématiquement.
Démo: la règle booléenne pouvant amener l'expression [ -f /tmp/bidon ] && echo ok || echo bad à afficher "bad" est la suivante: (le fichier existe et n'est pas de type f) ou bien (le fichier n'existe pas et le reste n'a pas d'importance donc on peut y rajouter "et n'est pas de type f"). Cette expression mathématique se factorise en (le fichier existe ou le fichier n'existe pas) et n'est pas de type f. La partie gauche du "et" étant toujours vraie, cela se réduit en "vrai et le fichier n'est pas de type f". Or dans une expression "vrai et truc", le "vrai" disparait et il ne reste que "le fichier n'est pas de type f" et son existence ou sa non existence n'est plus vérifiable.

Alors même si tout est fichier sous Linux, Bash est capable de faire la différence,

Ben oui. Tout est fichier ok mais le fait demeure qu'il y a différents types de fichiers. Ce type étant stocké dans l'inode, il est récupérable/vérifiable.

Ouais ! Régler ces problèmes

Bien résumé (mais avoue qu'elle était facile...)

[N_BaH]

Ca je ne suis pas d'accord. Les chemins absolus ont des avantages, et aussi des inconvénients.

à part leur longueur, je ne vois pas....

Et les chemins relatits [...] ont d'autres avantages et d'autres inconvénients.

leur principal inconvénient, c'est d'être relatifs.

s'ils existent c'est aussi pour qu'on les utilise

ah, mais j'en utilise ! sur la ligne de commande jamais dans un script.

[Sve@r]

ah, mais j'en utilise ! sur la ligne de commande jamais dans un script.

Oui en fait tu as raison. Je viens de réfléchir que c'est idiot, désolé.
En fait je pensais à un script qui serait à la racine d'un projet et qui travaillerait sur les différents sous-dossiers du projet. Je le pensais donc faire travailler en relatif (ce qui permet ensuite de déplacer le projet ailleurs tout en gardant la cohérence du script) mais en fait non. Il travaillerait peut-être avec des chemins générés depuis sa propre position (en utilisant dirname "$0") mais ça resterait au final des chemins absolus. Paramétrés... mais absolus.