How to ensure that /bin takes priority over System32 with "bash -c"?

Adam Dinwoodie
Sat Oct 31 14:21:05 GMT 2020

On Sat, 31 Oct 2020 at 13:16, Matt D. via Cygwin wrote:
> I can't always know what binaries exist in C:\Windows\System32 when
> writing my scripts. Am I supposed to always launch scripts as "bash
> --login -i -c"? I don't want or need to have bash run all of its login
> scripts unnecessarily.
> How can I run my bash scripts without invoking it as a login shell and
> ensure that /bin has the environment priority over System32 binaries?

Currently, your commands are doing exactly what you tell them: you're
not doing anything to override the PATH from Windows, so they're using
the PATH from Windows.

On a full Linux system, this is generally not an issue, because you
won't have any processes trying to run as children of processes with
Windows PATH variables. For most Cygwin users, this isn't a problem
because they either (a) just accept the performance impact of running
things with a login shell, or (b) (which I suspect is more likely) run
most things from within a login shell or some other environment like
cron that knows how to set the appropriate variables up.

If none of the above are options for you, you'll need to find some way
to set the environment variables you need. This might just be starting
your Bash commands with `export PATH=/bin:/sbin:$PATH`. Alternatively
you could look at using the BASH_ENV environment variable; if you
create, say, /etc/bashenv in Cygwin containing `export
PATH=/bin:/sbin:$PATH` and any other commands you need, and set
BASH_ENV=/etc/bashenv as a Windows system environment variable, I
believe Bash should read that when started up in the way you're using
it, and assuming you don't have any other non-Cygwin Bash programs on
your system (e.g. from Git for Windows), I doubt it'd affect anything



More information about the Cygwin mailing list