Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Bonjour, Le 04/07/2018 16:58, UNIXAS9 a écrit :
Pourriez-vous s'il vous plaît m'expilquer en détails cette ligne :
Déjà, il y a au moins deux lignes non vides. Je suppose que la première ligne ne se termine pas par un « . », et du coup je vais concaténer cette ligne avec la suivante. Par ailleurs, les commandes cd et pwd sont en principe des builtins du shell, et du coup cela pourrait aider de savoir de quel shell il s'agit.
Allons-y par petits bouts, en supposant que le shell est un peu comme le bash.
command -v -- "$0"
Ceci récupère le nom complet du script dans lequel tu as trouvé ce code, et l'affiche sur la sortie standard. Mettons par exemple que c'est /foo/bar/le_script
"$(command -v -- "$0")"
« $(truc) » récupère la sortie standard de la commande truc et en fait un paramètre de ligne de commande (ou plusieurs s'il y a des blancs). « "$(truc)" » s'assure que le résultat sera UN seul paramètre et pas plusieurs. Particulièrement utile si le chemin vers le_script peut comporter des espaces. Dans l'exemple, ce sera "/foo/bar/le_script"
"$(dirname -- "[...]")"
Extrait le nom de répertoire où se trouve le fichier dont le nom est passé en paramètre. Je te passe l'explication du $(...) et des guillemets, c'est la même chose que précédemment. Dans l'exemple, on a donc "/foo/bar".
cd -P [...] && pwd -P
Je ne connaissais pas cette syntaxe, mais le man de bash m'indique que ça permet d'obtenir le vrai nom physique du répertoire, au lieu de liens symboliques. Par exemple, si /foo est un lien symbolique vers /usr/local, ça donnera /usr/local/bar
current_dir=$(...)
Met la chaîne /usr/local/bar dans la variable current_dir. C'est fait temporairement, juste le temps d'exécuter le reste de la commande, à savoir « . ${current_dir}/../outils.env »
. ${current_dir}/../outils.env
Lance le script ${current_dir}/../outils.env, c'est-à-dire le script /usr/local/outils.env dans notre exemple, mais en exécutant ses commandes dans le script courant au lieu de lancer un processus indépendant. Ça veut dire que si /usr/local/outils.env définit des variables ou des fonctions, elles seront visibles dans le script appelant.
checklogdir ${current_dir} 1
Ça je n'en sais rien. Peut-être que checklogdir est une fonction définie dans outils.env ? Soit dit en passant, il vaudrait mieux que ce script définisse aussi ${current_dir} s'il ne l'a pas été avant, parce que la ligne compliquée ne l'a *pas* défini (rappelle-toi, j'ai dit que c'était fait temporairement). Cordialement, -- Olivier Miakinen
Bonjour,
Le 04/07/2018 16:58, UNIXAS9 a écrit :
Pourriez-vous s'il vous plaît m'expilquer en détails cette ligne :
Déjà, il y a au moins deux lignes non vides. Je suppose que la première
ligne ne se termine pas par un « . », et du coup je vais concaténer
cette ligne avec la suivante.
Par ailleurs, les commandes cd et pwd sont en principe des builtins
du shell, et du coup cela pourrait aider de savoir de quel shell
il s'agit.
Allons-y par petits bouts, en supposant que le shell est un peu comme
le bash.
command -v -- "$0"
Ceci récupère le nom complet du script dans lequel tu as trouvé ce
code, et l'affiche sur la sortie standard.
Mettons par exemple que c'est /foo/bar/le_script
"$(command -v -- "$0")"
« $(truc) » récupère la sortie standard de la commande truc et en fait
un paramètre de ligne de commande (ou plusieurs s'il y a des blancs).
« "$(truc)" » s'assure que le résultat sera UN seul paramètre et pas
plusieurs. Particulièrement utile si le chemin vers le_script peut
comporter des espaces.
Dans l'exemple, ce sera "/foo/bar/le_script"
"$(dirname -- "[...]")"
Extrait le nom de répertoire où se trouve le fichier dont le nom est
passé en paramètre. Je te passe l'explication du $(...) et des
guillemets, c'est la même chose que précédemment.
Dans l'exemple, on a donc "/foo/bar".
cd -P [...] && pwd -P
Je ne connaissais pas cette syntaxe, mais le man de bash m'indique
que ça permet d'obtenir le vrai nom physique du répertoire, au lieu
de liens symboliques. Par exemple, si /foo est un lien symbolique
vers /usr/local, ça donnera /usr/local/bar
current_dir=$(...)
Met la chaîne /usr/local/bar dans la variable current_dir. C'est fait
temporairement, juste le temps d'exécuter le reste de la commande, à
savoir « . ${current_dir}/../outils.env »
. ${current_dir}/../outils.env
Lance le script ${current_dir}/../outils.env, c'est-à-dire le script
/usr/local/outils.env dans notre exemple, mais en exécutant ses
commandes dans le script courant au lieu de lancer un processus
indépendant. Ça veut dire que si /usr/local/outils.env définit des
variables ou des fonctions, elles seront visibles dans le script
appelant.
checklogdir ${current_dir} 1
Ça je n'en sais rien. Peut-être que checklogdir est une fonction
définie dans outils.env ? Soit dit en passant, il vaudrait mieux
que ce script définisse aussi ${current_dir} s'il ne l'a pas
été avant, parce que la ligne compliquée ne l'a *pas* défini
(rappelle-toi, j'ai dit que c'était fait temporairement).
Pourriez-vous s'il vous plaît m'expilquer en détails cette ligne :
Déjà, il y a au moins deux lignes non vides. Je suppose que la première ligne ne se termine pas par un « . », et du coup je vais concaténer cette ligne avec la suivante. Par ailleurs, les commandes cd et pwd sont en principe des builtins du shell, et du coup cela pourrait aider de savoir de quel shell il s'agit.
Allons-y par petits bouts, en supposant que le shell est un peu comme le bash.
command -v -- "$0"
Ceci récupère le nom complet du script dans lequel tu as trouvé ce code, et l'affiche sur la sortie standard. Mettons par exemple que c'est /foo/bar/le_script
"$(command -v -- "$0")"
« $(truc) » récupère la sortie standard de la commande truc et en fait un paramètre de ligne de commande (ou plusieurs s'il y a des blancs). « "$(truc)" » s'assure que le résultat sera UN seul paramètre et pas plusieurs. Particulièrement utile si le chemin vers le_script peut comporter des espaces. Dans l'exemple, ce sera "/foo/bar/le_script"
"$(dirname -- "[...]")"
Extrait le nom de répertoire où se trouve le fichier dont le nom est passé en paramètre. Je te passe l'explication du $(...) et des guillemets, c'est la même chose que précédemment. Dans l'exemple, on a donc "/foo/bar".
cd -P [...] && pwd -P
Je ne connaissais pas cette syntaxe, mais le man de bash m'indique que ça permet d'obtenir le vrai nom physique du répertoire, au lieu de liens symboliques. Par exemple, si /foo est un lien symbolique vers /usr/local, ça donnera /usr/local/bar
current_dir=$(...)
Met la chaîne /usr/local/bar dans la variable current_dir. C'est fait temporairement, juste le temps d'exécuter le reste de la commande, à savoir « . ${current_dir}/../outils.env »
. ${current_dir}/../outils.env
Lance le script ${current_dir}/../outils.env, c'est-à-dire le script /usr/local/outils.env dans notre exemple, mais en exécutant ses commandes dans le script courant au lieu de lancer un processus indépendant. Ça veut dire que si /usr/local/outils.env définit des variables ou des fonctions, elles seront visibles dans le script appelant.
checklogdir ${current_dir} 1
Ça je n'en sais rien. Peut-être que checklogdir est une fonction définie dans outils.env ? Soit dit en passant, il vaudrait mieux que ce script définisse aussi ${current_dir} s'il ne l'a pas été avant, parce que la ligne compliquée ne l'a *pas* défini (rappelle-toi, j'ai dit que c'était fait temporairement). Cordialement, -- Olivier Miakinen
Olivier Miakinen
Le 05/07/2018 00:49, je répondais à UNIXAS9 :
Par ailleurs, les commandes cd et pwd sont en principe des builtins du shell, et du coup cela pourrait aider de savoir de quel shell il s'agit.
Euh... j'ai l'habitude de lire le contenu des articles et pas leur titre (champ Subject), du coup je n'avais pas vu que le shell en question était le korn shell (ksh). Sachant cela, ce que j'ai écrit à propos de « command -v », « cd -P » et « pwd -P » semble correct puisque les pages man de bash et de ksh disent la même chose. Cordialement, -- Olivier Miakinen
Le 05/07/2018 00:49, je répondais à UNIXAS9 :
Par ailleurs, les commandes cd et pwd sont en principe des builtins
du shell, et du coup cela pourrait aider de savoir de quel shell
il s'agit.
Euh... j'ai l'habitude de lire le contenu des articles et pas leur
titre (champ Subject), du coup je n'avais pas vu que le shell en
question était le korn shell (ksh). Sachant cela, ce que j'ai écrit
à propos de « command -v », « cd -P » et « pwd -P » semble correct
puisque les pages man de bash et de ksh disent la même chose.
Par ailleurs, les commandes cd et pwd sont en principe des builtins du shell, et du coup cela pourrait aider de savoir de quel shell il s'agit.
Euh... j'ai l'habitude de lire le contenu des articles et pas leur titre (champ Subject), du coup je n'avais pas vu que le shell en question était le korn shell (ksh). Sachant cela, ce que j'ai écrit à propos de « command -v », « cd -P » et « pwd -P » semble correct puisque les pages man de bash et de ksh disent la même chose. Cordialement, -- Olivier Miakinen
