Comment coder un chemin d'accès pour exécuter un script ou pour copier un fichier dans un dossier ?

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:

---

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 ############################################################################################################################################################

---

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. ;)

Bonjour :coucou:

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

Bonne chance :ccool:

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

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

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.

Bonjour

Citation:

---

Envoyé par glarance

Je ne connais pas le bash

---

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

Citation:

---

Envoyé par glarance

Code:

---

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.

Citation:

---

Envoyé par glarance

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.

Citation:

---

Envoyé par N_BaH

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.

Citation:

---

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:

---

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

---

Citation:

---

Envoyé par glarance

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 !!!

Citation:

---

Envoyé par glarance

Code:

---

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 :roll:

Citation:

---

Envoyé par N_BaH

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:

---

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:

---

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:

---

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:

---

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:

---

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]

Citation:

---

Envoyé par jack-ft

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

---

Comme le montre son shebang 8-)

Citation:

---

Envoyé par jack-ft

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:

---

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.

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:

---

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.

Citation:

---

Envoyé par Sve@r

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:

---

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

---

Salut,

Citation:

---

Envoyé par Sve@r

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

Citation:

---

Code:

---

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

---

---

EDIT
Démo

Code:

---

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:

---

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, :P
/EDIT
:zoubi:

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:

---

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

---

Citation:

---

Envoyé par glarance

une idée?

---

Ouais ! Régler ces problèmes :

Code:

---

1 2	touch: cannot touch '/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.

---

Et utilise la balise CODE, bon sang ! Celle avec le dièse # au bout de la 2^e ligne de boutons

Citation:

---

Code:

---

mv: cannot stat '/home/toto/source/20220926154455_973.txt /home/toto/source/20221003123055_973.txt': No such file or directory.

---

---

observe bien les apostrophes. Elles indiquent que la variable contient littéralement une seule entité composée des noms de deux fichiers.
c'est une mauvaise pratique d'effectuer le Développement des chemins dans une variable.
tu pourrais avoir

Code:

---

1 2 3 4 5 6

#!/bin/bash ... srcDir='/chemin/vers/dossierSource' motif='motifCherché' for f in "$srcDir/$motif"*.ext ...

---

PS: les noms de variables tout en majuscules sont, par conventions, réservés aux variables d'environnement (HOME, PWD...).

Citation:

---

Envoyé par Jipété

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

---

Oui ;)

Citation:

---

Envoyé par Jipété

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.

Citation:

---

Envoyé par Jipété

Démo

Code:

---

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.

Citation:

---

Envoyé par Jipété

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

---

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.

Citation:

---

Envoyé par Jipété

Ouais ! Régler ces problèmes

---

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

Citation:

---

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....:koi:

Citation:

---

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

---

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

Citation:

---

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

---

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

Citation:

---

Envoyé par N_BaH

ah, mais j'en utilise ! sur la ligne de commande :mrgreen: 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.