On 2020-10-14 14:47, Jérôme Froissart wrote:
The choice of GetCommandLineA was for illustration purposes;
had I used GetCommandLineW I would not be able to printf
using %ls under CMD.EXE, because of code page issues. However
here is a modified version of the test program that uses
Le mer. 14 oct. 2020 à 23:47, Jérôme Froissart a écrit :
> However, there is still a question that is puzzling me. I now
> understand _why_ things happen that way, but I am still wondering
> whether this is really what we _want_. I mean, keeping the double
> quotes around an UTF-8 argument just
Thank you everyone, I now have a better understanding of how Windows
and Cygwin work (being rather a Linux guy, I was not really aware of
all of this).
However, there is still a question that is puzzling me. I now
understand _why_ things happen that way, but I am still wondering
whether this is
On 2020-10-06 15:36, Jérôme Froissart wrote:
> Here are the more detailed steps to reproduce the issue (along with
> answers to your requests about `uname`, `locale`, etc.).
> (I mostly reproduced what billziss-gh had done before, I do not take
> all the credits :D)
>
> Here is an example C file
On 2020-10-06 14:36, Jérôme Froissart wrote:
Here is an example C file
$ cat example.c
#include
const char *GetCommandLineA(void);
int main(int argc, char *argv[])
{
const char *s = GetCommandLineA();
printf("C=%s\n", s);
for (int i = 0; argc > i;
Greetings, Jérôme Froissart!
> Andrey Repin wrote:
>> 1. Run CMD in a more capable terminal. Either M$ Terminal 1.0, or select true
>> type font for your console.
> I tried Windows Terminal 1.3, but this did not change anything :-(
> Besides, I think my cmd.exe was already using True Type fonts
On 2020-10-07 18:59, Eliot Moss wrote:
> I think what we mean is that, under Windows cmd, some things the shell does
> for
> you under Linux and Cygwin will not have been done. For example, there is
> "glob" expansion of filenames. If I write *.txt under bash, it gets expanded
> to
> a
I think what we mean is that, under Windows cmd, some things the shell does for you under Linux and
Cygwin will not have been done. For example, there is "glob" expansion of filenames. If I write
*.txt under bash, it gets expanded to a space-separated list of names of files that match that
On 2020-10-06 23:17, Thomas Wolff wrote:
>
>
> Am 06.10.2020 um 23:36 schrieb Jérôme Froissart:
>> Thanks for your replies.
>> This issue only happens when a program is run from cmd.exe, not from a
>> Cygwin bash shell.
>> This is important for me, since I discovered this bug in a project
>>
Thanks for your reply.
Andrey Repin wrote:
> 1. Run CMD in a more capable terminal. Either M$ Terminal 1.0, or select true
> type font for your console.
I tried Windows Terminal 1.3, but this did not change anything :-(
Besides, I think my cmd.exe was already using True Type fonts (if I
Am 06.10.2020 um 23:36 schrieb Jérôme Froissart:
Thanks for your replies.
This issue only happens when a program is run from cmd.exe, not from a
Cygwin bash shell.
This is important for me, since I discovered this bug in a project
that must be run from Windows graphical shell (i.e. there is no
On 2020-10-06 15:36, Jérôme Froissart wrote:
> Thanks for your replies.
> This issue only happens when a program is run from cmd.exe, not from a
> Cygwin bash shell.
> This is important for me, since I discovered this bug in a project
> that must be run from Windows graphical shell (i.e. there is
Greetings, Jérôme Froissart!
> Now, let's start a Windows shell (cmd.exe)
That explains it.
> Note that I had to copy cygwin1.dll from my Cygwin installation
> directory, otherwise binary.exe would not start.
> I do not know whether there is a `locale` equivalent in Windows
We've specifically
Thanks for your replies.
This issue only happens when a program is run from cmd.exe, not from a
Cygwin bash shell.
This is important for me, since I discovered this bug in a project
that must be run from Windows graphical shell (i.e. there is no
sensible way to run it through Cygwin and Bash).
>
Greetings, Jérôme Froissart!
> By discussing a merge request on another project [1], I think
> billziss-gh found a weirdness in the way Cygwin parses the command
> line arguments when non-ASCII characters come into play.
> EXPECTED BEHAVIOUR:
> cygwin should parse the following command line
>
On Fri, 2 Oct 2020 at 15:41, Jérôme Froissart <> wrote:
>
> By discussing a merge request on another project [1], I think
> billziss-gh found a weirdness in the way Cygwin parses the command
> line arguments when non-ASCII characters come into play.
>
> EXPECTED BEHAVIOUR:
> cygwin should parse
Hello,
By discussing a merge request on another project [1], I think
billziss-gh found a weirdness in the way Cygwin parses the command
line arguments when non-ASCII characters come into play.
EXPECTED BEHAVIOUR:
cygwin should parse the following command line
binary.exe --non-ascii
17 matches
Mail list logo
