C'est parce que par défaut, bash considère que l'espace est un séparateur de champ, donc il ne le traite pas comme un caractère.
Pour que ça fonctionne, il te faudrait faire avant ta boucle while :
OLDIFS=IFS
IFS=''
Tu sauvegardes l'ancienne valeur du séparateur de champ (variable IFS), et tu la set à ''
Ensuite tu fais ta boucle while, et après la boucle while, tu restitues l'ancienne valeur (pour éviter les problèmes si la suite de ton script s'attend à avoir un séparateur de champ standard) :
IFS=OLDIFS
Voici ce qu'en dit la man de bash:
IFS The Internal Field Separator that is used for word splitting after expansion and to split lines into words with the read builtin command. The default value is ``''.
En effet, github, c'est aussi un service payant aux entreprises, et je pense que c'est surtout ça qui intéresse Microsoft.Et je suis d'avis qu'ils n'on rien à faire que les projets libres migrent ailleurs. Maintenant, ce qui est bien c'est qu'il y a des alternatives viables qui permettent de migrer si on n'aime pas Microsoft.
Certes, mais il utilise explicitement bash, il n'y a donc pas de raison de s'interdire l'utilisation de [[, qui a l'avantage d'être une construction du langage (voir la documentation de bash), ce qui évite notamment de lancer une commande à chaque fois.
Disons que pour une raison que j'ignore, lorsque j'ai testé le [[ avec bash, ça n'a pas marché, et j'en ai déduit que bash ne prenait pas cette construction. J'ai été conforté dans mon erreur par le messae du posteur initial qui disait :
./diap_users.sh: line 23: [[ : commande introuvable
Je n'avais pas percuté que le shell voulait utiliser la commande '[[ ' (double crochet avec espace derrière), j'en ai donc conclu à tort que les doubles crochets n'étaient pas reconnus par bash.
Cependant après avoir retesté, j'ai vu que ça fonctionnait, donc ma remarque sur le fait que bash ne reconnaisse pas le double crochet est donc erronée.
Maintenant, sur le fait d'utiliser des spécificités d'un shell donné, je suis assez partagé : personnellement, dans le cas de la syntaxe des tests, je préfère largement (et recommande grandement) d'utiliser la syntaxe qui sera reconnue par le plus grand nombre de shell possible: ça évite de se prendre la tête quand on passe d'un environnement à un autre. Par contre, je suis moins catégorique sur les spécificités avancées d'un shell par rapport à un autre, car celles-ci peuvent rendre bien des services, et là c'est du cas par cas : si la façon de faire la plus générale ne complique pas trop les choses, j'opterai pour cette façon de faire, mais si le shell que j'utilise permet de simplifier grandement la résolution d'un problème donné par une de ses spécificités (ou qu'une spécificité rende le code beaucoup plus lisible), j'adopterai sans hésiter cette façon de faire.
… aujourd'hui, il y a netcat (nc) qui est beaucoup plus puissant et pratique.
Cela dit il y a une lib telnetlib dans python. Maintenant, qu'est-ce que tu entends par "effectuer un format" ?
Oups, je viens de tester, et avec bash aussi, le fonctionne (alors que j'ai essayé quelques minutes avant et ça ne fonctionnait pas. J'ai du faire une erreur …).
A noter que le test avec est disponible sous ksh, mais je n'ai pas l'impression qu'il le soit sous bash, a moins d'activer une option quelconque que je ne connais pas.
pour changer l'UUID, le mieux ca reste de reformater la partition
Euh, pas bien de racconter des bêtises comme ça :
man tune2fs :
-U UUID
Set the universally unique identifier (UUID) of the filesystem to UUID. The format of the UUID is a series of hex digits separated by hyphens, like this: "c1b9d5a2-f162-11cf-9ece-0020afc76f16". The UUID parameter may also be one of the following:
clear clear the filesystem UUID
random generate a new randomly-generated UUID
time generate a new time-based UUID
The UUID may be used by mount(8), fsck(8), and /etc/fstab(5) (and possibly others) by specifying UUID=uuid instead of a block special device name like /dev/hda1.
See uuidgen(8) for more information. If the system does not have a good random number generator such as /dev/random or /dev/urandom, tune2fs will automatically use a time-based UUID instead of a randomly-generated UUID.
Je crois qu'Anthony a commencé à t'aider. Le problème en programmation, ce n'est pas d'apprendre un langage, mais de décomposer le problème en un ensemble d'éléments plus simples. Et bien souvent, un papier et un crayon suffisent : il faut se dire, comme le fait Anthony :
- comment est-ce que je fais ?
puis pour chaque élément de réponse, se reposer la question, jusqu'à ce qu'on ne puisse plus décomposer les étapes.
Non, ce n'est pas une bonne décomposition : Je voudrais la démarche effectuée pour faire l'exercice sans ordinateur : comment faire avec un cahier et un styleo (le cours de maths, quoi).
si c'est un ayant-droit qui vient voir LinuxFr et donc son directeur de publication donc moi, ça m'embête un peu.
Ben tu as la même problématique si un ayant-droit vient te voir pour un lien vers une image lui appartenant non ? Que l'image soit sur linuxfr ou ailleurs, qu'est-ce que ça change ? (c'est une vraie question, car de mon point de vue ça ne change pas grand chose, mais il y a certainement quelque chose qui m'échappe).
Après, le problème d'utilisation (pas de vol, parce que pour moi ce n'est pas du vol) de bande passante, je l'ai bien compris.
Exemple, tu utilises le logo linuxfr comme avatar externe sur un site a fort audience. Résultat les serveurs de LinuxFR vont se taper un trafique réseau abusé voir même une charge CPU (pour les fichiers hébergés derrière des scripts PHP comme avec phpBB ou nextcloud par exemple). Et ce, sans rien fournir aux utilisateurs/clients de linuxfr.
ben dans ce cas ce n'est pas du vol de bande passante, tout comme copier un fichier sous droit d'auteur n'est pas du vol. Sinon on rentre dans le même délire que les soi-disants ayants-droits qui veulent mettre en place des redevances sur les liens vers leurs sites, ou tout autre truc du genre.
il y a la modération, pour éviter les images déposées en violation de leur licence, les pubs, les images non autorisées pour les mineurs, les images déposées sur le site uniquement pour pouvoir les utiliser depuis un autre site, les images haineuses, etc.
Je comprends les raisons invoquées, mais je ne suis pas certain que le fait de mettre a disposition l'image sur un stockage propre a linuxfr ou mettre à dispo un lien vers ces contenus soit différentes pour les contrainters légales.
Pour les "images déposées sur le site uniquement pour pouvoir les utiliser depuis un autre site": effectivemet, cet aspect peut poser problème. Il doit être possible techniquement de l'empêcher (j'ai bien en tête quelques idées, et je suis sûr que ça se fait déjà, d'ailleurs si certains ici connaissent ces techniques, je serais intéressé), mais je comprends qu'une mise en place technique puisse prendre beaucoup de temps et d'énergie pour un résultat qui ne serait pas 100% fiable.
Effectivement, on peut en discuter mais on peut considérer que par convention, historiquement, les lignes de commandes sous Unix partent du principe que l'utilisateur sait ce qu'il fait. Après on peut effectivement metttre en place des conventions d'alias ou de commandes "débutant" qui demandent confirmation à tout va et des alias ou commandes "avancées" qui ne demandent pas de confirmation.
L'autre raison de la non demande de confirmation des commandes shell est le fait que celles-ci doivent pouvoir être exécutées dans un script, dans ce cas de figure la demande de confirmation est problématique.
C'est plus le concept de "vol de bande passante" que j'ai du mal à comprendre. Pour le reste, je lirai à tête reposée, mais le fait de se plaindre que des images soient utilisées sans respect de la licence associée ne me gène pas.
On s'en fout. Complètement. Tu es profondément injuste.
Ben non, absolument pas, faut arrêter la dérespnsabilisation, d'autant plus que laplupart des gens cliquent sur "suivant, suivant, …" sans prendre la peine de lire ce qui est écrit (je ne parle pas de non compréhension, mais de ne pas lire). Ce raisonnement, qui consiste à deresponsabiliser les gens commence à me gaver, et rend les gens de plus en plus stupides. A un moment faut arrêter : dans le cas précis, tu as un processus d'installation, il te donne des indications, si tu ne les lis pas, c'est pas la faute de la machine. C'est la responsabilité de la personne qui décide de ne pas suivre les instructions ou de les ignorer.
Là, l'utilisateur ne voulait pas perdre ses données, et pourtant, la machine a perdu ses données.
parce qu'il n'a PAS lu que ses données peuvent être perdues. La machine lui a dit, mais il a décidé de ne pas écouter la machine.
La machine a mal communiqué, son interface était inadaptée, le protocole qu'elle a suivi était suffisamment confus pour que l'utilisateur ait pu, par erreur, cliquer sur un truc qui a fait que la machine a fait le contraire de ce que souhaitait l'utilsateur.
Va voir la copie d'écran plus haut, tu verras que c'est clair. Et des utilisateurs qui passent leur temps a faire suivant, suivant ok sans lire, j'en vois tous les jours (et j'avoue, je le fais parfois).
Dans le petit monde de l'informatique, peut-être, mais en dehors de ce monde, tu te goures complètement.
Absolument pas : si tu signes un contrat sans le lire, tu es tenu de te plier aux clauses de ce contrat. Idem pour le code de la route : il y a des signalisations (panneaux, lignes au sol) et si tu ne les regardes pas c'est de ta responsabilité.
c'est totalement anormal qu'un ordinateur puisse nuire de manière évidente à son utilisateur, et ce, même si l'utilisateur a fait une erreur.
Je crois que celle-là, elle est à encadrer. Dans le cas précis, je suis sur à 99% que lors de la réinstallation, l'utilisateur n'a pas bien lu ce que l'ordinateur lui disait (comme beaucoup de personnes qui se disent débutantes, et qui peuvent être intelligentes et brillantes par ailleurs et qui en viennent à perdre toute rationnalité lorsqu'elles se trouvent devant un ordinateur). La machine n'est pas là pour empêcher de faire ce que veut l'utilisateur, elle est là pour l'aider. Et si la machine dit à l'utilisateur que la procédure d'installation supprimera toues les données du disque et que l'utilisateur ne lit pas, ben c'est de sa responsabilité.
euh … ce genre de problème peut arriver sur n'importe quelle distribution. si j'ai bien compris :
- tu as eu un problème lorsque tu as tenté une mise à jour
- comme tu ne savais pas reprendre le processus en ligne de commande, tu as fait une réinstallation
- en réinstallant, tu n'as pas vu que ta partition home serait supprimé
Le point 1 n'est pas propre à Mageia, ça m'est déjà arrivé sur Ubuntu. La différence est que je sais comment faire pour relancer une installation qui a échoué (certes ça m'agace à chaque fois, mais je sais le faire). Ca arrive même avec Windows.
Le point 2 : ça peut se tenter mais c'est pas moins risqué que de tenter de rattrapper le problème à la ligne de commande.
Le point 3 : là je sens le réflexe stupide de la plupart des utilisateurs : "suivant, suivant, suvant OK" sans lire ce qui est indiqué. Et ça m'étonnerait qu'une installation de mageia n'indique pas que l'installation supprime toutes les données du disque. La plupart des distributions que j'ai essayées le font. Et tu aurais utilisé Ubuntu pour faire la même chose, tu aurais eu le même problème.
J’ai lu plus haut un commentaire bien triste disant que l’art est inutile
C'était un peu maladroit/provocateur, mais je voulais surtout opposer un outil qui à la base est un "objet dont on se sert pour effectuer un travail manuel ou mécanique, accomplir une tache déterminée ou en faciliter l'exécution", ou un "moyen d'action, ce dont on se sert pour obtenir un résultat" ( voir http://www.la-definition.fr/definition/outil ou Larousse), à une oeuvre d'art, qui n'a pas pour but d'accomplir une tache déterminée.
[^] # Re: Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 2.
C'est parce que par défaut, bash considère que l'espace est un séparateur de champ, donc il ne le traite pas comme un caractère.
Pour que ça fonctionne, il te faudrait faire avant ta boucle while :
Tu sauvegardes l'ancienne valeur du séparateur de champ (variable IFS), et tu la set à ''
Ensuite tu fais ta boucle while, et après la boucle while, tu restitues l'ancienne valeur (pour éviter les problèmes si la suite de ton script s'attend à avoir un séparateur de champ standard) :
Voici ce qu'en dit la man de bash:
[^] # A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par totof2000 . En réponse au journal Microsoft rachète Github. Évalué à 6.
En effet, github, c'est aussi un service payant aux entreprises, et je pense que c'est surtout ça qui intéresse Microsoft.Et je suis d'avis qu'ils n'on rien à faire que les projets libres migrent ailleurs. Maintenant, ce qui est bien c'est qu'il y a des alternatives viables qui permettent de migrer si on n'aime pas Microsoft.
[^] # Re: Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 2.
Disons que pour une raison que j'ignore, lorsque j'ai testé le [[ avec bash, ça n'a pas marché, et j'en ai déduit que bash ne prenait pas cette construction. J'ai été conforté dans mon erreur par le messae du posteur initial qui disait :
Je n'avais pas percuté que le shell voulait utiliser la commande '[[ ' (double crochet avec espace derrière), j'en ai donc conclu à tort que les doubles crochets n'étaient pas reconnus par bash.
Cependant après avoir retesté, j'ai vu que ça fonctionnait, donc ma remarque sur le fait que bash ne reconnaisse pas le double crochet est donc erronée.
Maintenant, sur le fait d'utiliser des spécificités d'un shell donné, je suis assez partagé : personnellement, dans le cas de la syntaxe des tests, je préfère largement (et recommande grandement) d'utiliser la syntaxe qui sera reconnue par le plus grand nombre de shell possible: ça évite de se prendre la tête quand on passe d'un environnement à un autre. Par contre, je suis moins catégorique sur les spécificités avancées d'un shell par rapport à un autre, car celles-ci peuvent rendre bien des services, et là c'est du cas par cas : si la façon de faire la plus générale ne complique pas trop les choses, j'opterai pour cette façon de faire, mais si le shell que j'utilise permet de simplifier grandement la résolution d'un problème donné par une de ses spécificités (ou qu'une spécificité rende le code beaucoup plus lisible), j'adopterai sans hésiter cette façon de faire.
[^] # Re: Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 2.
Ca c'est le problème que je n'avais pas vu : tu utilise des opérateurs de tests numériques.
man test :
Pour des tests sur des chaines (toujours d'après le man):
# on oublie telnet ....
Posté par totof2000 . En réponse au message Question script. Évalué à 3.
… aujourd'hui, il y a netcat (nc) qui est beaucoup plus puissant et pratique.
Cela dit il y a une lib telnetlib dans python. Maintenant, qu'est-ce que tu entends par "effectuer un format" ?
[^] # Re: Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 2.
Oups, je viens de tester, et avec bash aussi, le fonctionne (alors que j'ai essayé quelques minutes avant et ça ne fonctionnait pas. J'ai du faire une erreur …).
[^] # Re: Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 2.
A noter que le test avec est disponible sous ksh, mais je n'ai pas l'impression qu'il le soit sous bash, a moins d'activer une option quelconque que je ne connais pas.
# Remplace les doubles crochets par des simples dans ton test , et mettre un espace ...
Posté par totof2000 . En réponse au message Problème de script SHELL. Évalué à 4.
.. entre ton crochet et le premier terme de ton test.
devient
En effet '[' est une commande (soit sur le système de fichier, soit une commande interne du shell).
Pour t'en convaincre : :
[^] # Re: bootloader pas installé
Posté par totof2000 . En réponse au message changer de disque systeme. Évalué à 7.
Euh, pas bien de racconter des bêtises comme ça :
[^] # Re: Je veux bien te le faire ....
Posté par totof2000 . En réponse au message Exercice Python. Évalué à 2.
Je crois qu'Anthony a commencé à t'aider. Le problème en programmation, ce n'est pas d'apprendre un langage, mais de décomposer le problème en un ensemble d'éléments plus simples. Et bien souvent, un papier et un crayon suffisent : il faut se dire, comme le fait Anthony :
- comment est-ce que je fais ?
puis pour chaque élément de réponse, se reposer la question, jusqu'à ce qu'on ne puisse plus décomposer les étapes.
[^] # Re: Je veux bien te le faire ....
Posté par totof2000 . En réponse au message Exercice Python. Évalué à 2.
Non, ce n'est pas une bonne décomposition : Je voudrais la démarche effectuée pour faire l'exercice sans ordinateur : comment faire avec un cahier et un styleo (le cours de maths, quoi).
# Je veux bien te le faire ....
Posté par totof2000 . En réponse au message Exercice Python. Évalué à 7. Dernière modification le 20 mai 2018 à 18:01.
… pour 60 euros de l'heure. toute heure comencée est due.
Sinon, sans parler de python, comment décomposerais-tu le problème ? Quelle est la méthode pour faire cet exercice sans ordinateur?
[^] # Re: toi meme
Posté par totof2000 . En réponse au message hébergeur image gratuit sans tracking. Évalué à 3. Dernière modification le 20 mai 2018 à 17:58.
Ben tu as la même problématique si un ayant-droit vient te voir pour un lien vers une image lui appartenant non ? Que l'image soit sur linuxfr ou ailleurs, qu'est-ce que ça change ? (c'est une vraie question, car de mon point de vue ça ne change pas grand chose, mais il y a certainement quelque chose qui m'échappe).
Après, le problème d'utilisation (pas de vol, parce que pour moi ce n'est pas du vol) de bande passante, je l'ai bien compris.
[^] # Re: toi meme
Posté par totof2000 . En réponse au message hébergeur image gratuit sans tracking. Évalué à 1.
ben dans ce cas ce n'est pas du vol de bande passante, tout comme copier un fichier sous droit d'auteur n'est pas du vol. Sinon on rentre dans le même délire que les soi-disants ayants-droits qui veulent mettre en place des redevances sur les liens vers leurs sites, ou tout autre truc du genre.
[^] # Re: toi meme
Posté par totof2000 . En réponse au message hébergeur image gratuit sans tracking. Évalué à 1.
Je comprends les raisons invoquées, mais je ne suis pas certain que le fait de mettre a disposition l'image sur un stockage propre a linuxfr ou mettre à dispo un lien vers ces contenus soit différentes pour les contrainters légales.
Pour les "images déposées sur le site uniquement pour pouvoir les utiliser depuis un autre site": effectivemet, cet aspect peut poser problème. Il doit être possible techniquement de l'empêcher (j'ai bien en tête quelques idées, et je suis sûr que ça se fait déjà, d'ailleurs si certains ici connaissent ces techniques, je serais intéressé), mais je comprends qu'une mise en place technique puisse prendre beaucoup de temps et d'énergie pour un résultat qui ne serait pas 100% fiable.
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 3.
Effectivement, on peut en discuter mais on peut considérer que par convention, historiquement, les lignes de commandes sous Unix partent du principe que l'utilisateur sait ce qu'il fait. Après on peut effectivement metttre en place des conventions d'alias ou de commandes "débutant" qui demandent confirmation à tout va et des alias ou commandes "avancées" qui ne demandent pas de confirmation.
L'autre raison de la non demande de confirmation des commandes shell est le fait que celles-ci doivent pouvoir être exécutées dans un script, dans ce cas de figure la demande de confirmation est problématique.
[^] # Re: toi meme
Posté par totof2000 . En réponse au message hébergeur image gratuit sans tracking. Évalué à 1.
C'est plus le concept de "vol de bande passante" que j'ai du mal à comprendre. Pour le reste, je lirai à tête reposée, mais le fait de se plaindre que des images soient utilisées sans respect de la licence associée ne me gène pas.
[^] # Re: toi meme
Posté par totof2000 . En réponse au message hébergeur image gratuit sans tracking. Évalué à 4.
Faudrait qu'on m'explique le concept là …. Certes, ce n'estp as très correct, mais de là à parler de vol …
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 1. Dernière modification le 18 mai 2018 à 08:25.
En fait rien, j'avais mal compris le début de ton commentaire …
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 1.
Je ne parle pas de la partie mise à jour mais de la partie "réinstallation".
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 7.
Ben non, absolument pas, faut arrêter la dérespnsabilisation, d'autant plus que laplupart des gens cliquent sur "suivant, suivant, …" sans prendre la peine de lire ce qui est écrit (je ne parle pas de non compréhension, mais de ne pas lire). Ce raisonnement, qui consiste à deresponsabiliser les gens commence à me gaver, et rend les gens de plus en plus stupides. A un moment faut arrêter : dans le cas précis, tu as un processus d'installation, il te donne des indications, si tu ne les lis pas, c'est pas la faute de la machine. C'est la responsabilité de la personne qui décide de ne pas suivre les instructions ou de les ignorer.
Va voir la copie d'écran plus haut, tu verras que c'est clair. Et des utilisateurs qui passent leur temps a faire suivant, suivant ok sans lire, j'en vois tous les jours (et j'avoue, je le fais parfois).
Absolument pas : si tu signes un contrat sans le lire, tu es tenu de te plier aux clauses de ce contrat. Idem pour le code de la route : il y a des signalisations (panneaux, lignes au sol) et si tu ne les regardes pas c'est de ta responsabilité.
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 3.
Si le processus d'installation lui a indiqué qu'il allait perdre ses données, et quil ne l'a pas lu, la distrib, elle fait quoi ?
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 2.
Je crois que celle-là, elle est à encadrer. Dans le cas précis, je suis sur à 99% que lors de la réinstallation, l'utilisateur n'a pas bien lu ce que l'ordinateur lui disait (comme beaucoup de personnes qui se disent débutantes, et qui peuvent être intelligentes et brillantes par ailleurs et qui en viennent à perdre toute rationnalité lorsqu'elles se trouvent devant un ordinateur). La machine n'est pas là pour empêcher de faire ce que veut l'utilisateur, elle est là pour l'aider. Et si la machine dit à l'utilisateur que la procédure d'installation supprimera toues les données du disque et que l'utilisateur ne lit pas, ben c'est de sa responsabilité.
[^] # Re: Quel est vraiment la nature du problème ?
Posté par totof2000 . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 6.
euh … ce genre de problème peut arriver sur n'importe quelle distribution. si j'ai bien compris :
- tu as eu un problème lorsque tu as tenté une mise à jour
- comme tu ne savais pas reprendre le processus en ligne de commande, tu as fait une réinstallation
- en réinstallant, tu n'as pas vu que ta partition home serait supprimé
Le point 1 n'est pas propre à Mageia, ça m'est déjà arrivé sur Ubuntu. La différence est que je sais comment faire pour relancer une installation qui a échoué (certes ça m'agace à chaque fois, mais je sais le faire). Ca arrive même avec Windows.
Le point 2 : ça peut se tenter mais c'est pas moins risqué que de tenter de rattrapper le problème à la ligne de commande.
Le point 3 : là je sens le réflexe stupide de la plupart des utilisateurs : "suivant, suivant, suvant OK" sans lire ce qui est indiqué. Et ça m'étonnerait qu'une installation de mageia n'indique pas que l'installation supprime toutes les données du disque. La plupart des distributions que j'ai essayées le font. Et tu aurais utilisé Ubuntu pour faire la même chose, tu aurais eu le même problème.
[^] # Re: Pourquoi opposer œuvre d’art et outil ?
Posté par totof2000 . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 1.
C'était un peu maladroit/provocateur, mais je voulais surtout opposer un outil qui à la base est un "objet dont on se sert pour effectuer un travail manuel ou mécanique, accomplir une tache déterminée ou en faciliter l'exécution", ou un "moyen d'action, ce dont on se sert pour obtenir un résultat" ( voir http://www.la-definition.fr/definition/outil ou Larousse), à une oeuvre d'art, qui n'a pas pour but d'accomplir une tache déterminée.