zsh et fonctions

Salut otut le monde,

Je n'ai pas vu de discussion sur le sujet, pourtant il doit bien y en avoir - je ne suis tout de même pas tout seul à ne pas comprendre ! ... si ? - Bref, désolé si ça fait doublon, mais voici le soucis.

Je viens de me décider de me mettre à zsh. Et là, je veux utiliser des fonctions:
J'ai un fichier .oh-my-zsh/functions/verifpart (exécutable et lorsque je l'exécute directement depuis lq console, pqs d'erreur)
Mon script principal :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#!/usr/bin/zsh # # Version avec cp -a et rsync # d="" d=$(date "+%d%B%Y") local cami="" local cami_mnt="" local repdest="" local repsrc="" local filtre="" local trace="" # Charger les fonctions qui sont dans le $FPATH à ~/.oh-my-zsh/functions autoload -t .oh-my-zsh/functions/verifpart autoload rsync_sauvegardes cpsauv   .../... #pointe sur le répertoire de montage cami_mnt="/media/copie_interne" # Vérifier si la partition est bien montée, redirection de la sortie vers null pour ne pas avoir le massage verifpart $cami_mnt

---

Au départ j'utilisait une autre version vu que FPATH contient le bon chemin vers les fonctions, puis j'ai adopté ce format explicite pour autoload.

Quoiqu'il en soit, dans les deux cas j'obtient :

Code:

---

1 2 3

zsh -X $SCRIPTREPZSH/sauvegarde_hebdo_cp.zsh /home/katden/Documentos/Informatique/Programmation/scripts/zsh//sauvegarde_hebdo_cp.zsh:74: command not found: verifpart

---

Notez le "//" dans le chemin du script ... ? ... (mais enfin ce n'est pas le problème)

Pourriez-vous me dire pourquoi il ne trouve pas "verifpart" ? Merci bien.

Bonjour,

essaie de mettre le chemin absolu vers verifpart ?
mais ce serait bizarre qu'autoload ne chouine pas parce qu'il ne trouve pas le fichier. :koi:


quant au double slash, c'est parce que la variable en contient un à la fin (c'est une mauvaise pratique); rien de grave :D :ccool:

@Katden

Tout d'abord, rassurez-vous concernant le double slash (//) que vous avez remarqué dans le chemin de votre script : les systèmes de type Unix l'interprètent simplement comme un / unique. Cela n'est donc pas la cause de l'erreur.

Votre problème de command not found provient en réalité de deux comportements spécifiques de Zsh, qui sont très bien documentés dans le manuel officiel :

1. L'environnement des scripts non interactifs :
   Lorsque vous exécutez un script via la commande zsh votre_script.zsh, Zsh démarre en mode "non interactif". Dans ce mode, il ne lit pas votre fichier ~/.zshrc. Par conséquent, toute la configuration générée par Oh-My-Zsh, y compris l'ajout de vos dossiers de fonctions à la variable $FPATH (ou $fpath), n'existe pas lors de l'exécution du script.
   
2. La syntaxe de la commande autoload :
   La commande autoload attend le nom exact de la fonction à charger, et non le chemin d'accès vers le fichier. En écrivant autoload -t .oh-my-zsh/functions/verifpart, vous demandez à Zsh de chercher une fonction dont le nom serait littéralement ".oh-my-zsh/functions/verifpart", ce qui échoue.

Pour que cela fonctionne, vous devez déclarer explicitement le dossier contenant vos fonctions dans la variable $fpath au début de votre script, puis appeler autoload uniquement avec le nom des fonctions.

Voici la correction à appliquer dans votre script principal :

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

#!/usr/bin/zsh ## Version avec cp -a et rsync # d=$(date "+%d%B%Y") local cami="" local cami_mnt="" local repdest="" local repsrc="" local filtre="" local trace=""   # 1. On ajoute explicitement le dossier des fonctions au fpath du script. # (L'utilisation de $HOME est préférable à ~ dans les scripts) fpath=( "$HOME/.oh-my-zsh/functions" $fpath )   # 2. On utilise autoload avec le nom des fonctions. # Note : L'option -U est fortement recommandée par la documentation # pour éviter que d'éventuels alias n'interfèrent avec le chargement. autoload -U verifpart autoload -U rsync_sauvegardes cpsauv   # ... suite de votre script ...   # pointe sur le répertoire de montage cami_mnt="/media/copie_interne"   # L'appel fonctionnera désormais correctement verifpart $cami_mnt

