/* Topic des codeurs couche-tard [5] */

The Uploader · Le 05/08/2011, à 14:40

xapantu a écrit :

Ah, tu parlais de vim ? ton cas s'aggrave... tu vas avoir beaucoup de

Ouais!

tshirtman · Le 05/08/2011, à 14:53

Vim est extrèmement moderne… franchement, j'aurais du mal a bosser avec Vi, mais Vim est un logiciel qui évolue pas mal…

Pylades · Le 05/08/2011, à 16:19

.fetchmailrc

poll pop.orange.fr proto POP3:
user "me@fai.tld", with password ":P", is "paul" here options

.procmailrc

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/sh
MAILDIR=$HOME/.mail
VERBOSE=yes
ORGMAIL=$MAILDIR/fallback

:0
* ^To:.*\bme@fai\.tld\b
$MAILDIR/orange/new

Bon, ça progresse, je récupère des mails dans /var/mail/, mais pourquoi donc $MAILDIR reste-t-il vide malgré l’invocation de fetchmail ainsi : fetchmail -kavm '/usr/bin/procmail -Y -d %T' ?

grim7reaper · Le 05/08/2011, à 16:27

Chez moi MAILDIR est toujours vide (enfin si je fait echo $MAILDIR dans un shell) et ça ne me pose pas de problème.

Dernière modification par grim7reaper (Le 05/08/2011, à 16:27)

Pylades · Le 05/08/2011, à 16:30

Normal, c’est défini pour procmail, mais je veux dire que mon répertoire ~/.mail/orange/new/ ne contient rien du tout, pas plus qu’un autre, d’ailleurs…

grim7reaper · Le 05/08/2011, à 16:40

Πυλάδης a écrit :

Normal, c’est défini pour procmail, mais je veux dire que mon répertoire ~/.mail/orange/new/ ne contient rien du tout, pas plus qu’un autre, d’ailleurs…

Ha ok, ça me semblait bizarre aussi, mais comme t'avais écrit $MAILDIR…

Bon sinon t'as des infos intéressante dans .fetchmail-log et/ou dans .procmail-log ?

Ha aussi, je sais pas si ça joue mais dans mon .procmailrc j'ai un truc plus du style

$MAILDIR/orange/

pas

$MAILDIR/orange/new

Car

man 5 procmailrc a écrit :

If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliver the message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new".

Mais bon c'est ptetr pas faux non plus ce que t'as fait.

Dernière modification par grim7reaper (Le 05/08/2011, à 16:42)

Pylades · Le 05/08/2011, à 17:07

grim7reaper a écrit :

Πυλάδης a écrit :
Normal, c’est défini pour procmail, mais je veux dire que mon répertoire ~/.mail/orange/new/ ne contient rien du tout, pas plus qu’un autre, d’ailleurs…
Ha ok, ça me semblait bizarre aussi, mais comme t'avais écrit $MAILDIR…
Bon sinon t'as des infos intéressante dans .fetchmail-log et/ou dans .procmail-log ?

En mode verbeux :

