tag:blogger.com,1999:blog-62691985932648938862024-03-13T20:55:53.554-04:00Here today, blog tomorrowAnonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-6269198593264893886.post-8034003397974492702016-01-10T11:34:00.002-05:002016-01-10T11:34:42.355-05:00Twice the bits, twice the fun!<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$ dpkg --print-architecture <br />amd64</span></blockquote>
I guess it was time for me to finally join the 21st century!<br />
<br />
The process was not as painful as I had feared, but not nearly as painless as I would have hoped either. (Still, it wasn't much worse than what I've endured over the years with a half-multi-archified setup. I probably would have spared myself a lot of trouble by switching much earlier.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-3005186592097483172015-09-10T15:51:00.001-04:002015-09-10T15:51:13.476-04:00Desjardins: Vos transactions en ligne... par téléphoneJe n'ai pas pu m'empêcher de sourire devant cette contradiction:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEici7eXBZIaAy-E2ZIqvoJLImmQnM0wreckJ8VLxYrmce2T7F-fUxq2gkx2kpm6x1EKmRdX6BWIWI_0E6uDoudfganqENyundClMNY0cgrzzsD5I04DZySvNkaogqVE3YcXKy6lWHW2YTc/s1600/visa1a.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="236" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEici7eXBZIaAy-E2ZIqvoJLImmQnM0wreckJ8VLxYrmce2T7F-fUxq2gkx2kpm6x1EKmRdX6BWIWI_0E6uDoudfganqENyundClMNY0cgrzzsD5I04DZySvNkaogqVE3YcXKy6lWHW2YTc/s640/visa1a.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioShXyDLXSiTrb5kteeu1TYll_5Bb8qKD6kngMXS_olqIQ_zVgQeJspGAszg3TtHWhxVr8qLyI7ot9BI5TqyXrJA7GOjHSz-Cm3JxnDz-d5ifpdoQPEpeGsaLBVtoSgtLIgrtt3qj5s70/s1600/visa2b.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioShXyDLXSiTrb5kteeu1TYll_5Bb8qKD6kngMXS_olqIQ_zVgQeJspGAszg3TtHWhxVr8qLyI7ot9BI5TqyXrJA7GOjHSz-Cm3JxnDz-d5ifpdoQPEpeGsaLBVtoSgtLIgrtt3qj5s70/s640/visa2b.png" width="640" /></a></div>
<br />
Il s'agit probablement d'un bête oubli; la version anglophone est (surprenamment) plus complète :<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDD18zApFuTZVdUBXpj4rQq2CL1qNgtt7yXDjkD8S9eDZH_6wq4swHG5k67ANsv43OaliId4BfCeJNVr7evVsidTB9koRxioy3HFIyZT35koBedG0B_ySqsoZbuoFCFmhNvoFp085DLcw/s1600/visa3b.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="238" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDD18zApFuTZVdUBXpj4rQq2CL1qNgtt7yXDjkD8S9eDZH_6wq4swHG5k67ANsv43OaliId4BfCeJNVr7evVsidTB9koRxioy3HFIyZT35koBedG0B_ySqsoZbuoFCFmhNvoFp085DLcw/s640/visa3b.png" width="640" /></a></div>
<br />
(Et l'option est véritablement à trois clics, et non un seul, du sommaire où pointe le lien.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-13719920737206982592015-08-01T21:09:00.000-04:002015-08-01T21:09:45.120-04:00PayPal: No, we mean it, we really hate youI have <a href="http://blog.fbriere.net/2014/11/those-goddamn-copy-protected-password.html">previously complained</a> about PayPal disabling cut-and-paste for password entries. Apparently, this is also the case for the destination entry, when sending money without an invoice:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdXubS8US9jyH-3mbYsKgHio2_X0BWi7UT2pkm9scciJoMRCSa4O_jb4z_TIHET_HaR_wWveJKTQ64aZ0ZNyBqNkcZh8QFu8VRY0joufcTxzShFdreVdcOxgBi4NjdM8YWArvz-Gs96qw/s1600/paypal.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="140" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdXubS8US9jyH-3mbYsKgHio2_X0BWi7UT2pkm9scciJoMRCSa4O_jb4z_TIHET_HaR_wWveJKTQ64aZ0ZNyBqNkcZh8QFu8VRY0joufcTxzShFdreVdcOxgBi4NjdM8YWArvz-Gs96qw/s320/paypal.png" width="320" /></a></div>
That "<i>Email or mobile number</i>" field up there? The one where one typo can result in your money being gone forever? Yeah, cut-and-paste didn't work; you have to type that shit <i>manually</i>.<br />
<br />
Sometimes I wonder if they're not deliberately trying to drive me insane.<br />
<br />
(Actually, the part that pisses me off the most is that my own browser <i>obeys</i> to this stuff.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-77495037236298325382014-12-13T16:54:00.000-05:002014-12-13T16:54:48.351-05:00Don't ever leave Try::Tiny behindHit a bug at work a few days ago; it looked as if <span style="font-family: "Courier New",Courier,monospace;">Try::Tiny</span> was not doing its job of catching an exception, letting it pass right through instead. The exception was thrown several layers below the <span style="font-family: "Courier New",Courier,monospace;">try</span>, which itself was also several layers deep, with lots of <span style="font-family: "Courier New",Courier,monospace;">eval</span>s in-between. It took me quite a while to prune away all the unrelated bits, until the problematic part of the code was pared down to its simplest expression:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">try { die } catch { warn };</span></blockquote>
Huh? This piece of code should catch the <span style="font-family: "Courier New",Courier,monospace;">die</span> and emit a warning instead, but here it was, dying on me. What was going on?<br />
<br />
Actually, there's nothing wrong with that code, and it will do exactly what it is meant to do. <i>Unless you forget the</i> use <span style="font-family: "Courier New",Courier,monospace;">Try::Tiny</span>. Then all hell breaks loose.<br />
<br />
In most cases, failing to use a module will typically result in a "Undefined subroutine" or "Can't locate object method" error message that will point to your mistake in an obvious manner. But in this case, the manifestation can be quite puzzling.<br />
<br />
At first, I figured that maybe perl was parsing the first block (i.e. the first argument of the <span style="font-family: "Courier New",Courier,monospace;">try</span> subroutine) as an anonymous hash; since the <span style="font-family: "Courier New",Courier,monospace;">try</span> prototype hasn't been declared yet, there's no way to know that this argument is actually a block. The <span style="font-family: "Courier New",Courier,monospace;">die</span> will then be executed during the evaluation of the <span style="font-family: "Courier New",Courier,monospace;">try</span> arguments.<br />
<br />
Close, but no cigar. Turns out that perl is indeed parsing it as a block -- just not in the context we expect:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$ perl -MO=Deparse -e 'try { die } catch { warn }'<br />do {<br /> die<br />}->try(do {<br /> warn<br />}->catch);</span></blockquote>
Here's the indirect object syntax rearing it ugly head; Perl assumes that <span style="font-family: "Courier New",Courier,monospace;">try</span> is actually a method to be called on whatever class/object the following block will return. Yuck. (Notice that the same also applies to <span style="font-family: "Courier New",Courier,monospace;">catch</span>.)<br />
<br />
(Maybe this will finally push me to break the habit of using that syntax for class methods. Yeah, I know it's unhealthy, but I can't resist...)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-91592825081718595082014-11-29T16:54:00.001-05:002014-11-29T16:54:15.252-05:00PC Plus : Des heures de plaisir à s'inscrireEu beaucoup de plaisir l'autre jour à m'inscrire au <a href="https://www.pcplus.ca/">programme PC Plus du Choix du Président</a> (maudit que ça se dit mal). Le programme lui-même mériterait un autre billet, mais restons-en à l'inscription.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOCRW_XFsmhXYlTDdfrOmfQRTLPoqv_0rGVI_Hdp_05v0d3vx90EOUw3Iy3G1RMYs7BOHj4BhhFGJXlAsiTRuk6vdHFWb8qv1h-vi8zhPHIuAiUqULiYFgXD2vOnY8ewe2KWFfnHmCZyg/s1600/01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOCRW_XFsmhXYlTDdfrOmfQRTLPoqv_0rGVI_Hdp_05v0d3vx90EOUw3Iy3G1RMYs7BOHj4BhhFGJXlAsiTRuk6vdHFWb8qv1h-vi8zhPHIuAiUqULiYFgXD2vOnY8ewe2KWFfnHmCZyg/s1600/01.png" height="18" width="320" /></a></div>
Allons-y!<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgECBnrJhbd_zk9-rzrm4d3hs9wPBB6AECdt143nOYiJvtrSxZlhR7_hdM_ks791V1v73fNApxDQ8IUP06LYsrsp_2IA-8g2q7hugjapHooPSB-zIhRHDc20laGHTXM4HyZj6RvERlZHH4/s1600/03.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgECBnrJhbd_zk9-rzrm4d3hs9wPBB6AECdt143nOYiJvtrSxZlhR7_hdM_ks791V1v73fNApxDQ8IUP06LYsrsp_2IA-8g2q7hugjapHooPSB-zIhRHDc20laGHTXM4HyZj6RvERlZHH4/s1600/03.png" height="61" width="400" /></a></div>
Non. Sérieux. On parle d'une entreprise qui doit brasser des millions au Québec. Pas pouvoir mettre d'accents, c'est comme pas pouvoir donner un numéro de téléphone dans le 418. Non -- juste, non.<br />
<br />
(soupir) Bon, poursuivons quand même...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPpCEG8YYPbsEb8kE22NcJjihzf9lae80f5mS1-WwTTdINcGCMUlML__u-XCy_4MSTl7XFQfR7S95Qm67_iUYoO-_CyenOWnYT1ou0fIKNvuYM3788s8Ma3aDtwAoWu7VUVtCxKG1ZD3c/s1600/04.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPpCEG8YYPbsEb8kE22NcJjihzf9lae80f5mS1-WwTTdINcGCMUlML__u-XCy_4MSTl7XFQfR7S95Qm67_iUYoO-_CyenOWnYT1ou0fIKNvuYM3788s8Ma3aDtwAoWu7VUVtCxKG1ZD3c/s1600/04.png" height="55" width="320" /></a></div>
Euh, je crois que c'est l'adresse que l'on confirme ici, et non pas un courriel en soi.<br /><div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkE48uYZjIFQy-bprr53BiYyKiuSZMSASRTPolPWVZZfsmZl12AWf5vnczrXA4AkXhu1lganrd4pOjc929UJnHjne9-QHRdhoFCFypa0duUW1I7ZlNoIuV4dTv8l0Xx9y8YzlhTWsIEnk/s1600/05.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkE48uYZjIFQy-bprr53BiYyKiuSZMSASRTPolPWVZZfsmZl12AWf5vnczrXA4AkXhu1lganrd4pOjc929UJnHjne9-QHRdhoFCFypa0duUW1I7ZlNoIuV4dTv8l0Xx9y8YzlhTWsIEnk/s1600/05.png" height="28" width="320" /></a></div>
Tiens, un autre mot de passe avec une limite arbitraire. Pourquoi 8? Bah, pourquoi pas. (J'admet toutefois que c'est bien assez pour protéger une simple liste d'épicerie.)<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9IlRWaww02lHxWF1f00mYRZBqY-s_HDyRXnZdTpJT_M6dvM9BPsptVxXQdQZ6i1OE5Wk33u0xWhK1bPG7HUhrt7LB-ZlOKb2rIoQwp0UK-YPmaaw4a6YHQmGdzXSBccVDbqtTniGOaZo/s1600/06.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9IlRWaww02lHxWF1f00mYRZBqY-s_HDyRXnZdTpJT_M6dvM9BPsptVxXQdQZ6i1OE5Wk33u0xWhK1bPG7HUhrt7LB-ZlOKb2rIoQwp0UK-YPmaaw4a6YHQmGdzXSBccVDbqtTniGOaZo/s1600/06.png" height="36" width="320" /></a></div>
Oh, wow! Comme un magazine en papier -- ça prend un certain temps pour imprimer les étiquettes, j'imagine.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7RQ_QB8wpZ5wZjKBp7ykhhaTGCyCgCq1Rnr6uQygrAf03k9yf6IQMlTOHdGkndwjykGm3q819PUaVj8UM5BSjeCw_si0RjIeUx4vWNwIf145kmB9wykfvzwRN-H9eVs3RJ_H51KZpDvI/s1600/07.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7RQ_QB8wpZ5wZjKBp7ykhhaTGCyCgCq1Rnr6uQygrAf03k9yf6IQMlTOHdGkndwjykGm3q819PUaVj8UM5BSjeCw_si0RjIeUx4vWNwIf145kmB9wykfvzwRN-H9eVs3RJ_H51KZpDvI/s1600/07.png" /></a></div>
Uh-huh. (À noter que leur captcha n'est que du texte noir sur un fond rouge. Probablement plus difficile à lire pour un humain que pour un robot.)<br /><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3bRe40y3AIV1bd-0LSJ77iQJfX6m7oITALGXL59jR7oOoqyZ7B_PDx9TLl3tZ7n1_En_OhDfOveC6XDr1M-jHW_NmOm21TTcyF0FPOaA7mPxy2q4M0gbmLGw4bc7S_lRSYet8jsJPVfY/s1600/08.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3bRe40y3AIV1bd-0LSJ77iQJfX6m7oITALGXL59jR7oOoqyZ7B_PDx9TLl3tZ7n1_En_OhDfOveC6XDr1M-jHW_NmOm21TTcyF0FPOaA7mPxy2q4M0gbmLGw4bc7S_lRSYet8jsJPVfY/s1600/08.png" height="28" width="320" /></a></div>
<br />Euh, "accéder" à mes données? Elles sont directement dans le formulaire que j'essaie de vous soumettre, mes amis.<br />
<br />
(C'est comme ça, leur site <i>jamme</i> de temps à autre. Un rien <a href="http://ca.apponlinereview.com/?review=634040057">comparé à leur application mobile</a>.)<br />
<br />
Bon, peut-être que l'inscription a passé quand même, et que c'est simplement le <i>login</i> automatique qui a planté. Vérifions en demandant notre mot de passe par courriel.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhULq6ooyczuIBheIJtD1fifLPcOIvHgH0T0MTnSJS2nPAKy19DKc1brpe0NM776MLUk2fwKPmKE8nRTPQVuJ1RzvTE1m37FHVa6MAG0XTFHN-4xfx74JwamFyBhWZFwoR3j6CTkH44Rmo/s1600/09.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhULq6ooyczuIBheIJtD1fifLPcOIvHgH0T0MTnSJS2nPAKy19DKc1brpe0NM776MLUk2fwKPmKE8nRTPQVuJ1RzvTE1m37FHVa6MAG0XTFHN-4xfx74JwamFyBhWZFwoR3j6CTkH44Rmo/s1600/09.png" /></a></div>
Je vous assure qu'il s'agit d'une adresse courriel parfaitement valide; elle ne figure simplement pas dans vos dossiers. (Et pas sûr que ça donnerait grand chose de réessayer.)<br />
<br />
Heureusement, leur système a fini par prendre du mieux, et j'ai enfin pu m'inscrire et <i>loader</i> ma carte.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbHeUBFRMgBMCWbX_ONWn6QjzQABUyeDm-zgYsgGWy-pkRnmsyGn1XxfYBiW9mT-fnmUiMC42RUcSmugxbkRc8TDHLpLpwe9q-_ss4XAhEQ7UGotha2GnxDJWVwX78lQty43H0l3CxcjE/s1600/10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbHeUBFRMgBMCWbX_ONWn6QjzQABUyeDm-zgYsgGWy-pkRnmsyGn1XxfYBiW9mT-fnmUiMC42RUcSmugxbkRc8TDHLpLpwe9q-_ss4XAhEQ7UGotha2GnxDJWVwX78lQty43H0l3CxcjE/s1600/10.png" /></a></div>
Tiens, une offre pour le beurre. N'importe quel beurre?<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgs003WipMBrRzISVt9NGa1qmJ1n0jkk4LAFX-6aNrEvpMdh36oRbptybTlbzX6vdAHenwkP4JcH18mLe868bOnHQbgOLQhWnIWGY-xKLmWU33l5cdthaNIARZDpD4TwT7XkYPzJvM148w/s1600/11.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgs003WipMBrRzISVt9NGa1qmJ1n0jkk4LAFX-6aNrEvpMdh36oRbptybTlbzX6vdAHenwkP4JcH18mLe868bOnHQbgOLQhWnIWGY-xKLmWU33l5cdthaNIARZDpD4TwT7XkYPzJvM148w/s1600/11.png" height="50" width="320" /></a></div>
Ça a le mérite d'être clair.<br /><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com1tag:blogger.com,1999:blog-6269198593264893886.post-15438844195804242192014-11-02T16:38:00.003-05:002014-11-02T16:38:46.172-05:00Those goddamn copy-protected password fieldsFuck you, PayPal, for deliberately preventing me from pasting in the password field. These stupid "security" measures actually entice me to choose a <i>shorter, simpler</i> password, because who wants to painstakingly type 20 gibberish characters one by one -- <i>twice</i>?<br />
<br />
I take solace in the fact that my frustration is <a href="https://www.paypal-community.com/t5/My-Feedback-for-PayPal-Archive/cannot-copy-and-paste-passwords/td-p/666858">shared</a> <a href="http://www.quartertothree.com/game-talk/showthread.php?70953-So-is-the-PAYPAL-web-page-designed-by-idiots">by</a> <a href="https://alpha.app.net/dalton/post/2806873">many</a> <a href="http://ask.metafilter.com/221964/Why-does-PayPal-want-me-to-have-a-crappy-password">other</a> <a href="https://news.ycombinator.com/item?id=7778544">people</a>. (<a href="http://www.troyhunt.com/2014/05/the-cobra-effect-that-is-disabling.html">Here's a much more eloquent rant on this matter.</a>)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-89445450680743021082014-10-31T19:29:00.000-04:002014-10-31T19:29:33.774-04:00CrashPlan: Our watch is stuck on 2003CrashPlan has this cool feature where it <a href="http://support.code42.com/CrashPlan/Latest/Backup/How_Backup_Works#Backup_Basics">watches for new and changed files (and directories) in real-time</a>; it immediately notices when there's something new, and schedules it for the next backup.<br />
<br />
On Linux, this is done with inotify. This usually requires <a href="http://support.code42.com/CrashPlan/Latest/Troubleshooting/Linux_Real-Time_File_Watching_Errors">a little bit of fiddling with <span style="font-family: "Courier New",Courier,monospace;">sysctl(8)</span></a>, since the default maximum number of watches allowed per user is typically much lower than the number of entries in the backup file selection.<br />
<br />
However, you may find that this feature still cannot be enabled, no matter how high you raise that maximum number. Turns out that CrashPlan first checks the kernel version for inotify support (which was introduced in 2.6.13), and <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745984">cannot parse a version number with only two components</a>.<br />
<br />
Guys, seriously? <b>Seriously?</b> It's been <i>more than three years</i> since 3.0 was released. This should have been fixed a long time ago, and I most certainly shouldn't have to write a <a href="https://gist.github.com/fbriere/157693bb865eb0e43428">goddamn uname library wrapper</a> to make it work.<br />
<br />
(sigh)<br />
<br />
That being said -- once you've finally got it working, it's <i>really</i> cool, and well worth the effort.Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-78870848693139807382014-10-30T14:24:00.000-04:002014-10-30T14:24:35.393-04:00CrashPlan: Don't forget the umlautGood thing that I tested a full restore from my new CrashPlan backup, as I found that something was missing: all filenames containing non-ASCII characters were omitted from the backup!<br />
<br />
It turns out that Java is to blame -- at least in part. Filenames are, after all, strings, and Java treats them as such; any filename returned by a system call (as an array of bytes) is decoded into a String object (as an array of code points) based on the character encoding of the current locale. The same goes in reverse: any String filename passed as argument to a system call is encoded back. If all goes well, both operations should be exact opposites, and cancel each other; the string we give to <span style="font-family: "Courier New",Courier,monospace;">open(2)</span> should be byte-for-byte identical to the one we got from <span style="font-family: "Courier New",Courier,monospace;">readdir(3)</span>.<br />
<br />
If, however, the filename is not properly encoded accordingly with the current locale, it may contain sequences of bytes which are invalid, and cannot be converted into a code point. (This is typically the case with ISO-8859-1 filenames under a UTF-8 locale.) In that case, the Unicode replacement character (U+FFFD) is used instead -- that's what it's for, after all. Consequently, the re-encoded filename will not be identical to the original, and will refer to a (most probably) inexistant file with a weird name. (The effects can be perplexing at first, such as <a href="http://jonisalonen.com/2012/java-and-file-names-with-invalid-characters/">listed files not really existing</a>.)<br />
<br />
If the C locale is in effect (typically because <span style="font-family: "Courier New",Courier,monospace;">$LANG</span> -- or <span style="font-family: "Courier New",Courier,monospace;">$LC_ALL</span> or <span style="font-family: "Courier New",Courier,monospace;">$LC_CTYPE</span> -- was explicitly set to "C", or left undefined, either of which can often be the case for init scripts, or when using sudo), then only ASCII characters are allowed; any filename with non-ASCII characters (be it encoded with UTF-8 or ISO-8859-1) will definitely not work.<br />
<br />
CrashPlan actually accounts for all of this, and makes sure to set <span style="font-family: "Courier New",Courier,monospace;">$LANG</span> to "<span style="font-family: "Courier New",Courier,monospace;">en_US.UTF-8</span>" if it was previously undefined. (It also enforces UTF-8 as the current codeset. If your filesystem is still using a legacy encoding, welcome to the 21st century.) This ensures that UTF-8 filenames will be properly handled. Assuming, of course, that <span style="font-family: "Courier New",Courier,monospace;">en_US.UTF-8</span> is a valid locale.<br />
<br />
<b>That</b>'s the catch: on a Debian system, locales are not installed as-is, but rather generated on demand (to save space). And it's quite possible for <span style="font-family: "Courier New",Courier,monospace;">en_US.UTF-8</span> to not have been generated, if another UTF-8 locale is being used in its stead. In that case, failure to set <span style="font-family: "Courier New",Courier,monospace;">$LANG </span>will result in an invalid locale, falling back to the C locale, under which non-ASCII filenames cannot be handled properly.<br />
<br />
CrashPlan's fault in all this is quite simple: it does not appear to output any error or warning message in this situation. Seems like a serious oversight to me.<br />
<br />
Setting <span style="font-family: "Courier New",Courier,monospace;">$LANG</span> to the proper locale in <span style="font-family: "Courier New",Courier,monospace;">bin/run.conf</span> would do the trick, but according to Code42, this file will be overwritten when upgrading to a new version. (And unlike <a href="http://support.code42.com/CrashPlan/Latest/Troubleshooting/CrashPlan_App_Closes_In_Some_Linux_Installations">that other bug which prevents the client from launching</a>, this one could easily go unnoticed if reintroduced.) It's probably best to play it safe, and just generate the damn US locale.<br />
<br />
Problem solved.Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-63984276486207955602014-10-25T18:01:00.000-04:002014-10-25T18:01:00.061-04:00CrashPlan: Kicking the tiresAfter a lot of research and reading, I'm pretty much sold on <a href="https://www.code42.com/crashplan/">CrashPlan</a>.<br />
<br />
I'm currently in the process of uploading my <span style="font-family: "Courier New",Courier,monospace;">/home</span> partition (only 1.9 days to go!) as part of their free trial. (Kudos to them for not putting any cap or limit -- you can try it out as much as you want.) I had heard reports of issues with their upload/download speed, but it's all going as smooth as butter over here. Once I've run a successful restore dry-run, I'll be another happy customer.<br />
<br />
My only non-encryption-related issue so far is that there doesn't seem to be an easy way to remove a single file (or folder) that has already been deleted. (Being deleted, it no longer shows up in the File Selection list, and therefore cannot be deselected.) Of course, with the lack of any quota, this is not that much of an issue, but it's still bugging me a bit.<br />
<br />
(My thanks to Nelson Minar for his tips on <a href="http://nelsonslog.wordpress.com/2012/06/22/crashplan-on-linux/">increasing the inotify limit and turning off inbound backups</a>.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-13962139750282020512014-10-13T19:26:00.003-04:002014-10-25T17:08:54.810-04:00Another day, another segfault<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$ CrashPlanDesktop</span><br />
<span style="font-family: "Courier New",Courier,monospace;">$ tail -n 18 /opt/crashplan/log/ui_output.log <br />#<br /># A fatal error has been detected by the Java Runtime Environment:<br />#<br /># SIGSEGV (0xb) at pc=0xc981c81d, pid=17363, tid=4136905536</span></blockquote>
<br />
I'm starting to believe there's a curse on me...<br />
<br />
UPDATE: Well, I'll be damned; adding<span class="quote"> <span style="font-family: "Courier New",Courier,monospace;">-Dorg.eclipse.swt.browser.DefaultType=mozilla</span> does work. Apparently, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=404776">this is an eclipse bug</a> -- and here I thought that eclipse was merely an IDE.</span><br />
<br />
<span class="quote">UPDATE 2: This issue is <a href="http://support.code42.com/CrashPlan/Latest/Troubleshooting/CrashPlan_App_Closes_In_Some_Linux_Installations">actually documented</a> on CrashPlan's website. I guess I didn't look for it hard enough.</span>Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com1tag:blogger.com,1999:blog-6269198593264893886.post-2128254822400092392014-10-12T19:29:00.000-04:002014-10-12T19:29:25.925-04:00Reinventing the OfflineIMAP wheelI just realized that by attempting to hack IDLE support around mbsync, I was basically reinventing OfflineIMAP. Hurray me.<br />
<br />
(I had actually considered OfflineIMAP when I was initially looking for an IMAP sync-er, but most of the comments out there painted it as a clunkier, buggier, unmaintained alternative. After taking a second look, this doesn't seem to be the case, at least not in the current version. I guess I'll have to give it a try and see for myself.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-2003233127263623402014-10-12T19:10:00.002-04:002014-10-12T19:10:49.761-04:00No fate but what we makeIf I'd only taken five minutes to look at the damn code, instead of spending the whole evening poking at it with gdb, I would've easily found the missing comma that was causing the segfault from my previous post. (sigh)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com1tag:blogger.com,1999:blog-6269198593264893886.post-25170806153287691242014-10-08T15:05:00.000-04:002014-10-08T15:11:21.534-04:00SELECT ... FOR UPDATE on absent rowsFinally tracked down today at work the source of a year-old bug that was causing (rare) intermittent MySQL deadlocks:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">BEGIN; </span><br />
<span style="font-family: "Courier New",Courier,monospace;">SELECT i FROM t WHERE i = 42 FOR UPDATE;</span><br />
<span style="font-family: "Courier New",Courier,monospace;">(0 rows returned)</span><br />
<span style="font-family: "Courier New",Courier,monospace;">[...]</span><br />
<span style="font-family: "Courier New",Courier,monospace;">INSERT INTO t SET i = 42;</span><br />
<span style="font-family: "Courier New",Courier,monospace;">[deadlock]</span></blockquote>
Huh? How can this deadlock -- didn't I just get a write lock before? If not on the record itself (which didn't exist), then at least on the gap where it would be inserted, right?<br />
<br />
Turns out that MySQL/InnoDB <a href="http://bugs.mysql.com/bug.php?id=48911">doesn't acquire an exclusive lock in this case</a>. It <i>will</i> get a shared lock (on <i>something</i>), though, preventing any concurrent INSERT for that row, but making it possible to deadlock when INSERT requests the proper exclusive lock it requires. Hilarity ensues.<br />
<br />
(Despite comments to the contrary in the bug report, I can reproduce this for any value, large or small.)<br />
<br />
(Update: This apparently <a href="http://stackoverflow.com/q/3601895">varies from one DBMS to another</a>.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-75503702798761855332014-10-07T15:10:00.002-04:002014-10-08T14:22:58.870-04:00I just can't escape fateI've spent way too much time futzing aroung with programming and debugging these past few days. I really need to settle down for a while, and take care of all the things that I've put aside and are now piling up. Like, say, my monthly accounting.<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$ gnucash</span><br />
<span style="font-family: "Courier New",Courier,monospace;">Segmentation fault</span></blockquote>
(sigh)<br />
<br />
(Update: This turned out to be even more complicated than I thought, involving GCC; filed Debian bug #<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764510">764510</a>.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-13869934051322791982014-10-06T18:37:00.000-04:002014-10-06T18:37:15.127-04:00Sicker HappierSomehow, "I've been feeling under the weather" has turned into "let's copy all my mail under IMAP, switching from my SpamAssassin setup to my provider's, replacing most of procmail with Sieve scripts, fetchmail with mbsync, and converting what little remains to maildrop, skipping Postfix entirely".<br />
<br />
And then, "not sleeping enough and feeling much worse" morphed into "instead of running mbsync every 30 seconds, let's write a multi-threaded Python script that IDLEs on each mailbox".<br />
<br />
This is fucked up.<br />
<br />
(The SpamAssassin switch was worth it, though.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-31481104162243020562014-09-30T20:45:00.003-04:002014-10-06T18:44:09.264-04:00Every time you lie... Git kills a kittenJust wasted over two hours of my life over the fact that Git no longer supports <span style="font-family: "Courier New",Courier,monospace;">$GIT_CONFIG</span>. Except when it FUCKING PRETENDS TO.<br />
<br />
(I'll skip filing a bug report for the moment -- otherwise it would probably only be a stream of swear words.)<br />
<br />
(Followup: I filed Debian bug#<a href="http://bugs.debian.org/763712" rel="nofollow" target="_top">763712</a>, and was amazed at how quickly the dev team reacted. Kudos!)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com1tag:blogger.com,1999:blog-6269198593264893886.post-3820929031226366142014-09-29T20:58:00.002-04:002014-09-29T21:06:17.349-04:00An interface by any other nameIf you're looking to rename a network interface, you've probably come across this udev rule:<br />
<blockquote class="tr_bq">
<pre>SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:00", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="foo"</pre>
</blockquote>
And if you're like me, you won't be content to blindly copy this rule without understanding what it all means. What are all those constants for? Why can't we go for the simpler example shown in <a href="http://www.reactivated.net/writing_udev_rules.html#example-netif">Writing udev rules</a>:<br />
<blockquote class="tr_bq">
<pre>KERNEL=="eth*", ATTR{address}=="00:00:00:00:00:00", NAME="foo"</pre>
</blockquote>
What's wrong with <i>that</i>?<br />
<br />
Well, I don't know if it could be said that there's anything <i>wrong</i> with that rule (other than the fact that it is uselessly invoked for any other action), but it does lack precision; if there ever is, say, an "<span style="font-family: "Courier New",Courier,monospace;">ethical</span>" device that happens to have the same <span style="font-family: "Courier New",Courier,monospace;">address</span> attribute (maybe it is attached to the Ethernet port and inherited the attribute), it would also match that rule. Probably unlikely, but you never know.<br />
<br />
Here's the first rule again, deconstructed:<br />
<ul>
<li><pre>ACTION=="add"</pre>
<span style="font-family: inherit;">This shouldn't need any explanation. :)</span>
</li>
<li><pre>DRIVERS=="?*"</pre>
<span style="font-family: inherit;">Ensures that there is a driver for this device (i.e. <a href="https://lists.debian.org/debian-user/2013/11/msg01049.html">it is a physical device, not a virtual one</a>).</span>
</li>
<li><pre>SUBSYSTEM=="net"</pre>
<span style="font-family: inherit;">Provides a context for the following attributes (since there could be other subsystems with the same attribute names).</span>
</li>
<li><pre>ATTR{type}=="1"</pre>
<span style="font-family: inherit;">Ethernet hardware type (defined in </span><a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/linux/if_arp.h">if_arp.h</a>)
</li>
<li><pre>ATTR{address}=="00:00:00:00:00:00"</pre>
<span style="font-family: inherit;">MAC address, obviously :)</span>
</li>
<li><pre>ATTR{dev_id}=="0x0"</pre>
<span style="font-family: inherit;">In case there are multiple devices with the same MAC address, this matches the first one.</span>
</li>
</ul>
(You can get <a href="https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net">more information about the various attributes for a net device</a>.)<br />
<br />
I <i>think</i> that with all of the above, the <span style="font-family: "Courier New",Courier,monospace;">KERNEL</span> match is superfluous; although I guess it could be used to skip any interface that has already been renamed to something other than "<span style="font-family: "Courier New",Courier,monospace;">eth*</span>".<br />
<br />
And now I can rest, contented. :)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com1tag:blogger.com,1999:blog-6269198593264893886.post-65076829614025767342014-09-29T12:55:00.000-04:002014-09-29T12:55:24.049-04:00Not all USB flash drives are removableI had assumed that all USB flash drives had a <span style="font-family: "Courier New",Courier,monospace;">removable</span> sysfs attribute of 1 (they are, after all, "removable"), but this is not always true. (Apparently, <span style="font-family: "Courier New",Courier,monospace;">removable</span> was meant for floppy drives and such, where the <b>media</b> is removable.)<br />
<br />
Curiosity got the best of me, and I tried to figure out where that value was coming from. Google suggests that this is a USB property, but <span style="font-family: "Courier New",Courier,monospace;">lsusb</span> shows nothing to that effect. Searching the kernel code didn't help much; the end result comes from the <tt>GENHD_FL_REMOVABLE</tt> gendisk flag, set by <span style="font-family: "Courier New",Courier,monospace;">sd.c</span> from the <span style="font-family: "Courier New",Courier,monospace;"><span class="k">struct</span> </span><span class="n"><span style="font-family: "Courier New",Courier,monospace;">scsi_device</span> </span><span style="font-family: "Courier New",Courier,monospace;"><span class="o"></span><span class="n">removable</span><span class="p"></span></span> flag, set by, erm, <i>someone</i>.<br />
<br />
To make things more confusing, there is <b>another</b> <span style="font-family: "Courier New",Courier,monospace;">removable</span> sysfs attribute for USB devices, supposedly "inferred from a combination of hub descriptor bits and platform-specific data such as ACPI", whose description sounds like what I wanted in the first place, but which always returns <span style="font-family: "Courier New",Courier,monospace;">unknown</span> for me.<br />
<br />
That was an hour well wasted.Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-70581066868299921682014-09-28T22:17:00.000-04:002014-09-28T22:20:51.262-04:00$? is a very fragile thing<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">#!/bin/sh</span><br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">foo() { return 42; }<br /><br />while ! foo; do<br /> if [ $? -eq 42 ]; then<br /> echo "foo() has indeed returned 42"<br /> # This should exit with a status of 42, right?<br /> exit $?<br /> fi<br />done</span></blockquote>
It should've dawned on me that there's a glaring bug in there: the return status of the <span style="font-family: "Courier New",Courier,monospace;">echo</span> command will overwrite the value of <span style="font-family: "Courier New",Courier,monospace;">$?</span>.<br />
<br />
It took me some more time to realize that there are two bugs in there: <span style="font-family: "Courier New",Courier,monospace;">!</span> is also a command, and its return status will also overwrite <span style="font-family: "Courier New",Courier,monospace;">$?</span>.<br />
<br />
It took me much longer to realize that there are <b>three</b> bugs in there: <span style="font-family: "Courier New",Courier,monospace;">[</span> is <b>also</b> a command, and yadda yadda yadda.<br />
<br />
God I get tired of this shit sometimes...Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-59894346881668982352014-09-27T18:29:00.001-04:002014-09-27T18:29:26.521-04:00The Five Ws (and a few more letters)<a href="http://unix.stackexchange.com/a/85250">More information than I'd ever thought possible about the multiple ways of knowing if/where a command is available from a shell.</a> My head is still spinning.Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-30788934624956608052014-09-27T18:23:00.000-04:002014-09-27T18:25:43.158-04:00As thick as a phonebook<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$ cat .<br />cat: .: Is a directory</span><br />
<span style="font-family: "Courier New",Courier,monospace;">$ perl -pe '' .</span></blockquote>
Huh.<br />
<br />
Turns out you can <span style="font-family: "Courier New",Courier,monospace;">open(2)</span> a directory just fine, so Perl doesn't bat an eye over that. It's only the subsequent <span style="font-family: "Courier New",Courier,monospace;">read(2)</span> that will fail, indicated by <span style="font-family: "Courier New",Courier,monospace;">readline</span> (or <span style="font-family: "Courier New",Courier,monospace;">read</span>, or <span style="font-family: "Courier New",Courier,monospace;">sysread</span>) returning <span style="font-family: "Courier New",Courier,monospace;">undef</span>, which you're supposed to check for. Yeah, like anyone actually checks for these things.<br />
<br />
The worst part is that autodie won't save your ass in this situation:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">use autodie;<br />use warnings;<br /><br />open FH, "<", ".";<br />1 while <FH>;<br />close FH;<br /><br />print "Uncaught: $!\n";</span></blockquote>
Apparently, <a href="http://www.nntp.perl.org/group/perl.perl5.porters/2009/06/msg147535.html">not much can be done about this</a>. :(Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-29439608654684580462014-09-27T12:20:00.000-04:002014-09-28T22:22:18.232-04:00Letter to cgmanager: You have to learn to let goThis is the second time that I'm unable to unmount an otherwise non-busy block device, only to find out (after killing nearly every process, forcing me to reboot anyway) that the culprit is cgmanager. This is quite annoying.<br />
<br />
(Nobody else on the interwebs seems to have this problem. Oh well, at least I'll know who I should yell at next time.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-13379722937611439172014-09-27T12:10:00.000-04:002014-09-28T22:24:45.779-04:00UncloggedOlder, wiser programmers will have figured out that the bug in my previous post was due to an uncaught SIGPIPE. I'd completely forgotten about those. :)<br />
<br />
The shifting nature of the bug (which is what really had me confused) was due to a race condition between the parent process writing to the pipe, and the child closing it (by exiting). Here's an overly simplified version of what happens in both processes after the <span style="font-family: "Courier New",Courier,monospace;">clone()</span>:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">/* parent - writer */</span><br />
<span style="font-family: "Courier New",Courier,monospace;">write(...)</span><br />
<span style="font-family: "Courier New",Courier,monospace;">close(...)</span><br />
<span style="font-family: "Courier New",Courier,monospace;">waitpid(...)</span><br />
<span style="font-family: "Courier New",Courier,monospace;"><br /></span>
<span style="font-family: "Courier New",Courier,monospace;">/* child - reader */</span><br />
<span style="font-family: "Courier New",Courier,monospace;">execve("/bin/false", ...)</span><br />
<span style="font-family: "Courier New",Courier,monospace;">exit(1)</span></blockquote>
If the parent attempts to write to the pipe after it has been closed on the other side by the child's <span style="font-family: "Courier New",Courier,monospace;">exit()</span>, then a SIGPIPE obviously occurs. However, since our simple string is small enough to fit in a pipe's buffer, the parent may very well get the chance to close the pipe before the child. At this point, the child's <span style="font-family: "Courier New",Courier,monospace;">close()</span> will simply discard any data in the pipe's buffer and exit; its exit status will then be returned by the parent's <span style="font-family: "Courier New",Courier,monospace;">waitpid()</span>, stored in <span style="font-family: "Courier New",Courier,monospace;">$?</span>, and cause Perl's <span style="font-family: "Courier New",Courier,monospace;">close()</span> to return a false value.<br />
<br />
The script example given in the previous post is simple enough (without autodie) for the parent to get there first. Adding autodie then introduces just enough complexity for the parent to take a little bit more time, giving the child a chance to exit first. (Even using strace is enough to influence the result, making this a true heisenbug.)<br />
<br />
Note that in the parent-closes-first case, the failure has nothing to do with the pipe itself (hence why <span style="font-family: "Courier New",Courier,monospace;">$!</span> is left empty), but is simply due to the child returning a non-zero exit status. (Thus, replacing <span style="font-family: "Courier New",Courier,monospace;">false</span> with <span style="font-family: "Courier New",Courier,monospace;">true</span> would make the script fail some times, but not always. Now <i>there's</i> a real head-scratcher.)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-54458118138989143122014-09-25T22:25:00.001-04:002014-09-26T21:58:42.801-04:00CloggedThis one had me stumped for a while:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">#!/usr/bin/perl<br /><br />use 5.014;<br />use autodie;<br /><br />open FALSE, "|-", "false";<br />print FALSE "Hello world!";<br />say "Closing filehandle:";<br />close FALSE or die "close() doesn't die...";<br />say "...but doesn't succeed either";</span></blockquote>
What made it even confusing was that commenting out <span style="font-family: "Courier New",Courier,monospace;">autodie</span> allowed <span style="font-family: "Courier New",Courier,monospace;">close</span> to at least (silently) fail and return a false value (without even an error message in <span style="font-family: "Courier New",Courier,monospace;">$!</span> as would be expected). I used <span style="font-family: "Courier New",Courier,monospace;">autodie</span> to catch any unchecked errors, dammit, not to hide them even further!<br />
<br />
I guess that's what I get for living a life sheltered away from the raw, bare-metal, non-child-proof world of C programming. :)Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0tag:blogger.com,1999:blog-6269198593264893886.post-27639539988037301732014-09-25T22:03:00.000-04:002014-09-26T22:55:25.429-04:00I Can Haz Triplequotes?Writing a udev rule:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">[...] PROGRAM="/bin/sh -c '... something-that-must-be-quoted ...'"</span></blockquote>
Drat. :( Anonymoushttp://www.blogger.com/profile/01973426073788493252noreply@blogger.com0