On 2022-02-08 21:13, julie77...@gmail.com wrote:
On Tuesday, February 8, 2022 6:46 PM, Brian Inglis wrote:
On 2022-02-08 15:01, julie77...@gmail.com wrote:
Cygwin doesn't create an environment variable in bash to indicate that
the platform is Cygwin under Windows.
This causes compatibility problems when running various tools. Most of
my issues have been with Python tools running Windows Python.
I have been addressing this issue by grepping PATH for cygdrive which
doesn't seem like a very good approach.
Both msys2 and mingw solve this issue by setting the MSYSTEM
environment variable which lets tools check that OS=Windows_NT and
MSYSTEM=MSYS
Please add some way of identifying that programs are running under
Cygwin.
I have been switching env/OS/arch/triple dependent profile and rc files and
sections for years with:
64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT x86_64
x86_64-unknown-cygwin
32 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT i686
i686-pc-cygwin
Please note that *only* $OS is exported by default (in the above list), so
you will have to explicitly export (in profiles) any other shell variables
you wish to be available to shell subprocesses.
I realize that I can create my own env variables. I just think that
Cygwin should provide them so that programmers writing software can
rely on the variable name and value. If there is no consistent value
when Cygwin is installed then dozens of tools that work on other
bash solutions for Windows can't be made to work on Cygwin.
If you would like information provided, please request the information
you seek, and you are more likely to get a response.
You are making a series of incorrect statements here based on incorrect
assumptions due to lack of relevant information.
Did I suggest you had to set any of those variables?
If you would RTFM e.g. "$ info bash var" you would realize that those
variables named are set by bash, depending on the build target or host
execution environment.
I said *only* $OS is exported by default, such that it is automatically
exported to be available in child processes.
The other variables named have not been automatically exported by
default since bash 2.
You have to explicitly export the other variables named from your bash
login or bash process execution shell to make them available in child
process environments.
Other shells may not provide platform identification or use the same
variable names e.g.
bash $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
x86_64 . x86_64-unknown-cygwin . cygwin .
dash $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .
mksh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .
posh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .
tcsh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
x86_64-cygwin . x86_64 . cygwin . unknown
zsh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. x86_64 . cygwin . pc
in which case utilities may be used or system configuration enquiries
sysconf(3) may be required.
Cygwin also provides the POSIX mandated outputs:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html
64 $ uname
CYGWIN_NT-10.0
32 $ uname
CYGWIN_NT-10.0-WOW
and common Linux and BSD extensions (e.g. -o):
64 $ uname -so
CYGWIN_NT-10.0 Cygwin
64 $ uname -rv
3.3.4(0.341/5/3) 2022-01-31 19:35
$ head /proc/version
CYGWIN_NT-10.0-19044 version 3.3.4-341.x86_64 (corinna@calimero) (gcc
version 11.2.0 20210728 (Fedora Cygwin 11.2.0-2) (GCC) ) 2022-01-31
19:35 UTC
--
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.]
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