---

Citation:

---

vous demandez à Zsh de chercher une fonction dont le nom serait littéralement ".oh-my-zsh/functions/verifpart"

---

zsh devrait au moins avertir qu'il ne trouve pas la fonction appelée !

J'ai pas compris, désolé, que voulez vous dire ? Qu'est-ce qui vous semble compliqué ?

Citation:

---

Envoyé par N_BaH

Bonjour,

essaie de mettre le chemin absolu vers verifpart ?
mais ce serait bizarre qu'autoload ne chouine pas parce qu'il ne trouve pas le fichier. :koi:


quant au double slash, c'est parce que la variable en contient un à la fin (c'est une mauvaise pratique); rien de grave :D :ccool:

---

Merci.

J'ai testé avec le chemin absolu ça n'a rien changé. Par copntre je vais corriger fpeth pour retirer le "/".

@fred1599

Merci, c'est très clair et ça fonctionne (du moins cette partie, mais j'ai encore des problèmes).:)

Effectivement j'avais lu - en anglais - cette histoire de mode interactif ou pas, sans rien y comprendre... et je ne comprend toujours pas...:calim2:

Lorsque je lance un script comme ceci

Code:

---

zsh lancemonscript

---

C'est un mode qui n'est pas interactif avec ce que vous mentionnez comme conséquence. Mais, si j'ai ouvert une console zsh, alors de facto, c'est bien le mode interactif et tout les fichiers de paramétrage sont traités, non ? Donc fpath à la bonne valeur... la preuve si de fais "print $fpath" j'ai la bonne réponse ; contrairement au cas oú j'aurai une console bash dans laquelle je lancerai "zsh lancemonscript", et donc pas d emode interactif - du moins si bien suivi- ...

Et du reste si j'ouvre une console zsh pas bash ou autre chose, et que je déclare une fois de plus fpath avec le répertoire des fonctions dans mon script, du coup fpath qui est aussi déclaré dans les fichiers de paramétrage de zsh prend deux fois la valeur du chemin vers les fonctions. Parce qu'à partir du moment où j'ai ouvert une session de terminal zsh fpath et paramétré.

Est-ce juste ?... auquel cas il y a comme un truc qui me dérange...

À ce propos j'ai cru comprendre qu'il n'est pas nécessaire de mettre l'extension ".zsh" sur le fichier qui contient la script de la fonction. Est-ce vrai ?

Ps : la seule source assez complète de documentation que j'ai trouvée est là https://zsh.sourceforge.io/Doc/Relea...index-function
C'est bien, mais pas toujours compréhensible pour un néophyte comme moi je trouve.

Citation:

---

À ce propos j'ai cru comprendre qu'il n'est pas nécessaire de mettre l'extension ".zsh" sur le fichier qui contient la script de la fonction. Est-ce vrai ?

---

c'est vrai.
les extensions, sur Linux, c'est pour les humains.
tu pourrais aussi te dispenser du zsh pour exécuter ton script en le rendant exécutable et en indiquant son chemin si celui-ci n'est pas dans le PATH; c'est le shebang (la première ligne du script) qui dira au noyau quel interpréteur de commande utiliser.

pour fpath et toutes les autres variables définies dans les fichiers de configuration, elles sont accessibles dans un shell interactif (en gros, quand il y a une invite) parce que le shell lit ces fichiers. Mais, quand tu exécutes un script, tu appelles un autre environnement qui, lui, ne lit pas les fichiers de configuration lors de son initialisation, même s'il est exécuté dans un shell qui lui a lu ses fichiers de configuration.
ça te dé-dérange ? ;)

Oui ça me range 😃
Ce que j'en déduis c'est que ouvrir un shell est une chose. Depuis ce shell, ouvrir un script, c'est comme ouvrir un autre shell mais tout vierge.
Je ne comprends pas l'intérêt d'avoir fait ça comme ça maimais, y a sûrement une bonne raison

Merci pour ces réponses éclairantes.

Citation:

---

y a sûrement une bonne raison

---

en effet, les configurations concernant l'interactivité ne sont pas nécessaire dans un script qui ne l'est pas, ou qui l'est mais uniquement pour l'accomplissement de sa tâche indépendamment de l'environnement qui l'appelle..