fetchmail: 6.3.18 interroge pop.orange.fr (protocole POP3) à ven. 05 août 2011 17:59:37 CEST : récupération en cours
Essai de connexion avec 80.12.242.8/110...connecté.
fetchmail: POP3< +OK connected to pop3 on 2e03.me-wanadoo.net 
fetchmail: POP3> CAPA
fetchmail: POP3< +OK List of capabilities follows
fetchmail: POP3< USER
fetchmail: POP3< .
fetchmail: pop.orange.fr: échec du passage en TLS mais on continue quand-même.
fetchmail: POP3> USER me@fai.tld
fetchmail: POP3< +OK name is a valid mailbox
fetchmail: POP3> PASS *
fetchmail: POP3< +OK user exist with that password
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 1379
1 message pour me@fai.tld dans pop.orange.fr (1379 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1379
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK Message follows
lecture du message me@fai.tld@pop.orange.fr:1 parmi 1 (1379 octets) #*procmail: [4255] Fri Aug  5 17:59:43 2011
procmail: Assigning "ORGMAIL=/home/paul/.mail/fallback/"
procmail: No match on "^To:.*\bme@fai\.tld\b"
procmail: Locking "/var/mail/paul.lock"
procmail: Assigning "LASTFOLDER=/var/mail/paul"
procmail: Opening "/var/mail/paul"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/mail/paul.lock"
procmail: Notified comsat: "paul@4641:/var/mail/paul"
From paul  Fri Aug  5 17:59:43 2011
 Subject: test
  Folder: /var/mail/paul                           1546
 non éliminé
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.3.18 interroge pop.orange.fr (protocole POP3) à ven. 05 août 2011 17:59:43 CEST : interrogation finie
fetchmail: fin normale, état 0

Bon déjà ça serait bien de savoir pourquoi il ne match pas sur le champ « To » ; et ensuite de savoir pourquoi il ne fallback pas sur ~/.mail/fallback/…

grim7reaper a écrit :

Ha aussi, je sais pas si ça joue mais dans mon .procmailrc j'ai un truc plus du style
$MAILDIR/orange/
pas
$MAILDIR/orange/new
Car
man 5 procmailrc a écrit :
If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliver the message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new".
Mais bon c'est ptetr pas faux non plus ce que t'as fait.

Ben, je faisais comme lui ; mais j’ai corrigé et ça ne change rien…

grim7reaper · Le 05/08/2011, à 17:18

Πυλάδης a écrit :

Bon déjà ça serait bien de savoir pourquoi il ne match pas sur le champ « To » ;

T'as voulu te la péter avec tes '\b', mais t'es sûr que c'est supporté ?
Édit : bon après vérif' oui, c'est supporté. Cela dit, essaye quand même sans juste pour voir si ça change quelque chose ou pas.

Πυλάδης a écrit :

et ensuite de savoir pourquoi il ne fallback pas sur ~/.mail/fallback/…

C'est quoi ta règle pour fallback ?

Dernière modification par grim7reaper (Le 05/08/2011, à 17:20)

xapantu · Le 05/08/2011, à 18:49

Il y a quelques temps, quelqu'un avait parlé des _ dans les fonctions en C... (Πυλάδης je crois) Quelqu'un a un lien sur le sujet ? on peut compiler en utiliser des fonction _foo() qui sont dans une bibliothèque ? Ou bien c'est interdit ?

grim7reaper · Le 05/08/2011, à 19:10

Est-ce que ça :

ISO/IEC 9899:TC3 a écrit :

7.1.3 Reserved identiﬁers
Each header declares or deﬁnes all identiﬁers listed in its associated subclause, and optionally declares or deﬁnes identiﬁers listed in its associated future library directions subclause and identiﬁers which are always reserved either for any use or for use as ﬁle scope identiﬁers.
— All identiﬁers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
— All identiﬁers that begin with an underscore are always reserved for use as identiﬁers with ﬁle scope in both the ordinary and tag name spaces.
— Each macro name in any of the following subclauses (including the future library directions) is reserved for use as speciﬁed if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).
— All identiﬁers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identiﬁers with external linkage.160)
— Each identiﬁer with ﬁle scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identiﬁer with ﬁle scope in the same name space if any of its associated headers is included.
No other identiﬁers are reserved. If the program declares or deﬁnes an identiﬁer in a context in which it is reserved (other than as allowed by 7.1.4), or deﬁnes a reserved identiﬁer as a macro name, the behavior is undeﬁned.
If the program removes (with #undef) any macro deﬁnition of an identiﬁer in the ﬁrst group listed above, the behavior is undeﬁned.

Répond à ta question ?

Dernière modification par grim7reaper (Le 05/08/2011, à 19:13)

xapantu · Le 05/08/2011, à 19:52

Oui, à peu près, merci Je ne comprends pas vraiment comment on peut accéder aux fonctions _gtk, c'est bizarre parce que je suis sûr que c'est possible (et ce qui tu as cité n'a pas l'air de l'interdire, même si je ne comprends pas tout), mais gcc me dit que ça n'existe pas. Avec le même fichier source pourtant

Je vais regarder les options de gcc, mais je n'avais pas trouvé...

grim7reaper · Le 05/08/2011, à 20:14

Interdit peut‑être pas, mais c’est très limité niveau usage (« All identiﬁers that begin with an underscore are always reserved for use as identiﬁers with ﬁle scope »).
Et en pratique, il vaut mieux ne jamais le faire (Cf. ici, section File Scope Objects).

T’es vraiment sûr que tu est censé avoir accès à des fonctions dont le nom commence par '_', j’ai un doute.

Dernière modification par grim7reaper (Le 05/08/2011, à 20:15)

xapantu · Le 05/08/2011, à 20:37

En fait, ce n'est pas mon code, c'est l'exo icon view d'xfce. Pour une autre application, on avait ce fichier, qui compilait bien avec les autotools. J'essaye de le porter sur CMake, qui refuse de compiler avec ces fonctions _gtk. Alors qu'il n'y a aucune raison qu'il refuse... Je ne vois pas pourquoi, j'ai essayé de comparé les lignes de compilation, mais elles semblent à peu près identique, je ne vois vraiment pas ce qui ne va pas

Dernière modification par xapantu (Le 05/08/2011, à 20:37)

grim7reaper · Le 05/08/2011, à 20:39

C’est quoi le message d’erreur ?
C’est bien le même compilo que t’utilises ? Voire la même version ?
Idem pour les bibliothèques ?

Dernière modification par grim7reaper (Le 05/08/2011, à 20:48)

xapantu · Le 05/08/2011, à 20:40

Oui, c'est exactement pareil, le même compilo, les même bibliothèques, j'ai à côté la version en autotools qui compile parfaitement.
L'erreur, c'est:

CMakeFiles/marlin.dir/exo-icon-view.c.o: In function `exo_icon_view_buildable_custom_tag_end':
/home/xapantu/marlin-cmake/src/exo-icon-view.c:10177: undefined reference to `_gtk_cell_layout_buildable_custom_tag_end'

Et sachant qu'il y a des centaines d'appels gtk dans le programme, mais ce sont les seuls avec un _.

Dernière modification par xapantu (Le 05/08/2011, à 20:46)

grim7reaper · Le 05/08/2011, à 20:46

Et en compil « à‑la‑main » ça donne quoi ?
Passe ou pas pas ?
Si ça passe pas non plus, c’est sûrement que les autohell font une bidouille quelconque quelque part…

Sinon l’erreur semble plus ou moins coller avec les histoires de file scope dont on parlait plus haut.

Dernière modification par grim7reaper (Le 05/08/2011, à 20:47)

xapantu · Le 05/08/2011, à 20:50

Nan, à la main, ça passe pas
Je vais aller re-lire la commande des autotools, à tout hasard...

xapantu · Le 05/08/2011, à 21:01

Oo Ça passe en rajoutant -O2 ?! C'est vraiment bizarre ce truc décidément...

grim7reaper · Le 05/08/2011, à 21:10

Possible que la fonction soit inliné ou un truc du genre, du coup pas d'appel de fonction donc pas de problème de référence (bon là je dit peut‑être n'importe quoi, mais ça doit être un truc en rapport avec l'optimisation).
En tout cas c'est un très mauvais code ça, le comportement est clairement imprévisible (quand tu vois que ça passe pas sur le même compilo selon les options, jte le laisse imaginer si t'utilise un autre compilo).

Dernière modification par grim7reaper (Le 05/08/2011, à 21:11)

helly · Le 05/08/2011, à 21:12

Bon et sinon, ma nouvelle version d’Énigma, z’en pensez quoi alors ?

grim7reaper · Le 05/08/2011, à 21:15

Pas encore penché dessus, j’y regarderai ptêtre ce soir.

Tfaçon me semble qu’actuellement t’as d'autres choses à faire que coder ;-)

Pylades · Le 05/08/2011, à 21:16

grim7reaper a écrit :

Πυλάδης a écrit :
Bon déjà ça serait bien de savoir pourquoi il ne match pas sur le champ « To » ;
T'as voulu te la péter avec tes '\b', mais t'es sûr que c'est supporté ?
Édit : bon après vérif' oui, c'est supporté. Cela dit, essaye quand même sans juste pour voir si ça change quelque chose ou pas.

Ouais bah en fait ça utilisait les formes Gnu. -_-" Donc « \< » et « \> ».

grim7reaper a écrit :

Πυλάδης a écrit :
et ensuite de savoir pourquoi il ne fallback pas sur ~/.mail/fallback/…
C'est quoi ta règle pour fallback ?

Ben là encore j’ai lu de la mauvaise doc, en fait je mettais ORGMAIL=$MAILDIR/fallback/ mais en fait il fallait tout simplement mettre DEFAULT=fallback/.

Donc ça fonctionne, là. \o/

grim7reaper · Le 05/08/2011, à 21:22

Πυλάδης a écrit :

grim7reaper a écrit :
Πυλάδης a écrit :
Bon déjà ça serait bien de savoir pourquoi il ne match pas sur le champ « To » ;
T'as voulu te la péter avec tes '\b', mais t'es sûr que c'est supporté ?
Édit : bon après vérif' oui, c'est supporté. Cela dit, essaye quand même sans juste pour voir si ça change quelque chose ou pas.
Ouais bah en fait ça utilisait les formes Gnu. -_-" Donc « \< » et « \> ».

Ha ouais. J'avais mal lu, effectivement c'est pas \b et \B qui sont supportés mais bien \> et \<

Πυλάδης a écrit :

grim7reaper a écrit :
Πυλάδης a écrit :
et ensuite de savoir pourquoi il ne fallback pas sur ~/.mail/fallback/…
C'est quoi ta règle pour fallback ?
Ben là encore j’ai lu de la mauvaise doc

Comme quoi les tutos…
Rien ne vaut la doc au final (même si c’est moins sympa à lire), mais c’est vrai qu’un tuto aide à débroussailler.

Pylades · Le 05/08/2011, à 21:23

Euh… après réflexions ce n’est peut-être même pas les formes Gnu, qu’il utilise, en fait. Peut-être qu’il y cherche les « < » et « > » littéraux.
C’est tellement bizarre, cette affaire…

Édit : ah bah si tu confirmes, je ne vais pas plus loin alors. ^^

Dernière modification par Πυλάδης (Le 05/08/2011, à 21:24)

grim7reaper · Le 05/08/2011, à 21:26

Πυλάδης a écrit :

Édit : ah bah si tu confirmes, je ne vais pas plus loin alors. ^^

Bah j'ai trouvé ça quoi.

man 5 procmailrc a écrit :

\< or \> Match the character before or after a word. They are merely a shorthand for `[^a-zA-Z0-9_]', but can also match newlines. Since they match actual characters, they are only suitable to delimit words, not to delimit inter-word space

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1801 Le 05/08/2011, à 14:40

Re : /* Topic des codeurs couche-tard [5] */

#1802 Le 05/08/2011, à 14:53

Re : /* Topic des codeurs couche-tard [5] */

#1803 Le 05/08/2011, à 16:19

Re : /* Topic des codeurs couche-tard [5] */

#1804 Le 05/08/2011, à 16:27

Re : /* Topic des codeurs couche-tard [5] */

#1805 Le 05/08/2011, à 16:30

Re : /* Topic des codeurs couche-tard [5] */

#1806 Le 05/08/2011, à 16:40

Re : /* Topic des codeurs couche-tard [5] */

#1807 Le 05/08/2011, à 17:07

Re : /* Topic des codeurs couche-tard [5] */

#1808 Le 05/08/2011, à 17:18

Re : /* Topic des codeurs couche-tard [5] */

#1809 Le 05/08/2011, à 18:49

Re : /* Topic des codeurs couche-tard [5] */

#1810 Le 05/08/2011, à 19:10

Re : /* Topic des codeurs couche-tard [5] */

#1811 Le 05/08/2011, à 19:52

Re : /* Topic des codeurs couche-tard [5] */

#1812 Le 05/08/2011, à 20:14

Re : /* Topic des codeurs couche-tard [5] */

#1813 Le 05/08/2011, à 20:37

Re : /* Topic des codeurs couche-tard [5] */

#1814 Le 05/08/2011, à 20:39

Re : /* Topic des codeurs couche-tard [5] */

#1815 Le 05/08/2011, à 20:40

Re : /* Topic des codeurs couche-tard [5] */

#1816 Le 05/08/2011, à 20:46

Re : /* Topic des codeurs couche-tard [5] */

#1817 Le 05/08/2011, à 20:50

Re : /* Topic des codeurs couche-tard [5] */

#1818 Le 05/08/2011, à 21:01

Re : /* Topic des codeurs couche-tard [5] */

#1819 Le 05/08/2011, à 21:10

Re : /* Topic des codeurs couche-tard [5] */

#1820 Le 05/08/2011, à 21:12

Re : /* Topic des codeurs couche-tard [5] */

#1821 Le 05/08/2011, à 21:15

Re : /* Topic des codeurs couche-tard [5] */

#1822 Le 05/08/2011, à 21:16

Re : /* Topic des codeurs couche-tard [5] */

#1823 Le 05/08/2011, à 21:22

Re : /* Topic des codeurs couche-tard [5] */

#1824 Le 05/08/2011, à 21:23

Re : /* Topic des codeurs couche-tard [5] */

#1825 Le 05/08/2011, à 21:26

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums