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

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

[Matt D.]

I have Cygwin's /bin directory configured to be available on my login
environment PATH by default. This behavior is inherited when I run a
bash login shell:

$ where sort
C:\cygwin\bin\sort.exe
C:\Windows\System32\sort.exe

But if I run the following script from a Windows command prompt:

C:\> bash -c "where sort"
C:\Windows\System32\sort.exe
C:\cygwin\bin\sort.exe

This creates problems when I want to run a bash script from a process
that does not inherit my login environment. Scripts can fail
unexpectedly where identically named binaries from System32 take
priority.

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?

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

[Adam Dinwoodie]

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
else.

HTH

Adam

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

[Brian Inglis]

On 2020-10-31 08:21, Adam Dinwoodie wrote:
> 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
> else.

Remember 'where' is like the Windows version of Cygwin which or whereis, so you
see only the Windows view of the current PATH:

$ where where /t
     33280   2019-03-18      22:46:08  C:\Windows\System32\where.exe

I export to the env or prefix any such commands, for example, commands that
start another mintty window in some arch, WSL distro, etc. or run a script in
one of those, with BASH_ENV=$HOME/.bash_env:

$ head ~/.bash_env
#|/bin/bash
# ~/.bash_env - set up bash environment for non-login non-interactive shells
export PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:$PATH"

-- 
-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]