Il faut faire attention avec les résultats des commandes comme le ping : il est possible qu'un firewall bloque ces requêtes alors même que le serveur est joignable en FTP. Par ailleurs, le netstat ne te donneras un résultat pertinent qu'à partir du moment où la connexion est établie (puisque tu l'exécutes sur le client).
Il faudrait que tu détailles un peu la façon dont tu exécutes ton FTP. Quand tu écris que tu utilises des commandes "standard" qu'est ce que cela signifie ? Pour ma part, j'ai compris que tu utilises la commande ftp comme cela : ftp serveur <fichier_de_commande
ou bien comme ça : ftp serveur <<FIN
commande1
...
commanden
FIN
Ceci implique que le user et le mot de passe sont dans le fichier .netrc et que tu n'as pas de contrôle sur le déroulement de la connexion FTP pendant son exécution.
Le seul moyen que je connaisse alors pour savoir si tout s'est bien passé est de rediriger la sortie de la commande FTP vers un fichier et d'analyser cette log a posteriori (c'est faisable mais bon courage).
Si tu trouves des moyens plus simples et plus fiables de faire ce que tu veux, explique nous comment tu fais : à une époque j'ai longtemps chercher sans trouver.
Il faut aussi noter que le terme de "standard" pour ce type de commande peut être ambigu : la commande ftp peut varier d'un Unix à l'autre, d'une distribution Linux à une autre (y compris entre version d'une même distribution) et même en fonction du client ftp "standard" installé...
Les options d'exécution et le comportement en cas d'erreur peut être différents suivant la machine cliente (sortie di FTP à la première erreur rencontrée ou exécution des commandes jusqu'à la fin, envoi des log d'erreurs sur STDOUT ou STDERR, ...).
De la même façon, en fonction du serveur FTP sur lequel on se connecte, le texte des messages renvoyés peut varier légèrement (les codes eux sont à peu près standardiser : voir les RFC) : pour un tranfert réussi on peut par exemple avoir "226 Transfer complete." ou "250 Transfer completed successfully.".
Je pense donc encore que cela vaut la peine de se pencher sur des solutions alternatives comme des langages de scripting incluant un client FTP (zsh, Perl, ...) ou l'utilisation de commandes comme curl (upload et download) ou wget (download seulement mais installé partout).
[^] # Re: Quel interpréteur ?
Posté par JJD . En réponse au message code de retour FTP. Évalué à 1.
Il faudrait que tu détailles un peu la façon dont tu exécutes ton FTP. Quand tu écris que tu utilises des commandes "standard" qu'est ce que cela signifie ? Pour ma part, j'ai compris que tu utilises la commande ftp comme cela :
ftp serveur <fichier_de_commande
ou bien comme ça :
ftp serveur <<FIN
commande1
...
commanden
FIN
Ceci implique que le user et le mot de passe sont dans le fichier .netrc et que tu n'as pas de contrôle sur le déroulement de la connexion FTP pendant son exécution.
Le seul moyen que je connaisse alors pour savoir si tout s'est bien passé est de rediriger la sortie de la commande FTP vers un fichier et d'analyser cette log a posteriori (c'est faisable mais bon courage).
Si tu trouves des moyens plus simples et plus fiables de faire ce que tu veux, explique nous comment tu fais : à une époque j'ai longtemps chercher sans trouver.
Il faut aussi noter que le terme de "standard" pour ce type de commande peut être ambigu : la commande ftp peut varier d'un Unix à l'autre, d'une distribution Linux à une autre (y compris entre version d'une même distribution) et même en fonction du client ftp "standard" installé...
Les options d'exécution et le comportement en cas d'erreur peut être différents suivant la machine cliente (sortie di FTP à la première erreur rencontrée ou exécution des commandes jusqu'à la fin, envoi des log d'erreurs sur STDOUT ou STDERR, ...).
De la même façon, en fonction du serveur FTP sur lequel on se connecte, le texte des messages renvoyés peut varier légèrement (les codes eux sont à peu près standardiser : voir les RFC) : pour un tranfert réussi on peut par exemple avoir "226 Transfer complete." ou "250 Transfer completed successfully.".
Je pense donc encore que cela vaut la peine de se pencher sur des solutions alternatives comme des langages de scripting incluant un client FTP (zsh, Perl, ...) ou l'utilisation de commandes comme curl (upload et download) ou wget (download seulement mais installé partout).
A+
JJD