zsh et fonctions

Version imprimable

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.

28/03/2026, 12h14
Invité

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 :

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

29/03/2026, 15h15
Invité

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 !
29/03/2026, 15h20
fred1599

J'ai pas compris, désolé, que voulez vous dire ? Qu'est-ce qui vous semble compliqué ?
30/03/2026, 10h07
Katden

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 "/".
30/03/2026, 10h40
Katden

@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.
30/03/2026, 14h58
Invité

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 ? ;)
30/03/2026, 20h31
Katden

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.
30/03/2026, 20h42
Invité

Citation:

y a sûrement une bonne raison

en effet, les configurations concernant l'interactivité ne sont pas nécessaires 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..
31/03/2026, 06h34
Katden

Vu comme ça, ça à du sens en effet. Merci.

Citation:

Envoyé par fred1599

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

tu as déjà dépassé le nombre de questions gratuites à l'IA ?! 8O
:roll:

je te l'ai déjà dit : quitte à te faire l'agent humain de l'IA, tu devrais présenter "tes" réponses entre QUOTE
Citation:
Envoyé par fred1599
@Katden
Citation:
Envoyé par l'IA sur laquelle j'ai posé la question
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 :

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.
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
il serait donc plus simple pour toi de renvoyer l'OP à LMGPTTFY, et ce serait plus honnête.

31/03/2026, 17h01
fred1599

Citation:

tu as déjà dépassé le nombre de questions gratuites à l'IA ?!

Non il y a eu une suppression de message et donc ma réponse n'avait plus de cohérence avec la réponse précédente.