The system include path and system library path are hard-coded into the pkg-config executables as UNIX style paths. That leads to those paths not matching literally in the MinGW environments where paths are converted to Windows paths.
Also set environment variables with the same paths. That works because environment variables are automatically converted for MinGW executables.
In 73e06b9d4c (bash.bashrc: Update PS1 if PS1 wasn't exported. Closes
#653, 2016-07-14), we updated `/etc/bash.bashrc` to avoid overriding
`PS1`, but the way it was done requires `cut.exe` to be in the `PATH`.
Now, while _most_ of the time we're running inside a login Bash where
the `PATH` has been appropriately modified, sometimes we don't. In that
case, `cut.exe` is not in the `PATH`.
We should not spawn a new process, anyway, as spawning processes is
really expensive in the MSYS2 runtime because of all the contortions
necessary to emulate the POSIX syscall `fork()`.
Let's just avoid that extra process by using `case`, which is a Bash
built-in and therefore won't cost much time to run.
This fixes https://github.com/git-for-windows/git/issues/3652
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When launching a custom msys2 environment, and it does "first-run"
operations, it complains that: "cannot change permissions of
'/dev/shm': Permission denied".
This is related to the previous work in this area that happened
in #2337: Since "/" is mounted with noacl and chmod() is a no-op,
this error is cosmetic and can be removed.
However, in #2337, the access modifying behaviour was not removed
from the "mkdir" branch, which this patch aims to address.
They get started in the background and stay around which comes with various problems:
* The files can't be deleted until they are stopped
* Some CI systems wait until all programs are stopped
* On a cygwin update we have to restart everything or forking will be broken
(though pacman takes care of that now by killing everything cygwin-like on a core update)
Ideally though they would just exit in a controlled way after we no longer need them.
The reason this uses GNUPGHOME instead of passing --home to gpgconf is that dirmngr started by
"pacman-key --refresh-keys" somehow couldn't be killed that way.
Maybe because gpg doesn't forward --homedir in that case. Setting GNUPGHOME helped.
We want configure to always go through our config.site. It first
looks at CONFIG_SITE, then the prefix if there is one and then falls
back to our default. But this means if a prefix is set it wouldn't
use it.
Fix this by setting CONFIG_SITE always like before.
Broken by 9a37bb560a
Although the default and most used way to install MSYS2 is to have it
user-writable, some users prefer to have the root writable only to
admins. In that case, the 01-devices.post script would always print out
two failures on "login" when trying to chmod /dev/{shm,mqueue}. Since
the only supported configuration for MSYS2 is to mount `/` with noacl
where chmod() is a no-op, the failure is purely cosmetic, as is the
chmod invocation itself. For these reasons, let's not chmod at all.
I'm aware the non-user-writable root configuration itself is not
officially supported either, but I've been using it like that for years
now and this is the only issue I know of, so I think it's reasonable to
resolve this.
It calls install-info on all info files on the first MSYS2 start, but all
the info files are already installed in our current installer.
I'm not 100% sure why this was added, but I guess because of #1998 the installer
created in a chroot didn't install the info files properly and thus they were
missing on a fresh install. This is no longer the case now.
regen-info.sh is called in /etc/profile and part of the "backup" array in the PKGBUILD
so the call might not be removed if the user has changed /etc/profile. Since it is only
called in the first MSYS2 session this shouldn't lead to any problems.
msys2-base was removed from dash and filesystem, but filesystem gets updated
first and then fails beause it would break dash which hasn't been updated yet.
So add the provides back.
This fixes:
error: failed to prepare transaction (could not satisfy dependencies)
:: installing filesystem (2020.02-3) breaks dependency 'msys2-base' required by dash
Behavior about the value of HOSTTYPE and MACHTYPE is not compatible
between various POSIX compliant shells. For example zsh doesn't set
HOSTTYPE at all and set MACHTYPE to that of HOSTTYPE in bash. I
checked source tree of bash and found that HOSTTYPE is set to the
result of `uname -m` and that MACHTYPE is set to the result of `uname
-m` plus "-pc-msys".So change code accordingly.
This fixes issue #2008.
Co-authored-by: Yasuhiro KIMURA <yasu@utahime.org>
* Remove double quotes of the LOGINSHELL
When set shell arguments, LOGINSHELL has double quotes.
In the default, L6: set "LOGINSHELL=bash".
I followed the format it.
* Add value to $SHELL for zsh
Issue:
1. Run, C:\msys64\msys2_shell.cmd -mingw64 -shell zsh
2. echo $SHELL
3. Nothing
* Fix msys2_shell.cmd argument-handling with spaces
Commit 11ba641bed intended to preserve [`cmd.exe` delimiter characters](https://ss64.com/nt/syntax-esc.html#delimiters) in the command line passed on to `bash`, but broke the handling of `-where` directories with spaces in them. Fix this by:
- Incrementing `shiftCounter` with any quoted arguments treated as separate words, because the `FOR /F ... IN`-loop at the end cannot treat them (in the full command) as single parameters.
- Using the full list of `cmd.exe` delimiters in the `FOR /F ... IN`-loop when skipping the initial tokens.
Tested this with:
```
C:\msys2\msys2_shell.cmd -defterm -no-start -mingw64 -where <DIR> -shell bash -c $@ -- echo hello there, --world=windows
```
where `<DIR>` is the following:
- C:\Users
- C:\Progra~1
- "C:\Program Files"
- "C:\Program Files (x86)"
- "C:\Users\T-17\Documents\Projects and Learning\test,dir"
Fixes#1826
* Clean up `FOR /F ... IN`-command
* Clean up working variables
* Adhere to lowercase CALL convention
* Prefix working variables with `msys2_` to prevent collisions with user-defined variables
* Don't clobber quotes and parentheses in final Bash command line
* Prevent warning trace on no arguments
* Handle cmd.exe metacharacters (e.g. parentheses) in Bash command line
Consider this inline invocation in a Windows Command Prompt:
```
C:\msys2\msys2_shell.cmd -defterm -no-start -mingw64 -here -c $@ -- echo hello there, --world=windows
```
This currently produces:
>hello there, --world windows
Note the absence of the `=` character. This is due to the word-splitting done by `cmd.exe` to form the positional parameters (`%1` - `%9`). The same word-splitting is not done on the `%*` special variable, so derive the remaining command line arguments.
With this fix, the above command produces:
>hello there, --world=windows
Biswapriyo Nath