Re: [Mingw-w64-public] run system() in something other than cmd.exe?

[David Mathog]

On 10-May-2019 14:52, David Mathog wrote:

Is there a way that a program can do:

   status = system("some command");

Found it right after posting, change "COMSPEC".  Which works, but only 
sort of.

I have a program "execinput" which takes input and for each line does

   system();

Changed COMSPEC in a mintty window in bash shell to point to bash, then 
did


  set COMSPEC='C:\progs\msys32\usr\bin\bash.exe'
  echo 'pwd' | execinput
  (prints the current directory)  #<-- in cmd.exe pwd throws an error, 
so it is in bash

  echo 'ls -al' | execinput
  (lists as expected)
  echo 'echo one' | execinput
  one
  #it goes wrong at the next command
  echo 'echo one ; echo two ; echo three' | execinput
  one ; echo two ; echo three
  echo 'echo one & echo two & echo three' | execinput
  one
  two
  three

So it seems to work for ONE command, but for a compound command
for whatever reason it expects cmd.exe style command separators and not 
bash ones.


Is some other environmental variable required to make compound commands 
work?


Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] run system() in something other than cmd.exe?

[David Mathog]

Is there a way that a program can do:

   status = system("some command");

and have it run in an environment other than cmd.exe?  Perhaps by 
setting some
environmental variable(s) before calling system()?  Or maybe there is 
some system_variant()

function which can do this?

Currently if a shell script is running in an MSYS2 bash environment and 
calls a program which then does a system() call the command executes in 
cmd.exe, which for most linux or unix scripts is not at all the 
environment that command expects!


Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Update OpenGL headers

[LRN]

On 10.05.2019 15:53, NightStrike wrote:
> On Fri, May 10, 2019, 5:24 AM LRN wrote:
> 
>> TBH, i'm starting to think that we should radically cut the GL headers
>> down and
>> only ship GL.h and GLU.h, just like MS does (and also glaux.h, probably).
>> The
>> rest can be installed separately.
>>
>> In case anyone still thinks that shipping a full set of OpenGL headers in
>> MinGW-w64-headers is a good idea, here's the patch that updates the
>> headers to
>> a fresh git revision.
>
> Why remove them?

Because someone has to keep them up to date as long as they are part of
mingw-w64-headers.

An analogy: if we pretend for a second that a small part of the Boost headers
(that Boost authors do not edit) is documented to be mandatory for inclusion in
mingw-w64-headers, then shipping all GL headers is equivalent to shipping all
Boost headers.



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] include/ddk: Synchronize with ReactOS (1/2).

[Jacek Caban]

On 5/8/19 4:08 AM, Liu Hao wrote:

All DDK headers have been copied from
.
There are quite a few new headers which will be added later.

This commit contains all headers that have been modified.



What did you do about mingw-w64 modifications?


Jacek



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] include/ddk: Synchronize with ReactOS (2/2).

[Liu Hao]

All DDK headers have been copied from
.
There are quite a few new headers which will be added later.

This commit contains all headers that have added.

Signed-off-by: Liu Hao 


[This is a huge patch so I have to compress it before sending.]


-- 
Best regards,
LH_Mouse


-- 
Best regards,
ltpmouse


signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] snprintf() is broken in mingw-w64

[Pali Rohár]

Hello!

snprintf() function in mingw-w64 is broken. Seems that it just calls
MSVC's _snprintf() function which is not same as snprintf(). MSVC until
ucrt does not provide snprintf() at all, just _snprintf().

Differences are that MSVC's _snrpintf() does not ensure that filled
buffer would be null-termed and when overflow occurs it returns -1
instead of length which is needed to fully format string.

See following example:

  #include 

  int main() {
char buf[5] = "";
int ret = snprintf(buf, 3, "%d", 123456789);
printf("buf=%s ret=%d\n", buf, ret);
return 0;
  }

It prints:

  buf=123X ret=-1

So for MSVC's _snprintf() it is needed to write wrapper, e.g. following:

  #define snprintf(str, size, format, ...) ( (((size_t)(size) > 0) ? 
(_snprintf((str), (size), (format), __VA_ARGS__), ((char 
*)str)[(size_t)(size)-1] = 0, 0) : 0), _scprintf((format), __VA_ARGS__) )

It is simple inline-able macro so it does not increase executable code
size too much.

MSVC's _scprintf() function returns length of formatted string, so
exactly what snprintf() return value should be.

With that snprintf() define, output of above example is:

  buf=12 ret=9

Which is correct now.

Would you consider fixing snprintf() in mingw-w64?

Similarly also vsnprintf() can be fixed:

  #define vsnprintf(str, size, format, ap) ( (((size_t)(size) > 0) ? 
(_vsnprintf((str), (size), (format), (ap)), ((char *)str)[(size_t)(size)-1] = 
0, 0) : 0), _vscprintf((format), (ap)) )

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Update OpenGL headers

[NightStrike]

Why remove them?

On Fri, May 10, 2019, 5:24 AM LRN  wrote:

> TBH, i'm starting to think that we should radically cut the GL headers
> down and
> only ship GL.h and GLU.h, just like MS does (and also glaux.h, probably).
> The
> rest can be installed separately.
>
> In case anyone still thinks that shipping a full set of OpenGL headers in
> MinGW-w64-headers is a good idea, here's the patch that updates the
> headers to
> a fresh git revision.
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public