This allows other libraries to interact with this library more intelligently.

I was a HUGE fan of Jeweler.

But it is well and gone now. There was a fork, called juwelier, but it has an invalid copyright notice and license issues which get flagged by automated license checkers, so I would recommend against using it. I have been trying for several years to assist with fixing the issues with juwelier, but it iseems it has also fallen into disrepair.

I've been using svenfuchs' gem-release for a few years, and it has served me very well.

However, there are now built-in tools that can serve the purpose of releasing, and bumping the version manually isn't that hard.

rake gemspec causes self-dependency.

See: technicalpickles/jeweler#188
And: #5

technicalpickles recommends that we remove the gemspec entry in Gemfile and maintain duplicate dependency entries in gemspec and Gemfile. This is contrary to the Bundler recommendations, but may be necessary to work with Jeweler too.

Or... we could remove Jeweler. Here's some links that describe what life is like without Jeweler.

• http://gembundler.com/rubygems.html
• http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/
• http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

Both ways have their advantages. I will be happy to support whichever way you decide to go.

Ancient autotest library is dead. Switch to guard-rspec

• Switch to guard-rspec

This will allow automated comments to pull requests that summarize how the PR will change the test coverage.

See https://dev.to/pboling/ippccr-in-pursuit-of-perfect-code-coverage-reporting-3a2i

The copyright year in the license should list every year that the code received an update.

https://opensource.stackexchange.com/questions/5778/why-do-licenses-such-as-the-mit-license-specify-a-single-year

It will be great to have:

• Total RAM.
• RAM usage.
• Free RAM.
• Total SWAP.
• SWAP usage.
• Free SWAP.
• Number of running procs.
• Number of disks.
• Usage of each disk.
• Network devices, MACs, IPs, etc.

Thank you!

Feature request - detect when the OS is sleeping and waking. My particular interest is on macOS.

Yes, even on Ruby < 1.9

From 2009:
https://tomayko.com/blog/2009/require-rubygems-antipattern

Ruby 1.8.7 was released 2008-05-31.

A circular reference has occurred and gem install is no longer possible.

$ gem install os
ERROR:  While executing gem ... (Gem::Resolver::Molinillo::CircularDependencyError)
    There is a circular dependency between os and os

Version 1.0.1 is released: https://rubygems.org/gems/os

I don't see a 1.0.1 tag in this repository. Is this intended?

Maybe, you could use KeepAChangelog instead of the custom log format (https://github.com/rdp/os/blob/master/ChangeLog). 😇

Somehow the OS gem on rubygems.org seems to have ended up with a dependency on itself. I can't install it unless I have a prior version installed:

$ gem install os
Fetching: os-0.9.1.gem (100%)
ERROR: Error installing os:
os requires os (>= 0)

Changing the focus of this issue to "Specs don't pass on MacOS".

..................F..F..............

Failures:

  1) OS has working cpu count method
     Failure/Error: assert (cpu_count & (cpu_count - 1)) == 0 # CPU count is normally a power of 2
     Test::Unit::AssertionFailedError:
       <false> is not true.
     # ./spec/os_spec.rb:124:in `block (2 levels) in <top (required)>'

  2) OS should provide a path to directory for application config
     Failure/Error: assert OS.app_config_path('appname') == '/home/xdg/Library/Application Support/appname'
     Test::Unit::AssertionFailedError:
       <false> is not true.
     # ./spec/os_spec.rb:150:in `block (2 levels) in <top (required)>'

Finished in 0.03682 seconds
36 examples, 2 failures

The previous issue related to upgrading to RSpec 3 will be in #67

Same OS, different Rubies (64-bit and 32-bit):
$ uname -a
MINGW64_NT-10.0 name 2.5.0(0.295/5/3) 2016-03-31 18:47 x86_64 Msys
$ ruby -e 'require "os";p RUBY_PLATFORM;p OS.bits'
"x64-mingw32"
64
$ ruby -e 'require "os";p RUBY_PLATFORM;p OS.bits'
"i386-mingw32"
32

When we check for Ruby warnings (in order to clean up and improve our own code), a minimal use of the gem produces these (messy) warnings:

$ ruby -r os -w -e' '
os-0.9.6/lib/os.rb:154: warning: mismatched indentations at 'end' with 'for' at 151
os-0.9.6/lib/os.rb:158: warning: assigned but unused variable - kb
os-0.9.6/lib/os.rb:198: warning: mismatched indentations at 'end' with 'def' at 190
os-0.9.6/lib/os.rb:240: warning: mismatched indentations at 'end' with 'case' at 218

The same warnings are emitted on Windows, as well (of course).

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 2.6.4
  - RUBY VERSION: 2.3.1 (2016-04-26 patchlevel 112) [x86_64-linux]
  - INSTALLATION DIRECTORY: /home/mark/.rvm/gems/ruby-2.3.1
  - USER INSTALLATION DIRECTORY: /home/mark/.gem/ruby/2.3.0
  - RUBY EXECUTABLE: /home/mark/.rvm/rubies/ruby-2.3.1/bin/ruby
  - EXECUTABLE DIRECTORY: bin
  - SPEC CACHE DIRECTORY: /home/mark/.gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /home/mark/.rvm/rubies/ruby-2.3.1/etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /home/mark/.rvm/gems/ruby-2.3.1
     - /home/mark/.rvm/gems/ruby-2.3.1@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - bin
     - /home/mark/.rvm/gems/ruby-2.3.1@global/bin
     - /home/mark/.rvm/rubies/ruby-2.3.1/bin
     - /usr/local/bin
     - /usr/bin
     - /bin
     - /usr/local/games
     - /usr/games
     - /home/mark/.rvm/bin

I'd like to ask to get tag for gem release 1.1.4 tagged and released. Not sure which commit, maybe f1f4c33?

Reasoning:
It's not just important that it is easy to map tags to actual releases in the source tree. But for distro packaging we actually require to have a matching git tag for every release as the rule of thumb is to build from the version control state in order to aid transparency and confidence in public reviewed code etc.

Problem:
As of the above, the missing tag for 1.1.4 create the issue for me that i can't package ruby-os for our Distro currently.

Related to #36

Forgive me if I've missed something obvious, but I can't seem to find any mention of which license this code is released under.

If this gem is not following semantic versioning - please ignore and close this issue.

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

http://semver.org/

So I would consider bumping version to 1.something.something (currently it is "0.10.0").

When Ruby is running inside of WSL, it can be difficult to tell the difference between truly running on Linux and running within WSL.

The best way I have found to identify if it is WSL is...

def self.wsl?
  `cat /proc/version` =~ /Microsoft/ if linux?
end

I am happy to submit a patch and test if wanted.

This gem only needs yaml for the OS.report method. Most users aren't using this method. Could you move the require "yaml" line inside the report method so the gem boots much faster?

I will be working on steps to test this across mutliple versions of ruby (using rvm).

Hello

The top level of your gem should be a module, not a class, to follow standard conventions.

Problem

Errors:

An error occurred while loading ./spec/os_spec.rb.
Failure/Error: config.expect_with :rspec, :stdlib # enable `should` OR `assert`

ArgumentError:
  :stdlib is not supported
# ./spec/spec_helper.rb:8:in `block in <top (required)>'
# ./spec/spec_helper.rb:7:in `<top (required)>'
# ./spec/os_spec.rb:1:in `require'
# ./spec/os_spec.rb:1:in `<top (required)>'

An error occurred while loading ./spec/osx_spec.rb.
Failure/Error: config.expect_with :rspec, :stdlib # enable `should` OR `assert`

ArgumentError:
  :stdlib is not supported
# ./spec/spec_helper.rb:8:in `block in <top (required)>'
# ./spec/spec_helper.rb:7:in `<top (required)>'
# ./spec/osx_spec.rb:1:in `require'
# ./spec/osx_spec.rb:1:in `<top (required)>'

Warnings:

Deprecation Warnings:

