In case we have a git clone from Linux that is accessed via cygwin git
the files executable status will be derived from the file content (shebang)
and won't match the git repo, leading to a initially dirty tree.
This can be worked around by setting "core.filemode=false", but let's try
to match the cygwin permissions with the in-repo permissions so this isn't
needed.
As pointed out in the removed comments, this doesn't seem to do
what it was added for. The initial motivation comes from
http://cygwin.com/ml/cygwin/2012-01/msg00201.html but the lower
case tmp/temp don't seem to affect Windows programs.
GetTempPath() and GetEnvironmentStrings() see the uppercase version
here, so do perl and ruby. Only python for some reason prefers
the lowercase version.
Also cygwin and git-for-windows removed this long ago.
Avoid the confusion and remove both env vars.
We now provide ~/.inputrc as /etc/inputrc since fd25584fe30bc4fc
This means that on the first start we will execute /profile, which
writes various bash related files to $HOME, which bash will execute
after /profile is finished.
So with ~/.inputrc out of the way the environment on the first start
should be the same as the second one, so we can remove the restart
warning at the beginning.
The question remains if we should still call "clear" at the end, hiding
the setup process. I decided for removing it and enclosing the setup with
some colored status message. This hopefully is not too confusing for
users seeing the intial process and still allows an easy way to see the logs
if something goes wrong.
The main reason we have the first install warning still is that we
fill $HOME with bash related scripts that will only get executed
on the next login shell.
Simplify things by keeping MAYBE_FIRST_START logic in one file
and make it depend on wether $HOME was missing at the beginning.
Inline the call to cygpath into the loop to avoid it being
called in case all files already exist.
Remove call to chmod, it doesn't do anything in MSYS2.
Saves ~20ms here
It is undocumented and hasn't been touched in 8+ years.
If someone is missing it we can include it in dev-tools or
some other msys2 developer oriented package.
Current cygwin fails to delete or create /dev, since it's always
available as a virtual directory. rm fails because it's not empty
and mkdir fails because it already exists.
We could shell out to cmd.exe, but let's just continue to assume that
/dev exists in the installer base.
Also saves a useless mkdir call.
This was added in e259adce916745c3934
(1) this isn't executed if bash_profile exists, which is the default
and (2) I don't think we should include msys2 development related functions
here
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 9a37bb560a94ab9c
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.
