From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Fri, 16 Jun 2017 21:52:24 +0000 Message-ID: References: <841sqkdzh5.fsf@gmail.com> <84zid7y668.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="001a11407a7a9adeac05521acd33" X-Trace: blaine.gmane.org 1497649995 19327 195.159.176.226 (16 Jun 2017 21:53:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Jun 2017 21:53:15 +0000 (UTC) To: Vincent =?UTF-8?Q?Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 16 23:53:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzB0-0004jd-Kn for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Jun 2017 23:53:10 +0200 Original-Received: from localhost ([::1]:60824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLzB6-00081U-1d for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Jun 2017 17:53:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLzAv-00081O-Uf for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 17:53:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLzAs-0004iQ-MZ for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 17:53:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49094) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dLzAs-0004i6-Hr for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 17:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dLzAs-0006mW-8n for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 17:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Jun 2017 21:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27391 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27391-submit@debbugs.gnu.org id=B27391.149764996326035 (code B ref 27391); Fri, 16 Jun 2017 21:53:02 +0000 Original-Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 21:52:43 +0000 Original-Received: from localhost ([127.0.0.1]:51771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzAZ-0006lp-7V for submit@debbugs.gnu.org; Fri, 16 Jun 2017 17:52:43 -0400 Original-Received: from mail-ot0-f171.google.com ([74.125.82.171]:35265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzAX-0006lb-A2 for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 17:52:41 -0400 Original-Received: by mail-ot0-f171.google.com with SMTP id u13so24315115otd.2 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 14:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rqGbh2mf7l16edAyjoitwUukKrcYGjsGG4w0LL0dVHc=; b=Ob7F8coYuC9g9iLKpU3nrBM3wvJL6Wyl3RJMxfkTFQSPK2zmMe/VAKDhZDNAKGs9iI ZVXGc4jUwyvweYh/x4GJt547ID8/8CcvHCWENAfXauvlvPdbUAj94ggYuXj7hliTvK3B ilcjzWb/lsHUGbwCpBtHIB/HXIDgeLolTV4cq5rnPuw1GWkAYdCXiMW2rqvdKg13ip2k XxjNQHUHHnnnaQPKJxuoTCkyemXEypfTpgZwbyGefDwG4GctCmJ+YbKK72h6tS5vkpG+ xQl1KPZYINeY8U5+ps0eTV6SYP80VRwwYGyvgzhNhdCFCJyWXTv3wXnM8nYEPkcOGwuK 6Ucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rqGbh2mf7l16edAyjoitwUukKrcYGjsGG4w0LL0dVHc=; b=mu7NwYvUelnRV4k4ho6d+VjA8ttRDOh2NOmEw5EiyciBS+P3PWI/OxKRMkJEccMvln PR5m1HmHUI3LN2w3pZsLreJMdg65BVCODd2s+qA2JmmqKjNZ/zs4JaCXzBJWdLu+fFll RGB2BXsDq8+af8/wRp1uvlQWUlKIRcN/h/ma0PFnCsC+UwQ4CPRaWvR/t871QRKSV/OT 3qEdYCdVtwW8EeKGbKY4fLs6mfoLslylLtwfyAuKQtOHAtS3E70DqegVpTLpdHrpzz/X Tq+Z7Cj6TIxXnvHy6BXd5L3RVY+JV1SfBJDZ08suduKA4yMeGKrIW0VaXW8YiwneUn3+ PMVg== X-Gm-Message-State: AKS2vOxFPPTreiJRmyRRtlIwWkHlUYBWaUa1RnAa1rt74By/cJboUi2w KqAYNG8wZPtjCgOxrQlKVtpOfuri2w== X-Received: by 10.157.16.8 with SMTP id h8mr7811224ote.80.1497649955650; Fri, 16 Jun 2017 14:52:35 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133672 Archived-At: --001a11407a7a9adeac05521acd33 Content-Type: multipart/alternative; boundary="001a11407a7a9adea905521acd31" --001a11407a7a9adea905521acd31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philipp Stephani schrieb am Fr., 16. Juni 2017 um 23:39 Uhr: > Philipp Stephani schrieb am Fr., 16. Juni 2017 um > 23:34 Uhr: > >> Vincent Bela=C3=AFche schrieb am Fr., 16. J= uni >> 2017 um 23:28 Uhr: >> >>> >>> >>> Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : >>> > >>> > >>> > Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : >>> >> >>> >>> [...] >>> >>> >> >>> >> >>> > After some more investigation, I think that the bug is in function >>> > insert-file-contents of fileio.c which is the one that decide and set= s >>> > the coding system well before the other local variables are looked >>> into. >>> >>> After some more investigation, in the end the find-auto-coding of >>> mule.el is what is called to detect the coding. This function calls som= e >>> re-coding regexp. >>> >>> Here is a test function defining the same regexp. >>> >>> >>> (defun doit () >>> (interactive) >>> (let* ((prefix (regexp-quote "[comment]: # (")) >>> (suffix (regexp-quote ")")) >>> (re-coding >>> (concat >>> "[\r\n]" prefix >>> ;; N.B. without the \n below, the regexp can >>> ;; eat newlines. >>> "[ \t]*coding[ \t]*:[ \t]*\\([^ \t\r\n]+\\)[ \t]*" >>> suffix "[\r\n]"))) >>> (message (if (looking-at re-coding) "ok" "nak")))) >>> >>> I tried it with point at end of line >>> >>> [comment]: # ( Local Variables: ) >>> >>> and it answered "ok". Now I defined this with re-search-forward instead >>> of looking-at: >>> >>> (defun doit () >>> (interactive) >>> (let* ((prefix (regexp-quote "[comment]: # (")) >>> (suffix (regexp-quote ")")) >>> (re-coding >>> (concat >>> "[\r\n]" prefix >>> ;; N.B. without the \n below, the regexp can >>> ;; eat newlines. >>> "[ \t]*coding[ \t]*:[ \t]*\\([^ \t\r\n]+\\)[ \t]*" >>> suffix "[\r\n]"))) >>> (message (if (re-search-forward re-coding nil t) "ok" "nak")))) >>> >>> I placed the point before the coding: line, and I also got answer "ok" >>> >>> So I don't think that the regexp as such is to blame. Something else >>> seems to happen. It is too late now, I need to go to bed... >>> >>> Vincent. >>> >>> >> I think it's actually the regexp that searches for "Local Variables". Th= e >> following minimal example fails for me: >> >> (with-temp-buffer >> (insert " >> >> [comment]: # ( Local Variables: ) >> [comment]: # ( coding: utf-8 ) >> [comment]: # ( End: ) >> >> ") >> (goto-char (point-min)) >> (re-search-forward >> "[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"= )) >> >> > Does anybody know why the second character range says [^[\r\n] instead of > [^\r\n]? This seems to explicitly exclude a leading [. > If this is a typo, then here's a patch. --001a11407a7a9adea905521acd31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 16. Juni 2017 um 23:39=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 16. Juni 2017= um 23:34=C2=A0Uhr:
Vincent Bela=C3=AFche <vincent.belaic= he@gmail.com> schrieb am Fr., 16. Juni 2017 um 23:28=C2=A0Uhr:


Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>
>
> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit :
>>

[...]

>>
>>
> After some more investigation, I think that the bug is in function
> insert-file-contents of fileio.c which is the one that decide and sets=
> the coding system well before the other local variables are looked int= o.

After some more investigation, in the end the find-auto-coding of
mule.el is what is called to detect the coding. This function calls some re-coding regexp.

Here is a test function defining the same regexp.


(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (looking-at re-coding) "ok" "nak&= quot;))))

I tried it with point at end of line

[comment]: # ( Local Variables: )

and it answered "ok". Now I defined this with re-search-forward i= nstead
of looking-at:

(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (re-search-forward re-coding nil t) "ok&quo= t; "nak"))))

I placed the point before the coding: line, and I also got answer "ok&= quot;

So I don't think that the regexp as such is to blame. Something else seems to happen. It is too late now, I need to go to bed...

=C2=A0 Vincent.


I think it's actually the regexp that searches for "= Local Variables". The following minimal example fails for me:

(with-temp-buffer
=C2=A0 (insert "
<= br>
[comment]: # ( Local Variables: )
[comment]: # ( coding: ut= f-8 )
[comment]: # ( End: )

")
=
(goto-char (point-min))
(re-search-forward
=C2=A0&= quot;[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]&= quot;))


<= /div>
Does anybody kn= ow why the second character range says [^[\r\n] instead of =C2=A0[^\r\n]? T= his seems to explicitly exclude a leading [.
=

If this is a typo, then here's a patch.=C2=A0
=
--001a11407a7a9adea905521acd31-- --001a11407a7a9adeac05521acd33 Content-Type: text/plain; charset="US-ASCII"; name="0001-Allow-local-variables-section-to-begin-with-a-square-b.txt" Content-Disposition: attachment; filename="0001-Allow-local-variables-section-to-begin-with-a-square-b.txt" Content-Transfer-Encoding: base64 Content-ID: <15cb2e48903d80038a11> X-Attachment-Id: 15cb2e48903d80038a11 RnJvbSAyZjhiYmY3ZTcyOWVhMDlhZGRmMGQwNjY4NjFhM2IzOGMzMTIxNDFkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IEZyaSwgMTYgSnVuIDIwMTcgMjM6NDk6MDkgKzAyMDAKU3ViamVjdDogW1BBVENIXSBBbGxv dyBsb2NhbCB2YXJpYWJsZXMgc2VjdGlvbiB0byBiZWdpbiB3aXRoIGEgc3F1YXJlIGJyYWNrZXQK CkZpeGVzIEJ1ZyMyNzM5MS4KCiogbGlzcC9pbnRlcm5hdGlvbmFsL211bGUuZWwgKGZpbmQtYXV0 by1jb2RpbmcpOiBGaXggcmVndWxhcgpleHByZXNzaW9uIGZvciAiTG9jYWwgVmFyaWFibGVzIiBz ZWN0aW9uLgoKKiB0ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLXRlc3RzLmVsIChmaW5kLWF1 dG8tY29kaW5nLS1idWcyNzM5MSk6CkFkZCB1bml0IHRlc3QuCi0tLQogbGlzcC9pbnRlcm5hdGlv bmFsL211bGUuZWwgICAgICAgICAgICB8ICAyICstCiB0ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9t dWxlLXRlc3RzLmVsIHwgMzkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDIg ZmlsZXMgY2hhbmdlZCwgNDAgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQogY3JlYXRlIG1v ZGUgMTAwNjQ0IHRlc3QvbGlzcC9pbnRlcm5hdGlvbmFsL211bGUtdGVzdHMuZWwKCmRpZmYgLS1n aXQgYS9saXNwL2ludGVybmF0aW9uYWwvbXVsZS5lbCBiL2xpc3AvaW50ZXJuYXRpb25hbC9tdWxl LmVsCmluZGV4IGZhM2FkODBlMmYuLjZjZmI3ZTZkNDUgMTAwNjQ0Ci0tLSBhL2xpc3AvaW50ZXJu YXRpb25hbC9tdWxlLmVsCisrKyBiL2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLmVsCkBAIC0xOTcw LDcgKzE5NzAsNyBAQCBmaW5kLWF1dG8tY29kaW5nCiAJICAoZ290by1jaGFyIHRhaWwtc3RhcnQp CiAJICAocmUtc2VhcmNoLWZvcndhcmQgIltcclxuXVxeTCIgdGFpbC1lbmQgdCkKIAkgIChpZiAo cmUtc2VhcmNoLWZvcndhcmQKLQkgICAgICAgIltcclxuXVxcKFteW1xyXG5dKlxcKVsgXHRdKkxv Y2FsIFZhcmlhYmxlczpbIFx0XSpcXChbXlxyXG5dKlxcKVtcclxuXSIKKwkgICAgICAgIltcclxu XVxcKFteXHJcbl0qXFwpWyBcdF0qTG9jYWwgVmFyaWFibGVzOlsgXHRdKlxcKFteXHJcbl0qXFwp W1xyXG5dIgogCSAgICAgICB0YWlsLWVuZCB0KQogCSAgICAgIDs7IFRoZSBwcmVmaXggaXMgd2hh dCBjb21lcyBiZWZvcmUgImxvY2FsIHZhcmlhYmxlczoiIGluIGl0cwogCSAgICAgIDs7IGxpbmUu ICBUaGUgc3VmZml4IGlzIHdoYXQgY29tZXMgYWZ0ZXIgImxvY2FsIHZhcmlhYmxlczoiCmRpZmYg LS1naXQgYS90ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLXRlc3RzLmVsIGIvdGVzdC9saXNw L2ludGVybmF0aW9uYWwvbXVsZS10ZXN0cy5lbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAw MDAwMDAwMDAwLi4wODRmNjA5YzQ1Ci0tLSAvZGV2L251bGwKKysrIGIvdGVzdC9saXNwL2ludGVy bmF0aW9uYWwvbXVsZS10ZXN0cy5lbApAQCAtMCwwICsxLDM5IEBACis7OzsgbXVsZS10ZXN0cy5l bCAtLS0gdW5pdCB0ZXN0cyBmb3IgbXVsZS5lbCAgICAgICAgIC0qLSBsZXhpY2FsLWJpbmRpbmc6 IHQ7IC0qLQorCis7OyBDb3B5cmlnaHQgKEMpIDIwMTcgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u LCBJbmMuCisKKzs7IFRoaXMgZmlsZSBpcyBwYXJ0IG9mIEdOVSBFbWFjcy4KKworOzsgR05VIEVt YWNzIGlzIGZyZWUgc29mdHdhcmU6IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2Rp ZnkKKzs7IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UgYXMgcHVibGlzaGVkIGJ5Cis7OyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRo ZXIgdmVyc2lvbiAzIG9mIHRoZSBMaWNlbnNlLCBvcgorOzsgKGF0IHlvdXIgb3B0aW9uKSBhbnkg bGF0ZXIgdmVyc2lvbi4KKworOzsgR05VIEVtYWNzIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCis7OyBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorOzsgTUVSQ0hBTlRBQklMSVRZIG9y IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorOzsgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKworOzsgWW91IHNob3VsZCBoYXZl IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKzs7IGFs b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNl bnNlcy8+LgorCis7OzsgQ29tbWVudGFyeToKKworOzsgVW5pdCB0ZXN0cyBmb3IgbGlzcC9pbnRl cm5hdGlvbmFsL211bGUuZWwuCisKKzs7OyBDb2RlOgorCisoZXJ0LWRlZnRlc3QgZmluZC1hdXRv LWNvZGluZy0tYnVnMjczOTEgKCkKKyAgIkNoZWNrIHRoYXQgQnVnIzI3MzkxIGlzIGZpeGVkLiIK KyAgKHdpdGgtdGVtcC1idWZmZXIKKyAgICAoaW5zZXJ0ICJcbltjb21tZW50XTogIyAoIExvY2Fs IFZhcmlhYmxlczogKVxuIgorICAgICAgICAgICAgIltjb21tZW50XTogIyAoIGNvZGluZzogdXRm LTgJKVxuIgorICAgICAgICAgICAgIltjb21tZW50XTogIyAoIEVuZDoJCSluIikKKyAgICAoZ290 by1jaGFyIChwb2ludC1taW4pKQorICAgIChzaG91bGQgKGVxdWFsIChsZXQgKChhdXRvLWNvZGlu Zy1hbGlzdCAoKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAoYXV0by1jb2RpbmctcmVnZXhw LWFsaXN0ICgpKQorICAgICAgICAgICAgICAgICAgICAgICAgIChhdXRvLWNvZGluZy1mdW5jdGlv bnMgKCkpKQorICAgICAgICAgICAgICAgICAgICAgKGZpbmQtYXV0by1jb2RpbmcgIiIgKGJ1ZmZl ci1zaXplKSkpCisgICAgICAgICAgICAgICAgICAgJyh1dGYtOCAuIDpjb2RpbmcpKSkpKQorCis7 OzsgbXVsZS10ZXN0cy5lbCBlbmRzIGhlcmUKLS0gCjIuMTMuMQoK --001a11407a7a9adeac05521acd33--