Requiring `rspec/autorun` when running RSpec via the `rspec` command is deprecated. Called from /Users/pboling/src/my/moss/spec/spec_helper.rb:5:in `require'.

Solution

Use modern RSpec patterns, for example:

• Upgrade to RSpec 3 syntax via transpec

or maybe wait for them to fix their junk, then just use RbConfig.ruby if it's available, instead? (sure...add assertion that jruby version is > X why not?)

but what about 1.8...hmm...we still need our own extra magic for jruby 1.8 from jar though...

In order to do this, and not issue a major version bump, it would be ideal to first determine the oldest version that currently works with the gem, and specify that as the spec.required_ruby_version. This will have the effect of explicitly "dropping" everything that already doesn't work.

Based on #2 it would seem that this gem originally supported Ruby 1.8, and it seems like that may be the best initial value of required_ruby_version.

If you do want to do a major version bump later you could drop older Rubies at that time.

Note that require_relative wasn't added until Ruby 2.1, so it wouldn't be useable until the required ruby version has surpassed that number.

If there are any other features you'd like, let me know, I'll do what I can to add them :)

Here's a relevant StackOverflow question. Quoting JP:

In Mac OS X I'll put user-specific files for my app in ~/Library/Application Data/{{MyApp}}/ and in Unix I'll put them in ~/.{{MyApp}}/ — where should I put them for Windows?

and quoting mikel's answer:

On Windows, it's ENV['APPDATA']

which I interpret as File.join((File.expand_path ENV['APPDATA']), '{{MyApp}}'). For me, this results in:

C:/Users/Mark/AppData/Roaming/{{MyApp}}

(For the above occurrences of {{MyApp}}, we should substitute the actual name of the application—of course.)

So, a cross-platform method, whose purpose would be to return the location where we should place user-specific files, perhaps optionally with (or without) the suffixes /{{MyApp}}/ or /.{{MyApp}}/, would be useful, and simple to use. (Also, IMO it falls in the bailiwick you've undertaken with this gem.)

Presumably, an attempt should be made to match existing practice. Often on Windows (in particular), configuration files (which comprise just one of the many kinds of user-specific files targeted by this suggested feature) are placed in one of two locations: ENV['APPDATA'] or ENV['HOMEPATH'].

BTW, when running the RubyInstaller's Ruby, the result of ENV['HOME'] seems set to the same location as ENV['HOMEPATH'].

https://keepachangelog.com/en/1.0.0/

This is a dependency of docker-sync, I have the following error when starting it:

in `freebsd?': undefined method `freebsd?' for OS:Class (NoMethodError)

in this location

Operating system: Manjaro (Arch Linux derivative)
Ruby version: 2.5.3
Gem version: 1.0.0

1.1.1 appears to have been released, but it's difficult to see exactly what changed without either of these artifacts. It appears to be this diff.

ex:

class OS
  if RUBY_DESCRIPTION =~ /mingw/
    def windows?; true; end
  else
   def windows? false; end
  end
end

That type of thing.

def Driver.rss_current
if RUBY_PLATFORM =~ /darwin/
ps u | grep #{Process.pid} | grep -v grep.strip
elsif RUBY_PLATFORM =~ /mingw|mswin/
0
else
# assume linux
(File.read "/proc/#{Process.pid}/statm").strip
end
end

and also rbs

Is there any support for detecting AARCH64 on Mac & Linux yet (was hoping for a OS.aarch64? method)? If not, would you have any tips on how to figure that out using this gem or some other ways (I noticed OS.host_cpu returns what I likely need, but I'm on a non-AARCH64 computer right now, so I'd have to test later on an AARCH64 machine)?

Thanks for providing such a useful and API friendly gem. I have been using on and off for over a decade.

Best,

AMaleh

I found that the files inside os gem are world writable. Is it possible to change the permissions?

how about mri for 1.8, kri for 1.9?

Hey,

I am running into an issue with mixed line endings (some from DOS, some from Unix). I just found these instructions: http://help.github.com/dealing-with-lineendings/. It looks like, once configured, github will ensure the files in the repo have a single line ending, but it is converted for editing on each platform. Does that sound like a good idea to you?

maybe add a new method that does include them...hmm...

Trivy scanner reports os pulls vulnerable rake, probably due to https://github.com/rdp/os/blob/master/Gemfile.lock#L11

==================================================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                TITLE                 |
+---------+------------------+----------+-------------------+---------------+--------------------------------------+
| rake    | CVE-2020-8130    | HIGH     | 0.9.6             | 12.3.3        | rake: OS Command Injection           |
|         |                  |          |                   |               | via egrep in Rake::FileList          |
|         |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-8130 |
+---------+------------------+----------+-------------------+---------------+--------------------------------------+

https://guides.rubygems.org/

There are too many to list, but a ton of them are included out of the box with a bundle gem os command.

yup
and rubygems, too :) [and how broken rubygems is about it]