2011-05-04 12:54:50 +0000 2011-05-04 12:54:50 +0000
92
92
Advertisement

Comment échapper aux espaces en ligne de commande dans Windows sans utiliser de guillemets ?

Advertisement

Par exemple, quelle est l'alternative à cette commande sans guillemets :

CD "c:\Documents and Settings"

La raison pour laquelle je ne veux pas utiliser de guillemets est que cette commande fonctionne :

SVN add mypathname\*.*

mais cette commande ne fonctionne PAS :

SVN add "mypathname\*.*"

Le problème étant que lorsque je change mon nom de chemin pour un chemin avec des espaces, je dois citer le tout. Par exemple :

SVN add "c:\Documents and Settings\username\svn\*.*"

Mais lorsque j'essaie cette commande, j'obtiens le message d'erreur suivant :

svn: warning: 'c:\Documents and Settings\username\svn\*.*' not found
Advertisement

Réponses (7)

59
59
59
2011-05-04 16:59:54 +0000

Presque tout fonctionne pour moi, mais avez-vous peut-être essayé la ligne 5… en vous échappant de l'espace avec un symbole de caret (^)

1 C:\Documents and Settings\user>cd ..

2 C:\Documents and Settings>cd ..

3 C:\>cd Documents and Settings

4 C:\Documents and Settings>cd..

5 C:\>cd Documents^ and^ Settings

6 C:\Documents and Settings>cd..

7 C:\>cd C:\documents and settings

8 C:\Documents and Settings>cd..

9 C:\>

Ou par exemple en dessous où le caret fait vraiment toute la différence.

On dirait qu'en dessous, le symbole de caret peut être votre réponse, voir ligne 3 ci-dessous.

1 C:\>"c:\Documents and Settings\a.bat"
gaga

2 C:\>c:\Documents and Settings\a.bat
'c:\Documents' is not recognized as an internal or external command,
operable program or batch file.

3 C:\>c:\Documents^ and^ Settings\a.bat
gaga

C:\>
36
36
36
2013-04-24 07:45:18 +0000

J'ai constaté que le fait de mettre des citations autour d'une seule partie du lieu fonctionne. Dans votre cas :

SVN add C:\"Documents and Settings"\username\svn\*.*

Bien que cette méthode utilise des guillemets, il est important de noter que les astérisques se trouvent à l'extérieur des guillemets, ce qui fait qu'ils fonctionnent correctement.

26
Advertisement
26
26
2015-08-26 02:01:44 +0000

