Commande shell ne marchant pas correctement en VBA

Version imprimable

26/04/2018, 11h04
RyuAutodidacte

Commande shell ne marchant pas correctement en VBA

Bonjour,

j'utilise une ligne de commande (tester avec l'invite de commande => résultat OK),
permettant de connaître le nombre de ligne dans un fichier texte
(je suppose qu'elle marche aussi avec les ".csv") :

Code:

find /v /c "" < Path/fichier.txt

Lorsque j'ai voulu l'utiliser en VBA via la commande Shell, j'ai eu des résultats complètement aléatoire.
(pas de souci avec l'invite de commande)

Code:

toto = Shell("Cmd.exe /C" & "find /v /c """" < " & """" & Path/fichier.txt & """", 0)

1- Est ce que cette commande est fiable ?
2- ai-je loupé quelque chose afin que la commande marche correctement

Config : cession de démarrage Windows 10 Excel 2010 (je suis sur Mac sinon)

Merci

Ryu
26/04/2018, 11h52
Menhir

(sans certitude) essaye ça :

Code:

toto = Shell("Cmd.exe /C" & " FIND /v /c """" < Path/fichier.txt", 0)

En supposant que Path/fichier.txt est un chemin écrit en dur et non des variables.

Petit détail : sur Windows et Mac, ça ne peut bien sûr pas fonctionner avec la même syntaxe, au moins en ce qui concerne le chemin.
26/04/2018, 13h07
RyuAutodidacte

Coucou Menhir,

En Effet Path/fichier.txt est bien une variable, je l'ai écrit de cette façon pour que ce soit représentatif.
Par contre j'ai noté que ton FIND est écrit tout en capital, c'est peut être cette petite différence qui joue sur le résultat …
Dès que j'ai accès à un PC je tests, au pire je le ferai ce soir.
Merci

Edit :

Citation:

Petit détail : sur Windows et Mac, ça ne peut bien sûr pas fonctionner avec la même syntaxe, au moins en ce qui concerne le chemin.

Pour cela pas de souci ;) (toujours bien de le spécifier)
26/04/2018, 15h24
Menhir

MS-DOS ne faisait pas de différences entre majuscules et minuscules. Il est donc peu probable que ça ait une incidence.

Par contre, je crois plus à l'espace entre /C et find et à la suppression des train de ".

Pour ce qui est de l'introduction de ta variable, j'ai de sérieux doutes.
Mais comme tu ne donnes pas les infos sur le sujet, difficile d'en dire plus.
26/04/2018, 16h40
RyuAutodidacte
Re,

pour être dans le contexte voilà ce que l'on aurait dans le code concernant les variables - dans VBA :
(j'ai doublé les guillemets au endroits nécessaires normalement)
Code:

1 2 3 Chm = "C:\Users\UserName\Documents\MesFichiers\" NomFichier = "TITI.txt" toto = Shell("Cmd.exe /C" & "find /v /c """" < " & """" & Chm & NomFichier & """", 0)
Ce que j'ai dans l'invite de commande et qui marche (de tête j'ai pas de PC là):

Code:

find /V /C "" < "C:\Users\UserName\Documents\MesFichiers\TITI.txt"

Citation:

Envoyé par RyuAutodidacte

(j'ai doublé les guillemets au endroits nécessaires normalement)

Je peux me tromper mais j'ai l'impression que dans le lot, il y en a quelques uns en trop.
Je comprends la première série de 4 mais je comprends moins les suivants.

A ta place, je mettrais tout ça dans une variable String intermédiaire pour pouvoir vérifier ce que ça donne.
Code:

1 2 3 4 5 Chm = "C:\Users\UserName\Documents\MesFichiers\" NomFichier = "TITI.txt" MaCommnade = "Cmd.exe /C" & "find /v /c """" < " & """" & Chm & NomFichier & """" Debug.Print MaCommande toto = Shell(MaCommande, 0)
Je peux encore me tromper mais il me semble que ça devrait plutôt ressembler à ça :

Code:

MaCommnade = "Cmd.exe /C" & " find /v /c """""" < " & Chm & NomFichier

Le fait d'avoir une String intermédiaire te permettra de le vérifier.

Citation:

Code:

find /V /C "" < "C:\Users\UserName\Documents\MesFichiers\TITI.txt"

Es-tu sûr que les guillemets soient nécessaires pour encadrer le nom de fichier ?

Si c'est le cas (ce dont je doute), la syntaxe serait :

Code:

MaCommnade = "Cmd.exe /C" & " find /v /c """""" < " & """" & Chm & NomFichier & """"

26/04/2018, 17h48
unparia

Bonjour Ryu
Lorsque l'on écrit
toto = Shell("..........")
toto n'est pas le résultat de la commande, mais l'identificateur de tâche (ID = numéro identifiant le programme en cours d'exécution)
Tu as d'une part l'exécution de la commande (que tu ne vois pas) et d'autre part ce que retourne toto ( > 0 si la commande a réussi, 0 si elle a échoué).
Tu ne saurais obtenir ton résultat sans créer un pipe :
- vers un fichier pour y consigner ce résultat
ou
- vers une variable ou un contrôle en utilisant une fonction de l'api de Windows

Le jeu n'en vaut pas la chandelle (trop lourd pour création d'un pipe/contrôle - ou si pipe vers fichier à ouvrir ensuite, autant se servir directement de l'instruction Open pour compter les vbnewline).
26/04/2018, 21h55
clementmarcotte

Bonjour,

Je crains que ce soit non, mais peux-tu utiliser le Scripting Runtime (File System Object) avec ton Mac ?
Si, par chance, c'est oui, il y a un truc tout simple:

FSO, ou une autre portion du Scripting Runtime, permet de trouver à quelle ligne tomberait une nouvelle ligne d'un fichier texte. Tant que tu n'as pas de ligne vide qui dépasse, tu trouves ce numéro et tu lui enlèves un.
26/04/2018, 22h38
unparia

Existent également deux possibilités
1) l'une avec PowerShell (à installer si non présent !)
2) l'autre en passant par une connexion ADODB

Ni l'une ni l'autre ne valent le coup, comparées à une simple utilisation de l'instruction Open.

Bonsoir,

- Déjà merci à Menhir de s'être intéressé à mon problème :ccool:

- clementmarcotte :

Citation:

peux-tu utiliser le Scripting Runtime (File System Object) avec ton Mac ?

Tout ce qui appartient à ActiveX n'est pas utilisable sur Mac.
Mais la question ne se pose pas, car je le fait sur PC.

Pour la petite histoire en qq mots : quand j'ai débuté en VBA, les réponses données était accès PC et non Mac, et j'avais beaucoup de mal à comprendre
(la plupart des utilisateurs étant PC + l'aide VBA Via le F1 n'existe pas sur Mac).
J'ai donc fait une partition Windows sur mon Mac avec Excel pour comprendre ce que j'avais du mal à assimilé et voir les différences entre Mac et PC;
Et cela aide grandement. J'ai eu aussi une grande aide sur le forum (d'une personne qui se reconnaitra, coucou ;) et d'autres par la suite que je salue tout autant ;)) qui m'a permis de bien progressé, bien sur avec beaucoup de travail ...
Grâce à cela j'ai moins de difficulté de passer en VBA d'une plateforme à l'autre.

Là le shell windows est tout nouveau pour moi.
Contrairement au Mac où il suffit de passer par AppleScript en utilisant la Commande "do shell script "le script"" récupérant les valeurs envoyé par le Terminal

- Jacques :

Citation:

mais l'identificateur de tâche (ID = numéro identifiant le programme en cours d'exécution)

Je comprends mieux le résultat des chiffres différents à chaque lancement du code
C'est la bonne réponse, et tellement logique une fois dit :plusser: (bien vu tu as deviner où je voulais en venir)

Donc j'ai pas mal d'imagination (et il en faut pour faire du code :mrgreen:) et j'ai modifié légèrement ma commande :

Code:

Shell "Cmd.exe /C" & "FIND /v /c """" < " & """" & Chm & FicDestFinal & """" & " | clip", 0

Je suppose que la aussi tu vois à quoi je pense - maintenant est ce que cela vaut vraiment le coup ? ( je ne suis pas assez expert sur PC pour le savoir)
Voilà je n'ai pas voulu compliqué la commande en envoyant le résultat directement dans le presse-papier, il suffit juste de le récupérer ...
Code:

1 2 3 4 5 6 7 8 9 Chm = "C:\Users\UserName\Documents\MesFichiers\" NomFichier = "TITI.txt" Shell "Cmd.exe /C" & "FIND /v /c """" < " & """" & Chm & NomFichier & """" & " | clip", 0 Const DATAOBJECT_BINDING As String = "new:{1C3B4210-F441-11CE-B9EA-00AA006B1A69}" With CreateObject(DATAOBJECT_BINDING) .GetFromClipboard NbLig = .GetText End With
Edit : on s'est croisé Jacques pendant que je faisais mon roman :)

26/04/2018, 23h10
unparia

rediriger vers le presse-papier est une bonne et astucieuse idée :plusser:

Je ne sais par contre pas si tout cela vaut vraiment le coup.
Mais l'exercice est déjà plaisant.
Amitiés
26/04/2018, 23h17
RyuAutodidacte

Je peux me tromper, mais je pense que cela peut valoir le coup pour des fichiers volumineux,
tandis que pour des tout petits fichiers il vaut mieux utiliser Open

Ryu ;)
26/04/2018, 23h24
unparia

Citation:

Je peux me tromper, mais je pense que cela peut valoir le coup pour des fichiers volumineux,
tandis que pour des tout petits fichiers il vaut mieux utiliser Open

rien n'empêche (tu sais maintenant le faire) de lire bloc par bloc et de compter (par split) le nombre de chr(13) présents dans chaque bloc.

Je dis chr(13) et non vbcrlf pour le cas où un bloc se terminerait par exemple sur un chr(10) et que le suivant commencerait par un chr(13).
Or, les sauts de lignes dans les fichiers .txt sont exprimés par des vbcrlf (et contiennent donc forcément le caractère chr(13)).
Amitiés
26/04/2018, 23h35
RyuAutodidacte

figure toi que j'y avais pensé mais fait chou blanc - je m'y suis mal pris et je comprends pourquoi en partie, j'ai utilisé Chr(10) :oops:
(il y a surement autre chose)

il faudra que je re teste.

Merci Jacques :plusser:

Edit : je viens de me rappeler que je me suis arrêter de coder dans ce sens là car j'avais peur qu'au final le résultat soit aussi bien avec les lignes non vides et les lignes vides, ce qui fausserait celui-ci.
Mais ceci dit pour un fichier dont on ne doute pas de l'intégrité des données tel qu'il a été conçu, c'est une bonne solution ...

Citation:

j'y avais pensé mais fait chou blanc - je m'y suis mal pris et je comprends pourquoi en partie, j'ai utilisé Chr(10)
(il y a surement autre chose)

Tu t'es peut-être fait des crocs en jambe.
Voilà ce que tu aurais pu écrire (exemple) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Private Sub CommandButton1_Click() Dim lgb As Long, fic As String lgb = 100000 ' ----->> taille de bloc à traiter (à à mettre à la valeur de votre choix ...) fic = "d:\test.txt" MsgBox nbl(fic, lgb) End Sub Private Function nbl(fic As String, lgb As Long) As Long Dim lgt As Long, nb As Long, reste As Long, k As Long, titi As String Dim FS As Integer FS = FreeFile nbl = 1 Open fic For Input As #FS lgt = LOF(FS): nb = lgt \ lgb: reste = lgt Mod lgb For k = 1 To nb titi = Input(lgb, #FS) nbl = nbl + UBound(Split(titi, Chr(13))) Next titi = Input(reste, #FS) nbl = nbl + UBound(Split(titi, Chr(13))) Close #FS End Function
EDIT :

Citation:

je viens de me rappeler que je me suis arrêter de coder dans ce sens là car j'avais peur qu'au final le résultat soit aussi bien avec les lignes non vides et les lignes vides, ce qui fausserait celui-ci

Des lignes, vides ou non, sont des lignes.
Un fichier texte peut fort bien contenir des lignes vides, créées délibérément à des fins précises. Je me sers personnellement (et ne suis pas le seul) assez souvent de constructions de cette nature. Elles permettent entre autres de visualiser beaucoup mieux différents articles d'un fichier texte (plutôt que de séparer par un caractère moins "parlant")

27/04/2018, 09h10
RyuAutodidacte

Coucou,

Concernant l'Edit, je ne le contredit pas, j'ai écrit aussi :

Citation:

Mais ceci dit pour un fichier dont on ne doute pas de l'intégrité des données tel qu'il a été conçu, c'est une bonne solution ...

C'était surtout par rapport à la demande dans le post où le demandeur ne voulait pas de ligne vide.
27/04/2018, 13h57
RyuAutodidacte

Re Jacques,

:plusser: la demo du post #15

Amitiés

Ryu