Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonjour !
Script tout bête. Il permet de récupérer, dans le presse-papier (clipboard),
une liste de nom de fichiers sélectionnés dans un des explorateurs de
windows.
Mise en place :
- copier le script sous le nom arg2clipboard.pyw (n'oubliez pas le
'w')
- créer un icône sur le bureau, avec, comme cible :
C:\Python23\pythonw.exe C:\pyt\arg2clipboard.pyw
(il faut adapter le chemin, là où on a enregistré le script)
Utilisation :
Ouvrir l'explorateur ; sélectionner un ou plusieurs fichiers ;
clic-droit
+ "copier"
Clic-droit sur l'icone + "coller"
Ouvrir un éditeur de texte ; coller
Divers :
- ça marche aussi, si, à la place du copier-coller, on fait un
drag-and-drop des fichiers, vers l'icone ;
- ça marche aussi, si on glisse l'icone dans la barre de lancement
rapide ;
- avec le même principe, vous pouvez compléter le script, pour zipper la
sélection ; l'envoyer par mail, ou en ftp ; etc.
Conclusion :
Même pour scripter, Python, c'est génial.
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." wrote in message news:ceq8h1$h6o$
d'après le jargon français En fait, c'est la définition, d'UNE instanciation d'UN jargon français.
Mais il y en a d'autres. On trouve des caractéristiques variables (parfois contradictoires), selon les sources : les langages de scripts sont interprétés ; ils utilisent des scripts sous forme de texte ; n'utilisent pas de branchements ; restent à l'intérieur d'un espace d'exécution défini et limité ; etc.
Une autre confusion ici: parler de "langage interprete" n'a pas vraiment de sens, le fait d'etre interprete ou compile n'est pas une caracteristique d'un langage mais d'une implementation...
Pouvez-vous expliciter "des scripts sous forme de texte" ? Pour tous les langages que je connais, les programmes sont ecrits, donc stockes sous forme de texte.
Y'a t-il des langages utilises de nos jours et ne permettant pas de branchements ?
"Michel Claveau - abstraction méta-galactique non triviale en fuite
perpétuelle." <unseulmcmcmcmc@msupprimerlepoint.claveauPOINTcom> wrote in
message news:ceq8h1$h6o$1@news-reader1.wanadoo.fr...
d'après le jargon français
En fait, c'est la définition, d'UNE instanciation d'UN jargon français.
Mais il y en a d'autres. On trouve des caractéristiques variables (parfois
contradictoires), selon les sources : les langages de scripts sont
interprétés ; ils utilisent des scripts sous forme de texte ; n'utilisent
pas de branchements ; restent à l'intérieur d'un espace d'exécution défini
et limité ; etc.
Une autre confusion ici: parler de "langage interprete" n'a pas vraiment
de sens, le fait d'etre interprete ou compile n'est pas une caracteristique
d'un langage mais d'une implementation...
Pouvez-vous expliciter "des scripts sous forme de texte" ? Pour tous les
langages que je connais, les programmes sont ecrits, donc stockes sous
forme de texte.
Y'a t-il des langages utilises de nos jours et ne permettant pas de
branchements ?
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." wrote in message news:ceq8h1$h6o$
d'après le jargon français En fait, c'est la définition, d'UNE instanciation d'UN jargon français.
Mais il y en a d'autres. On trouve des caractéristiques variables (parfois contradictoires), selon les sources : les langages de scripts sont interprétés ; ils utilisent des scripts sous forme de texte ; n'utilisent pas de branchements ; restent à l'intérieur d'un espace d'exécution défini et limité ; etc.
Une autre confusion ici: parler de "langage interprete" n'a pas vraiment de sens, le fait d'etre interprete ou compile n'est pas une caracteristique d'un langage mais d'une implementation...
Pouvez-vous expliciter "des scripts sous forme de texte" ? Pour tous les langages que je connais, les programmes sont ecrits, donc stockes sous forme de texte.
Y'a t-il des langages utilises de nos jours et ne permettant pas de branchements ?
Les fichiers de config, html, sql...
Mais peut-être que c'est un abus... de langage !
-- Wilk - http://flibuste.net
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Le langage de programmation des orgues de Barbarie ? Les séquences d'automatisation des automates, sur rubans perforés ? Le HTML ? (HTML pur, pas avec du javascript intégré). XML ?
Le langage de programmation des orgues de Barbarie ?
Les séquences d'automatisation des automates, sur rubans perforés ?
Le HTML ? (HTML pur, pas avec du javascript intégré).
XML ?
Le langage de programmation des orgues de Barbarie ? Les séquences d'automatisation des automates, sur rubans perforés ? Le HTML ? (HTML pur, pas avec du javascript intégré). XML ?
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonjour !
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python ? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne pas forcément envie de regarder Linux.
Bonjour !
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est
qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances
sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python
? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne
pas forcément envie de regarder Linux.
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python ? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne pas forcément envie de regarder Linux.
Xavier Combelle
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:
Bonjour !
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Là, je ne suis pas d'accord, aussi bien python que le C ont des dépendances clairement exprimées par les import et les include. Un script shell dépend de quels sont les programmes installes sur la machine et de la manière dont ils réagissent. Par exemple, passer les bons arguments en ligne de commande.
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python ? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne pas forcément envie de regarder Linux.
Là, tu fait dire à ma citation beaucoup plus que ce qu'elle disait. elle ne comparait que c et shell. Je ne voit pas en tu lui fait dire les autres comparaisons. Ensuite, le caractère d'Unix-nature fait plutôt référence à la capacité du shell à mettre en relation des outils
l'exemple donné par l'aide info au sujet de la software Toolbox who | cut -c1-8 | sort | uniq qui permet de lister les utilisateurs de la machine illustre (il me semble, la phrase de Eric S. Raymond "There is more Unix-nature in one line of shell script than there is in ten thousand lines of C"
C'est la qualité de mise en relation d'outil simple qui fait la grande force du shell. Je ne vois pas sur ce plan quel est l'avantage qu'à le Perl sur Python.
Michel Claveau - abstraction méta-galactique non triviale en fuite
perpétuelle. wrote:
Bonjour !
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est
qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances
sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Là, je ne suis pas d'accord, aussi bien python que le C ont des
dépendances clairement exprimées par les import et les include.
Un script shell dépend de quels sont les programmes installes sur la
machine et de la manière dont ils réagissent. Par exemple, passer les
bons arguments en ligne de commande.
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python
? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne
pas forcément envie de regarder Linux.
Là, tu fait dire à ma citation beaucoup plus que ce qu'elle disait.
elle ne comparait que c et shell. Je ne voit pas en tu lui fait dire les
autres comparaisons.
Ensuite, le caractère d'Unix-nature fait plutôt référence à la capacité
du shell à mettre en relation des outils
l'exemple donné par l'aide info au sujet de la software Toolbox
who | cut -c1-8 | sort | uniq
qui permet de lister les utilisateurs de la machine illustre (il me
semble, la phrase de Eric S. Raymond "There is more Unix-nature in one
line of shell script than there is in ten thousand lines of C"
C'est la qualité de mise en relation d'outil simple qui fait la grande
force du shell. Je ne vois pas sur ce plan quel est l'avantage qu'à le
Perl sur Python.
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:
Bonjour !
Ta citation 1 ne concerne que le shell, et pourtant, ce qui est dit n'est qu'une généralité (dans TOUS les programmes, scripts ou non, les dépendances sont plus difficiles à analyser, lorsque qu'il devient plus "large").
Là, je ne suis pas d'accord, aussi bien python que le C ont des dépendances clairement exprimées par les import et les include. Un script shell dépend de quels sont les programmes installes sur la machine et de la manière dont ils réagissent. Par exemple, passer les bons arguments en ligne de commande.
Et, ;o) , selon ta citation 2 : Perl serait plus "Unix-nature" que Python ? Ou même Haskell que Bash... Point de vue intéressant, mais qui ne donne pas forcément envie de regarder Linux.
Là, tu fait dire à ma citation beaucoup plus que ce qu'elle disait. elle ne comparait que c et shell. Je ne voit pas en tu lui fait dire les autres comparaisons. Ensuite, le caractère d'Unix-nature fait plutôt référence à la capacité du shell à mettre en relation des outils
l'exemple donné par l'aide info au sujet de la software Toolbox who | cut -c1-8 | sort | uniq qui permet de lister les utilisateurs de la machine illustre (il me semble, la phrase de Eric S. Raymond "There is more Unix-nature in one line of shell script than there is in ten thousand lines of C"
C'est la qualité de mise en relation d'outil simple qui fait la grande force du shell. Je ne vois pas sur ce plan quel est l'avantage qu'à le Perl sur Python.
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonsoir !
Cas 1 ) Un programme, fut-il en Python, ne dépend pas que des import, mais d'un ensemble d'éléments, internes ou externes au programme. Par exemple, un programme en Python sous windows, qui fera appel à des serveurs COM dépend de leur présence ; il ne fonctionnera par sous Linux, où ce genre de fonctionnalité n'existe pas. Et, donc, plus le programme est gros, plus il y a de risque de se perdre dans les dépendances. C'est une évidence, une généralité, une lapalissade.
Cas 2) Ta citation fait EXPLICITEMENT référence au nombre de lignes des programmes. Or, la compacité (vu par le nombre de lignes), n'est pas un critère de "nature". C'est ce qu'avait démontré "a contrario" Intercal, face à Cobol, il y a maintenant une trentaine d'années, à la grande époque de la productivité "à la ligne" des programmeurs.
@-salutations -- Michel Claveau
Bonsoir !
Cas 1 ) Un programme, fut-il en Python, ne dépend pas que des import, mais
d'un ensemble d'éléments, internes ou externes au programme. Par exemple, un
programme en Python sous windows, qui fera appel à des serveurs COM dépend
de leur présence ; il ne fonctionnera par sous Linux, où ce genre de
fonctionnalité n'existe pas.
Et, donc, plus le programme est gros, plus il y a de risque de se perdre
dans les dépendances. C'est une évidence, une généralité, une lapalissade.
Cas 2) Ta citation fait EXPLICITEMENT référence au nombre de lignes des
programmes. Or, la compacité (vu par le nombre de lignes), n'est pas un
critère de "nature". C'est ce qu'avait démontré "a contrario" Intercal, face
à Cobol, il y a maintenant une trentaine d'années, à la grande époque de la
productivité "à la ligne" des programmeurs.
Cas 1 ) Un programme, fut-il en Python, ne dépend pas que des import, mais d'un ensemble d'éléments, internes ou externes au programme. Par exemple, un programme en Python sous windows, qui fera appel à des serveurs COM dépend de leur présence ; il ne fonctionnera par sous Linux, où ce genre de fonctionnalité n'existe pas. Et, donc, plus le programme est gros, plus il y a de risque de se perdre dans les dépendances. C'est une évidence, une généralité, une lapalissade.
Cas 2) Ta citation fait EXPLICITEMENT référence au nombre de lignes des programmes. Or, la compacité (vu par le nombre de lignes), n'est pas un critère de "nature". C'est ce qu'avait démontré "a contrario" Intercal, face à Cobol, il y a maintenant une trentaine d'années, à la grande époque de la productivité "à la ligne" des programmeurs.
@-salutations -- Michel Claveau
Matthieu Villeneuve
"Xavier Combelle" wrote in message news:4110bd36$0$16387$
Un langage de script est naturellement interprété car cette interprétation permet de rendre transparent les tâches effectuées.
Cela me semble confus, et/ou faux. Un _langage_ n'est pas interprete ou compile, c'est une caracteristique d'une implementation du langage. Il existe des interpreteurs C, et il est tout a fait possible d'ecrire des compilateurs Perl.
Qu'entendez-vous par "transparent" ? Comment le fait d'interpreter un programme au lieu de le compiler puis de l'executer rend les taches effectuees plus "transparentes" ?
Pour le transformer en langage de programmation, il suffit de rajouter des structures de données, du contrôle de flux et des moyens d'organiser le code (fonction, classe, modules).
C'est une distinction tout a fait arbitraire. Un langage de programmation n'est en aucune facon force de contenir ces choses.
Cette introduction, qui est majeure pour sa nature, se fait de façon assez souples dans la réalité, c'est pourquoi, des langages Python ou Perl, sont encore qualifiés de langages de script alors qu'ils on le statut de langage de programmation générale.
La aussi, c'est une distinction arbitraire, fondee sur ce qui est fait _d'habitude_ avec un langage donne. Il est tout a fait possible d'ecrire des applications tres complexes en shell Unix, et d'ecrire des programmes tres simples (remplissant des taches habituellement effectuees par des "scripts" shell) en C++.
-- Matthieu Villeneuve
"Xavier Combelle" <xavier_combelle@yahoo.fr> wrote in message
news:4110bd36$0$16387$626a14ce@news.free.fr...
Un langage de script est naturellement interprété
car cette interprétation permet de rendre transparent les tâches
effectuées.
Cela me semble confus, et/ou faux.
Un _langage_ n'est pas interprete ou compile, c'est une caracteristique
d'une implementation du langage. Il existe des interpreteurs C, et il est
tout a fait possible d'ecrire des compilateurs Perl.
Qu'entendez-vous par "transparent" ? Comment le fait d'interpreter un
programme au lieu de le compiler puis de l'executer rend les taches
effectuees plus "transparentes" ?
Pour le transformer en langage de programmation,
il suffit de rajouter des structures de données, du contrôle de flux et
des moyens d'organiser le code (fonction, classe, modules).
C'est une distinction tout a fait arbitraire. Un langage de programmation
n'est en aucune facon force de contenir ces choses.
Cette introduction, qui est majeure pour sa nature, se fait de façon
assez souples dans la réalité, c'est pourquoi, des langages Python ou
Perl, sont encore qualifiés de langages de script alors qu'ils on le
statut de langage de programmation générale.
La aussi, c'est une distinction arbitraire, fondee sur ce qui est fait
_d'habitude_ avec un langage donne. Il est tout a fait possible d'ecrire
des applications tres complexes en shell Unix, et d'ecrire des programmes
tres simples (remplissant des taches habituellement effectuees par des
"scripts" shell) en C++.
"Xavier Combelle" wrote in message news:4110bd36$0$16387$
Un langage de script est naturellement interprété car cette interprétation permet de rendre transparent les tâches effectuées.
Cela me semble confus, et/ou faux. Un _langage_ n'est pas interprete ou compile, c'est une caracteristique d'une implementation du langage. Il existe des interpreteurs C, et il est tout a fait possible d'ecrire des compilateurs Perl.
Qu'entendez-vous par "transparent" ? Comment le fait d'interpreter un programme au lieu de le compiler puis de l'executer rend les taches effectuees plus "transparentes" ?
Pour le transformer en langage de programmation, il suffit de rajouter des structures de données, du contrôle de flux et des moyens d'organiser le code (fonction, classe, modules).
C'est une distinction tout a fait arbitraire. Un langage de programmation n'est en aucune facon force de contenir ces choses.
Cette introduction, qui est majeure pour sa nature, se fait de façon assez souples dans la réalité, c'est pourquoi, des langages Python ou Perl, sont encore qualifiés de langages de script alors qu'ils on le statut de langage de programmation générale.
La aussi, c'est une distinction arbitraire, fondee sur ce qui est fait _d'habitude_ avec un langage donne. Il est tout a fait possible d'ecrire des applications tres complexes en shell Unix, et d'ecrire des programmes tres simples (remplissant des taches habituellement effectuees par des "scripts" shell) en C++.
