Fix MSYS=wincmdln, and enable it by default #10
Conversation
…nvironment variables to Windows form for native Win32 applications. This reinstates the MSYS=wincmdln functionality that was inadvertently broken by the patch: with that setting, all processes spawned by MSYS2 are supposed to fill the CommandLine field in the process information so that e.g. `wmic process list` can see it (otherwise, only the executable itself is listed in the command line, but all the arguments are missing). Signed-off-by: Johannes Schindelin <[email protected]>
|
I marked this up as a FWIW I wonder whether we should also make |
|
If I understand this correctly this is for non-cygwin binaries in which case the path would have been hit anyway because !real_path.iscygexec(). Am I missing something? (unrelated, as you might have noticed I've changed the default branch for this repo and added CI. I hope that's ok) |
|
Based on my debugging experience, missing command line arguments are an issue in cygwin processes, not Win32 ones. |
|
Assuming there's no disadvantage to this feature, I would like this turned on by default (or hard-coded even). |
No, this is for MSYS2/Cygwin binaries. If you call, say,
There is only one disadvantage that I can see: as the shown command-line is not the actual command-line as used by MSYS2/Cygwin, there might be discrepancies. The most obvious one comes when the command-line is longer than 32k: this is allowed in MSYS2 when calling another MSYS2 process, but it would be shown truncated by However, I think you're right: this should be the default nevertheless because the surprise of not seeing any command-line arguments is bigger than the surprise of seeing a potentially truncated one. Having said that, I do want to give users an "escape hatch" in case they absolutely want Cygwin's default behavior, so I am more in favor of just switching the default and support opting out (via |
|
I just added a commit to enable |
Okey dokey. |
|
Sure. But did you add that second commit? I can't see it. |
ok, I was confused since the commit says "for native Win32 applications". Thanks for the explanation. With my very limited cpp/cygwin experience, your explanation makes sense, so lgtm. |
I had pushed it, but to another remote. D'oh! Sorry ;-) |
dscho
force-pushed
the
fix-wincmdln-in-msys2
branch
2 times, most recently
from
1a17369 to
fae9acd
Compare
|
FWIW this is the second commit I was talking about. |
|
Should the docs be updated or do we not care about them? |
|
|
It is hard for me to follow the code, but comparing our current code and your patched code both to upstream code, yours seems to be more logical. I'm assuming it builds and does what it says on the tin. |
In the Cygwin project, it was decided that the command-line of Cygwin processes, as shown in the output of `wmic process list`, would suffer from being truncated to 32k (and is transmitted to the child process via a different mechanism, anyway), and therefore only the absolute path of the executable is shown by default. Users who would like to see the full command-line (even if it is truncated) are expected to set `CYGWIN=wincmdln` (or, in MSYS2's case, `MSYS=wincmdln`). Seeing as MSYS2 tries to integrate much better with the surrounding Win32 ecosystem than Cygwin, it makes sense to turn this on by default. Users who wish to suppress it can still set `MSYS=nowincmdln`. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
fix-wincmdln-in-msys2
branch
from
fae9acd to
d1fe488
Compare
I was on the fence, as the documentation still talks about
Basically, @Alexpux' patch erroneously moves the My patch moves the
Yes, I tested (and just re-tested, to be sure) the built |
This ports the patches from msys2/msys2-runtime#10 to the actual package definition used to build the `msys2-runtime` package. Signed-off-by: Johannes Schindelin <[email protected]>
|
offtopic, would it make sense to rename this repo to msys2-runtime? To make the relation to the package more clear? |
Sure. In Git for Windows, we did exactly that: https://github.com/git-for-windows/msys2-runtime/ |
|
👍 done |
gcc-14 will default to c99 and as a result a fair amount of old code in newlib
(particularly libgloss) is failing to build. I don't offhand know how many
patches will be necessary to fix the various failures. I'll just pick them off
one by one from my tree.
This particular patch works around the return-mismatch problem syscalls.c for
fr30.
That file is a bit odd in that most functions are declared as returning an
integer, but the implementations look like:
> int
> _read (file, ptr, len)
> int file;
> char * ptr;
> int len;
> {
> asm ("ldi:8 %0, r0" :: "i" (SYS_read) : "r0");
> asm ("int #10");
>
> return;
> }
Note the lack of a value on the "return" statement. The assumption is that the
interrupt handler implementing syscalls will put the return value into the
proper register, so falling off the end of the C function or returning with no
value works in the expected way. It's not good code, but it probably works.
Working from that assumption I decided to just use a pragma to disable the
upgraded diagnostic from GCC -- essentially preserving existing behavior.
This is the only fr30 specific issue that needs to be resolved and the only
issue (so far) I've seen of this specific nature.
This is apparently broken since 2015...