Je cherche à bypasser la limitation de 2048 caractères dans un shell sous windows 2000.
 
Typiquement j'ai une *grosse* ligne de commande à lancer (il s'agit du démarrage d'une virtual machine Java avec un classpath particulièrement long).
 
Une idée?

bide

bravo

Juste une idee comme ca : utilise la variable d'environement CLASSPATH au lieu de passer le classpath par la ligne de commande.

c'est la ligne de commande qui est limitée. Donc, au runtime la variable est remplacée par la valeur effective. Si l'ensemble dépasse 2048 caractères, ca pête.
 
L'idée est de passer par un process C qui ne fait pas appel au shell (c'est une limitation du shell en fait) mais bon bof quoi.

il faut que tu utilises le caractère "^" pour marquer un saut de ligne, et ainsi dépasser la limite
exemple :

tu obtiens en sortie 2098 caractères

Il n'existe pas de vraie solution à ce problème. WXP et W2003 peuvent aller jusqu'à 8000 caractères il me semble.
 
Toutefois, il est préférable de faire un peu le ménage dans le CLASSPATH:
 
Si tu as un classpath avec plein de fichiers, mais beaucoup situés dans le même répertoire, utilise le paramètre -Djava.ext.dirs=répertoire1;répertoire2;répertoire3
 
Par exemple:
java -cp c:\j2re\lib\titi.jar;c:\j2re\lib\tata.jar;c:\j2re\lib\toto.jar
(et que toutes les archives et classes dans ce répertoire sont spécifiées)
 
Tu peux alors écrire plus simplement:
java -Djava.ext.dirs=c:\j2re\lib

 
Tu n'as pas compris ce que je voulais dire. Evidemment, faire java -classpath $CLASSPATH ne change rien au probleme. Par contre tu peux exporter la variable d'environement CLASSPATH, et lancer java sans -classpath... Ce qui reduit d'autant la longueur de la ligne de commande.
 

 
Le problème reste entier si le classpath seul fait plus de 2048 caractères.
Tu ne peux pas mettre une ligne aussi longue en passant par l'interface graphique de Windows, et si tu tentes en ligne de commandes "set CLASSPATH=xxxx" ou "setx classpath xxxxx" tu retombes dans le même pb de longueur maxi.
 
Une autre solution à ton pb, si tu es prêt à tout, est d'utiliser un shell autre que celui de Windows 2000. Par exemple, sous cygwin/bash, la même ligne de commande ne pose aucun problème.

 
Non, c'est completement different. Si c'est a peu pret comme sous linux/unix, "set" est une instruction du shell. Tu n'invoques pas de commande, donc tu n'est pas limite par la taille de ligne de commande.
 

 
Alors ca ca m'etonnerait beaucoup. Je ne vois pas comment le fait d'utiliser bash sous cygwin souleverait les limites de l'OS qui est en dessous. Que ce soit windows, linux ou unix, c'est le kernel qui limite la taille de la ligne de commande.

 
Ce n'est *pas* comme sous Unix/Linux alors (d'ailleurs je t'ai précisé que ça marchait avec bash ...).
Pourtant "set" est bien une commande intégrée au shell de windows, comme export pour bash. Mais je ne vois pas le rapport entre commande intégrée/commande tierce, et pas de limitation de la longueur ... (puisque c'est le shell qui limite, cf réponse suivante)
 
 

 
Non, c'est une limitation de l'interpreteur de commande (cmd.exe), pas de Windows lui-même.
C'est d'ailleurs documenté chez Microsoft: http://support.microsoft.com/defau [...] -us;830473
 
Je précise que tout ce que je dis, je l'ai déja testé. Je ne balance pas des suppositions comme des affirmations. Le coup du classpath de 4000 caractères, j'ai déja donné merci, et je t'assure qu'un "set classpath" te sort le même résultat que "java -classpath", à savoir, "input line too long", alors que ça marche très bien sous cygwin.
 
Et je pense que de toutes façons, quand la ligne de commande dépasse 2000 caractères, il faut se poser des questions sur son utilité ...