<p>Yeah, I know.</p>
<p><a href="https://github.com/eht16" class="user-mention">@eht16</a> I guess this is one of the reasons why <em>spawn</em> didn't use <code>W</code> variants (as it has a comment about encoding conversion):</p>
<blockquote>
<p>GLib converts the argument vector to UNICODE. For non-UTF8 arguments, the result is often "Invalid string in argument vector at %d: %s: Invalid byte sequence in conversion input" (YMMV). Our tools (make, grep, gcc, ...) are "ANSI", so converting to UNICODE and then back only causes problems.</p>
</blockquote>
<p>The thing is that to pass in the search string, we try and pass the binary representation in the specified encoding for the search.  That works OK so long as the spawn code accepts arbitrary byte sequences (well, 0-terminated only), but not if it has to be valid.<br>
Not doing the input conversion on Windows seems to work OK for the input part, not so much in better results or output.  Maybe we could mess a little with <code>LC_CTYPE</code> and set it to <code>LC_CTYPE=${LC_CTYPE%.*}.ourencoding</code>, maybe it'd help.  Or maybe not, I don't know.</p>
<p>I guess this issue is an argument for <a href="https://github.com/codebrainz" class="user-mention">@codebrainz</a>'s proposition of rewriting this with custom code ^^</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/1321#issuecomment-262751191">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJyhUQ2tivuoyN0hrqmJ2-b53Pow2ks5rBXBogaJpZM4K7hbz">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJwNRS6MWprz81muYv9bVGCVLtnK3ks5rBXBogaJpZM4K7hbz.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/issues/1321#issuecomment-262751191"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@b4n in #1321: Yeah, I know.\r\n\r\n@eht16 I guess this is one of the reasons why *spawn* didn't use `W` variants (as it has a comment about encoding conversion):\r\n\r\n\u003e  GLib converts the argument vector to UNICODE. For non-UTF8 arguments, the result is often \"Invalid string in argument vector at %d: %s: Invalid byte sequence in conversion input\" (YMMV). Our tools (make, grep, gcc, ...) are \"ANSI\", so converting to UNICODE and then back only causes problems.\r\n\r\nThe thing is that to pass in the search string, we try and pass the binary representation in the specified encoding for the search.  That works OK so long as the spawn code accepts arbitrary byte sequences (well, 0-terminated only), but not if it has to be valid.\r\nNot doing the input conversion on Windows seems to work OK for the input part, not so much in better results or output.  Maybe we could mess a little with `LC_CTYPE` and set it to `LC_CTYPE=${LC_CTYPE%.*}.ourencoding`, maybe it'd help.  Or maybe not, I don't know.\r\n\r\nI guess this issue is an argument for @codebrainz's proposition of rewriting this with custom code ^^"}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1321#issuecomment-262751191"}}}</script>