Re: [résolu] interpreter $var mais pas !d
Christophe Martin wrote: [...]
var='un truc'; sed -e "/$var/ !d"
[zap] bizrae tout de meme cette interpretation de !d entre " ... je ne peux pas tester, suis pas chez moi, mais les simple quote devraient fonctionner
sed -e "/$var"'/!d'
yep, ça marche sed -e "/$var/"' !d' aussi (j'avais dû tester avec un espace entre " et '... en faisant un truc genre sed -e "/$var/" '!d' qui marche pas) Daniel
Christophe
On lun 28 août, Daniel C wrote:
Christophe Martin wrote: [...]
var='un truc'; sed -e "/$var/ !d"
[zap] bizrae tout de meme cette interpretation de !d entre " ... je ne peux pas tester, suis pas chez moi, mais les simple quote devraient fonctionner
sed -e "/$var"'/!d'
yep, ça marche sed -e "/$var/"' !d' aussi (j'avais dû tester avec un espace entre " et '... en faisant un truc genre sed -e "/$var/" '!d' qui marche pas)
Je pense que faire une page sur le quoting dans le wiki ne serait pas de trop, perso des fois je pête un plomb avec des quotes dans des quotes dans des quotes :/ Daniel, je te sens motivé pour commencer la section [1], qu'en penses tu ? :) [1] http://cli.asyd.net/home/shell/common/quoting -- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking Solaris User Group
Bruno Bonfils wrote:
Je pense que faire une page sur le quoting dans le wiki ne serait pas de trop, perso des fois je pête un plomb avec des quotes dans des quotes dans des quotes :/
Daniel, je te sens motivé pour commencer la section [1], qu'en penses tu ? :)
Euh, motivé ? why not ;-) mais compétent, ça reste à voir... à part le traditionnel "le bash interprête les chaînes entre " et pas celle entre ', je vois pas trop quoi raconter... Bon, j'essaierai de faire un truc avec aussi le nb d'escape qu'il faut suivant les cas (mais il faudra relire, parce que je me plante 1fois/2 et j'en revient à essayer à chaque fois), mais pas aujourd'hui. Sinon, il est indiqué que bash est le shell par défaut de MacOS X sur http://cli.asyd.net/home/shell/bash mais sur http://cli.asyd.net/home/shell/tcsh il est indiqué que c'est tcsh... Je laisse celui qui sait corriger. Je veux bien faire un essai, mais c'est bien parce que vous utilisez "notre" template dokuwiki (NeoLao est notre developpeur/designer maison et a fait le template lilas pour nos besoins au taf) Content que ça serve :-) A ce propos, j'ai qq questions complètement HS sur du code produit au boulot et donné en GPL ou en CC - Est ce qu'il faut une autorisation expresse de l'employeur ? (ça me parait souhaitable, mais dans pas mal de cas je me vois pas remonter au big boss et demander un papier). - L'employeur doit-il être mentionné aux cotés de l'auteur ? Daniel
On lun 28 août, Daniel C wrote:
Daniel, je te sens motivé pour commencer la section [1], qu'en penses tu [1] http://cli.asyd.net/home/shell/common/quoting
Euh, motivé ?
why not ;-) mais compétent, ça reste à voir... à part le traditionnel "le bash interprête les chaînes entre " et pas celle entre ', je vois pas trop quoi raconter...
Ben déjà, ne pas oublier de citer que l'on peut mixer les ''"" pour un seul argument, comme dans ton exemple, chose que pour ma part j'oublie facilement. Dire bien sûr que \ permet d'escaper un caractère capturé par le shell
Bon, j'essaierai de faire un truc avec aussi le nb d'escape qu'il faut suivant les cas (mais il faudra relire, parce que je me plante 1fois/2 et j'en revient à essayer à chaque fois), mais pas aujourd'hui.
Pas de problème
Je veux bien faire un essai, mais c'est bien parce que vous utilisez "notre" template dokuwiki (NeoLao est notre developpeur/designer maison et a fait le template lilas pour nos besoins au taf) Content que ça serve :-)
héhé, t'inquiète pas qu'il me sert, je l'ai mis sur zshwiki.org aussi, et il me sert aussi pour une appli (libre) que je suis en train d'écrire --my two cents qui n'ont pas beaucoup de valeur--
A ce propos, j'ai qq questions complètement HS sur du code produit au boulot et donné en GPL ou en CC
- Est ce qu'il faut une autorisation expresse de l'employeur ? (ça me parait souhaitable, mais dans pas mal de cas je me vois pas remonter au big boss et demander un papier).
Une autorisation express pour quoi ? Toute ligne de code écrite pendant les heures de travail appartient à la société, non à l'auteur (c'est du moins comme ca dans tous les contrats que j'ai signés / vus / entendu). Donc déjà... Après de mon expèrience personnelle, ca ne pose pas de problème aux sociétés quand les outils en questions ne concernent pas l'activité coeur de celles ci
- L'employeur doit-il être mentionné aux cotés de l'auteur ?
Bonne question, je ne sais pas s'il y a obligation (j'en doute), mais en tout cas il m'arrive souvent de voir des projets dans ce cas avec de nombreuses références à la société sur la page du projet (logo, + lien dédié, + page de roadmap avec présisions des features sponsorisés par la société) --my two cents qui n'ont pas beaucoup de valeur-- -- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking Solaris User Group
On lun 28 août, Daniel C wrote:
- Est ce qu'il faut une autorisation expresse de l'employeur ? (ça me parait souhaitable, mais dans pas mal de cas je me vois pas remonter au big boss et demander un papier).
Une autorisation express pour quoi ? Toute ligne de code écrite pendant les heures de travail appartient à la société, non à l'auteur (c'est du moins comme ca dans tous les contrats que j'ai signés / vus / entendu). Donc déjà... Après de mon expèrience personnelle, ca ne pose pas de problème aux sociétés quand les outils en questions ne concernent pas l'activité coeur de celles ci
En ce qui me concerne, on a une politique interne claire : si il s'agit de corriger un bug, on le fait soit en son nom propre (genre si c'est rapide), soit (après validation de la boite pour avoir son nom collé au projet) au nom de la boîte. L'argument de base étant que si on corrige un bug, le mieux c'est que ce soit intégré par les développeurs amont, sinon on risque d'avoir à le re-corriger ou pire, le patch risque de ne plus passer pour cause de changement en amont sur une version ultérieure. C'est le genre de situation qui devient ingérable assez rapidement parce qu'on se retrouve à faire un fork de facto pour utiliser en interne le projet en question... C'est rarement le but recherché quand on fait du code libre. Après, pour ce qui est d'une vraie amélioration ça dépend du projet et de l'amélioration : pour les mêmes raisons que précédemment, on peut pousser pour tenter de faire accepter du code par les dev amonts, histoire de ne pas avoir à maintenir une version parallèle. Après, tout dépend du client, du projet, etc. Quand je veux faire passer un petit patch rapidement, je le fais en mon nom en dehors des heures de travail avec l'accord tacite de mon employeur, parce que ça simplifie la vie de tout le monde ;)
- L'employeur doit-il être mentionné aux cotés de l'auteur ?
Bonne question, je ne sais pas s'il y a obligation (j'en doute), mais en tout cas il m'arrive souvent de voir des projets dans ce cas avec de nombreuses références à la société sur la page du projet (logo, + lien dédié, + page de roadmap avec présisions des features sponsorisés par la société) --my two cents qui n'ont pas beaucoup de valeur--
Le contrat voudrait que oui, puisque quand le code est écrit durant les heures de travail l'ayant droit est l'employeur. Après tout dépend du projet et de la stratégie de l'employeur, il peut ne pas vouloir faire de publicité au fait qu'il contribue à tel ou tel projet. Par exemple, quand le temps passé sur le projet en question va être refacturé à un client : le client peut ne pas apprécier de payer pour une modif sur laquelle il n'a pas l'exclusivité. Donc à discuter au cas par cas avec les responsables de la boite et du projet :) après, YMMV :) -- Clément Hermann (nodens)
Bruno Bonfils wrote:
A ce propos, j'ai qq questions complètement HS sur du code produit au boulot et donné en GPL ou en CC
- Est ce qu'il faut une autorisation expresse de l'employeur ? (ça me parait souhaitable, mais dans pas mal de cas je me vois pas remonter au big boss et demander un papier).
Une autorisation express pour quoi ? Toute ligne de code écrite pendant les heures de travail appartient à la société, non à l'auteur (c'est du moins comme ca dans tous les contrats que j'ai signés / vus / entendu).
Oui, mais quand ta société n'est pas une boite d'informatique, c'est précisé nulle part. Pour NeoLao c'est un peu particulier parce qu'il a pas mal de projets persos, dont il réutilise des morceaux au taf, et il utilise des trucs appris au boulot pour ses trucs persos (et pour le moment tout le monde y gagne). Quand il file un skin dokuwiki en CC, ça va être dur de prouver qu'il l'a fait sur ses heures de boulot (car ce n'est que partiellement vrai/faux), et à part lui et moi, je vois pas qui pourrait répondre à la question... Bref, je ne crains pas les foudres de mon employeur, je ne pense pas le voler, mais j'aimerais faire les choses proprement.
Donc déjà... Après de mon expèrience personnelle, ca ne pose pas de problème aux sociétés quand les outils en questions ne concernent pas l'activité coeur de celles ci
Dans certains cas, l'utilisation de briques GPL l'oblige quand même. Je dois d'ailleurs relire tout ça pour savoir à partir de quand une "surcouche" d'une appli GPL doit être GPL (par exemple, un skin dokuwiki qui ajouterait de nouvelles fonctionnalités, sans modifier le code source ne devrait pas avoir besoin d'être GPL, mais si on change un include par un autre dans le source initial, l'ajout devrait être GPL), ça règlera mes états d'âme vis à vis de mon employeur.
- L'employeur doit-il être mentionné aux cotés de l'auteur ?
Bonne question, je ne sais pas s'il y a obligation (j'en doute), mais en tout cas il m'arrive souvent de voir des projets dans ce cas avec de nombreuses références à la société sur la page du projet (logo, + lien dédié, + page de roadmap avec présisions des features sponsorisés par la société) --my two cents qui n'ont pas beaucoup de valeur--
C'est déjà ça. Je vais poser la question sur une autre ml pour arrêter de polluer celle-ci. Daniel
Daniel C wrote:
Je dois d'ailleurs relire tout ça pour savoir à partir de quand une "surcouche" d'une appli GPL doit être GPL (par exemple, un skin dokuwiki qui ajouterait de nouvelles fonctionnalités, sans modifier le code source ne devrait pas avoir besoin d'être GPL, mais si on change un include par un autre dans le source initial, l'ajout devrait être GPL), ça règlera mes états d'âme vis à vis de mon employeur.
Bon, après une brève relecture des classiques, le coté viral de la GPL ne s'applique que sur la redistribution. On peut modifier un soft GPL et garder la modif privée tant qu'on ne la distribue pas. Daniel
Daniel C wrote:
Daniel C wrote:
Je dois d'ailleurs relire tout ça pour savoir à partir de quand une "surcouche" d'une appli GPL doit être GPL (par exemple, un skin dokuwiki qui ajouterait de nouvelles fonctionnalités, sans modifier le code source ne devrait pas avoir besoin d'être GPL, mais si on change un include par un autre dans le source initial, l'ajout devrait être GPL), ça règlera mes états d'âme vis à vis de mon employeur.
Bon, après une brève relecture des classiques, le coté viral de la GPL ne s'applique que sur la redistribution.
On peut modifier un soft GPL et garder la modif privée tant qu'on ne la distribue pas.
Histoire de pinailler un peu, on ne doit donner le code qu'à celui à qui on redistribue... si on ne redistribue pas y'a en effet rien à faire ;) Dans ma boite, on fait parfois du code libre (pas toujours GPL mais assimilé) qu'on ne donne qu'à nos clients, et qu'on n'a jamais contribué nulle part. Bon, après, rien n'empêche nos clients de le redistribuer ou de le contribuer ailleurs à leur tour. -- Clément Hermann (nodens)
Bonjour, On 8/28/06, Daniel C <ml@editionsdidier.com> wrote:
Oui, mais quand ta société n'est pas une boite d'informatique, c'est précisé nulle part.
peu importe, c'est écrit ainsi dans le code de la propriété intellectuelle : les oeuvres des l'esprit sont la propriété de leur auteur ... sauf les logiciels, les oeuvres multimédia et les bases de données. Sauf indication contraire dans le contrat (une gentille entreprise qui écrit qu'elle donne la paternité à l'employé) tout développement informatique dans le cadre professionnel appartient à l'entreprise. Jeremy -- Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them. Please send me only open formats, as OpenDocument or pdf.
Bruno Bonfils wrote:
Daniel, je te sens motivé pour commencer la section [1], qu'en penses tu ? :)
Bon, j'ai essayé de pondre un petit qqchose, mais ça me parait vraiment basique... Je vous laisse corriger (on sait jamais), reformuler (si besoin) et surtout ajouter... Je suis tombé hier sur un autre cas bizarre que j'ai dû contourner. Je n'ai plus l'exemple précis, mais en gros, c'était var=toto result="$(echo -e "titi\ntoto\ntutu" | sed -e '/$var/ !d')" le !d était interprêté (par la dernière commande de l'historique qui commence par d) et quoi que je fasse, le !d était toujours interprêté à cause des " extérieurs (indispensable pour que le $() soit exécuté. J'ai modifié mes commandes pour contourner le pb, et je me suis aperçu ensuite que l'on pouvait passer par une variable intermédiaire : var=toto exp="/$var"'/!d' result="$(echo -e "titi\ntoto\ntutu" | sed -e $exp)" Daniel PS: concernant sed, quelqu'un peut-il expliquer pourquoi les parenthèses capturantes doivent être échappées, sinon elles prennent le rôle du caractère parenthèse. En général, tous les caractères ayant un sens particulier dans les regexp doivent être échappés pour redevenir de "simples caractères". Dans sed aussi, sauf pour les parenthèses.
echo "un texte (entre parenthèses) avec aussi des 'apostrophes'."| sed -e 's/(/#/' un texte #entre parenthèses) avec aussi des 'apostrophes'. # la parenthèse est bien un caractère ordinaire
echo "un texte (entre parenthèses) avec aussi des 'apostrophes'."| sed -e "s/.*'\(.*\)'.*/\1/" apostrophes # elle capture si on l'échappe
Etonnant non ?
On 8/30/06, Daniel C <ml@editionsdidier.com> wrote:
PS: concernant sed, quelqu'un peut-il expliquer pourquoi les parenthèses capturantes doivent être échappées, sinon elles prennent le rôle du caractère parenthèse. En général, tous les caractères ayant un sens particulier dans les regexp doivent être échappés pour redevenir de "simples caractères". Dans sed aussi, sauf pour les parenthèses.
Différence entre regexp simples et étendus dans sed : -r, --regexp-extended use extended regular expressions in the script. Jeremy -- Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them. Please send me only open formats, as OpenDocument or pdf.
participants (4)
-
Bruno Bonfils -
Clement Hermann -
Daniel C -
Jeremy Monnet