Bonjour,
Je souhaite savoir s'il existe un moyen de dire à windows:
"Ouvre ce fichier avec ce programme"
et ce de manière automatique (en ligne de commande par exemple) sans avoir à faire clic droit, propriété, s'ouvre avec...)
D'avance merci
Bonjour,
Je souhaite savoir s'il existe un moyen de dire à windows:
"Ouvre ce fichier avec ce programme"
et ce de manière automatique (en ligne de commande par exemple) sans avoir à faire clic droit, propriété, s'ouvre avec...)
D'avance merci
De façon permanente, ou juste pour UN lancement ?
Plusieurs solutions :
- Commande assoc, qui ne marchera que pour l'utilisateur courant.
- runas + assoc pour le faire pour un autre utilisateur (à tester toutefois, j'ai un doute sur celle-là).
- Séquence de commandes reg pour ajouter la clé de registre correspondante pour n'importe quel utilisateur (y compris "tous").
Déjà, l'aide de Windows : touche Windows+F1, cherche "Références de A à Z de la ligne de commande", et mets ensuite ça dans les favoris de l'aide.
Ensuite, en tête de ce forum, tu as des annonces et des post-its que je te conseille de parcourir de A à Z.
Tu as plusieurs moteurs de script possible sous Windows : Batch, VBS, PowerShell (par ordre croissant de puissance/complexité).
Le batch est l'interpréteur "historique", celui que tu es certain de trouver partout. Le VBS est très courant également, bien qu'il puisse parfois poser quelques soucis et risque fort d'être abandonné au profit de PowerShell.
Enfin, le PowerShell est le plus récent : il est très puissant (basé sur .NET), mais il est loin d'être installé partout ou d'être encore très connu. Toutefois, l'avenir du script de commande d'administration, c'est lui. Le batch est plutôt pour les scripts de commande "personnels", ceux qui t'aident à automatiser un boulot n'impliquant pas de modifier le système (ce qui est d'ailleurs le rôle initial des fichiers batch...)
Cependant, pour des raisons historiques et de nombre de scripts existants, le batch n'est pas prêt d'être abandonné, au contraire même. Cela reste une "valeur sûre" pour des traitement simples à moyennement complexe. Le PS est plutôt à réserver pour les scripts réellement complexes (où le batch arrive à des impossibilités) je pense, du moins pour l'instant.
Dans tous les cas, tu as des tutos pour tous ces langages de script au travers des annonces/post-its du forum.
C'était l'avis "façon Microsoft", par rapport aux possibilités du batch et celles du Powershell. Une "bonne pratique", si tu préfères.
Il est clair et net que des actions d'administration qui demandaient des batchs très complexes se font désormais en quelques lignes de PS, et réciproquement : des actions "simples" en batch sont, je trouve, un peu lourdes à faire en PS. Mais cette utilisation du langage batch "aux limites" est, justement, aux limites du langage : certains scripts d'administration sont monstrueusement lents et/ou trop complexes pour être efficacement maintenus.
Reste que l'existant en batch est énorme, je l'ai souligné. Rien que pour cette raison, ce langage de script n'est pas prêt d'être abandonné, ou même simplement "réduit" dans ses possibilités. Mais pour de nouveaux traitements, si c'est de l'administration "lourde", je préconiserais PS en lieu et place du batch. Tout comme je préconise le batch pour les traitements "personnels" n'impliquant pas l'administration du système et/ou du réseau.
salut,
en cas de lenteur je suis d'accord avec vous mais en cas de possibilités offertes (ici je ne fais pas de comparaison avec PowerShell) c'est une chose discutable..à mon avis plus de 40% des possibilités des batchs est encore inexploitable (ou timidement utiliser).
en plus, le nombre important d'utilitaires tirece qui se comptent par centaines..
Disons qu'après, c'est surtout un souci de maintenabilité du code du batch plus qu'un souci de faisabilité. Et je maintiens, c'est uniquement là-dessus que je discute du bien-fondé de certains scripts batch.
Justement, ça, c'est pour moi LE argument à ne pas citer, car cela nuit au déploiement du batch (qui va alors requérir des outils tiers pour fonctionner).
Ce n'est pas (trop) gênant sur un poste dédié, ça l'est un peu plus dans le cadre d'un déploiement à plus grosse échelle (ex : script de démarrage de session Windows). C'est pour cela par exemple que je ne donne jamais d'exemples utilisant sed, awk et autres outils issus d'Unix, et que je n'utilise QUE des commandes natives.
Certes, cela limite les possibilités du langage, j'en suis conscient. Mais cela en augmente la portabilité et/ou la facilité de déploiement, ce qui est souvent tout aussi important.
ces même arguments peuvent ce porté au PowerShell "déploiement du script" et à tout autres langages de scripts donc ce qui nous restes c'est les pauvres Batchs et les VBS.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager