Issue #16742 has been updated by Eregon (Benoit Daloze).


For `RbConfig.host_os` I expect the same as `RbConfig::CONFIG['host_os']`, or better slightly simplified (no version, no variant information)
like `linux`, `darwin`, `mingw`, `mswin`, etc (easier to check, and we could document the various possible values).

Similar to process.platform() on Node.js:
https://nodejs.org/api/process.html#process_process_platform (except win32 => windows)

For `RbConfig.windows?` that would include at least mswin and mingw.

Not sure about cygwin, what do you think @MSP-Greg?
WSL would clearly be false for `RbConfig.windows?`, so I think it should be `false` for cygwin too since it also tries to hide the fact you're on Windows.

There are many checks for Windows for various reasons, but notably for whether some system features are supported.
Some of them can be checked more directly (e.g., fork, unix sockets) but not all (e.g., proper support for creating symlinks) which explain why we see `RUBY_PLATFORM =~ /(mswin|mingw)/` in so many gems and tests and specs.

----------------------------------------
Feature #16742: RbConfig.windows? and RbConfig.host_os
https://bugs.ruby-lang.org/issues/16742#change-85008

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I think adding these two methods would greatly clarify platform checks:
```ruby
RbConfig.windows? # obvious, much clearer than RUBY_PLATFORM =~ /(mswin|mingw)/
RbConfig.host_os # same as RbConfig::CONFIG['host_os'], but much shorter
```

`RbConfig::CONFIG['host_os']` is too long and feels like digging in the internals even though it's such a simple thing to query.


For comparison, there is already a `RbConfig.ruby` method on `RbConfig`, which helps avoiding the boilerplate to access `RbConfig::CONFIG` manually.

Thoughts?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>