Malgré les réponses qui donnent l'illusion que ça marche, le fait est qu'on ne peut pas se faufiler dans les espaces pour trouver les arguments habituels des cmd. C'est facile à prouver :

  1. Enregistrez “echo %1” sous le nom de test.bat. Ce fichier batch produira le premier argument que le cmd nous passera.

  2. Maintenant, essayez de lancer test.bat, en fixant la valeur de %1 à foo bar. (Notez qu'il y a un espace entre foo et bar.)

  3. Faites des essais et des erreurs pendant quelques années et réalisez que il n'y a pas moyen de le faire. Les gens vont suggérer de s'échapper en utilisant ^, mais test.bat foo^ bar ne produira pas foo bar.

Donc, il n'y a aucun moyen d'obtenir la sortie foo bar, et le plus proche que nous puissions obtenir est de faire fonctionner test.bat foo" "bar qui produit foo" "bar, ou de faire fonctionner test.bat "foo bar" qui produit "foo bar". Maintenant, la raison pour laquelle les autres réponses apparaissent fonctionner est que cd fait sa propre analyse additionnelle, divergeant du comportement des passages d'arguments habituels (les %1, %2, %3 et etc. dans les fichiers batch typiques).

Par exemple, considérons la commande particulière :

cd c:\documents and settings \some folder with spaces

Pourquoi fonctionne-t-elle ? Cela est dû au fait que cd self fait quelque chose d'équivalent à la réunion des 7 arguments usuels en un seul logique. Selon les normes de passage des arguments du cmd, nous voyons 7 arguments :

  1. c:\documents
  2. and
  3. settings
  4. \some
  5. folder
  6. with
  7. spaces

C'est comme si cd avait réuni les 7 arguments en un seul, faisant quelque chose de semblable à array.join(" "), qui produit le chemin :

c:\documents and settings \some folder with spaces

Notez que ce comportement est spécifique à cd seulement (et à quelques autres fonctions). Il n'a rien à voir avec le passage habituel des arguments.


En effet, cd a une autre particularité. Rappelez-vous que nous avons dit plus haut que nous ne pouvions pas obtenir la sortie foo bar ? Le résultat le plus proche que nous pouvons obtenir est en exécutant :

test.bat foo" "bar

qui produit foo" "bar, ou :

test.bat "foo bar"

qui produit "foo bar", ou :

test.bat "foo "bar

qui produit "foo "bar, ou :

test.bat foo" bar"

qui produit foo" bar", ou :

test.bat "foo b"ar

qui produit "foo b"ar, ou :

test.bat fo"o bar"

qui produit fo"o bar", ou :

test.bat fo"o ba"r

qui produit fo"o ba"r, ou :

test.bat "fo"o" bar"

qui produit "fo"o" bar", ou :

test.bat "f""o""o"" ""b""a""r":

qui produit "f""o""o"" ""b""a""r", ou encore :

test.bat """"f"""o""""o"" ""ba"""r"""""""""":

qui produit """"f"""o""""o"" ""ba"""r"""""""""". Tous les exemples ci-dessus présentent une similitude, à savoir qu'ils produiront foo bar après que nous ayons supprimé les caractères ". L'auteur de cd a dû s'en rendre compte lui aussi… si nous devions déduire du comportement particulier de cd qui trippe tous les " qu'il reçoit , permettant à toutes ces commandes de fonctionner :

  • cd c:\documents and settings

  • cd "c:\documents and settings"

  • cd "c:"\"documents and settings"

  • cd c:\"documents" "and" "settings"

  • cd c:\"docu"ments an"d set"tings"

  • cd c:"\"docu"ments an"d set"ti"""ngs

  • cd "c"":""\"docu"ments an"d set"ti"""ngs

  • cd "c"":""\"do""cu"me"nts a"n""d set"ti"""ngs

  • cd c"""":""""\"""d"""oc""""u"me"""""nt"s a"n""d set"""""""ti""""ngs

  • &007

8
8
8
2014-04-19 07:51:15 +0000

Le nom du fichier court semble fonctionner comme une brise.

“E:\Progra~1\Java\Eclipse\eclipse.exe” -vmargs -Xms1024m -Xmx2048m

Pour augmenter la mémoire… ;)

3
Advertisement
3
3
2012-10-03 14:47:56 +0000

Utilisez le nom de fichier court 8.3. Par exemple :

If exist c:\docume~1 goto :Ifoundthesucker
2
2
2
2017-05-12 08:43:24 +0000

Pour ceux qui parlent du remplacement de la version 8.3, veuillez noter les deux choses suivantes :

  • La version 8.3 peut être désactivée (ou activée) sur NTFS, donc elle peut ne pas toujours exister.
  • Le nom 8.3 d'un fichier/dossier peut être modifié sans préavis, simplement en créant, renommant ou supprimant d'autres choses dans le même dossier.

Donc c:\docume~1 peut pointer vers :

  • Nulle part (être invalide)
  • Le dossier que vous voulez
  • Un autre dossier
  • Un dossier variable dans le temps

Ce n'est pas sûr, à moins que vous n'obteniez le nom court et que vous l'utilisiez dans des opérations atomiques.

Bien qu'il soit très rare qu'ils changent, il est courant qu'ils n'existent pas.

Si vous voulez savoir si 8.3 existe pour un dossier/fichier particulier, testez-le avec le paramètre /X sur une commande dir, ou encapsulez-le sur un for pour n'obtenir que cette partie, etc.

Pour en savoir plus sur la façon d'activer/désactiver 8.3 sur NTFS, voir cet article de support Microsoft : https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions

0
Advertisement
0
0
2019-08-08 20:42:46 +0000

Suite à l'article de @Pang, et à d'autres discussions sur les noms courts et les pièges, voici comment résoudre dynamiquement un nom long en un nom court :

for %A in ("C:\Some\long path\which must exist\to be resolved") do @echo %~sA

Puis, évidemment, vous pouvez utiliser le nom court plutôt que les guillemets qui l'entourent.

Advertisement