term_size

Linux: Windows:

A Rust library to enable getting terminal sizes and dimensions

Documentation

Maintenance status

This crate is no longer maintained. It works fine, but the maintainers don't have time and willingness to work on it or review future PRs anymore.

Consider using terminal_size instead.

Usage

First, add the following to your Cargo.toml:

[dependencies]
term_size = "1"

Next, add this to your crate root:

extern crate term_size;

To get the dimensions of your terminal window, simply use the following:

fn main() {
  if let Some((w, h)) = term_size::dimensions() {
    println!("Width: {}\nHeight: {}", w, h);
  } else {
    println!("Unable to get term size :(")
  }
}

License

Copyright Benjamin Sago, Kevin Knapp, and term_size contributors.

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Contributing

1. Fork it!
2. Create your feature branch: git checkout -b my-new-feature
3. Commit your changes: git commit -am 'Add some feature'
4. Push to the branch: git push origin my-new-feature
5. Submit a pull request :D

Minimum Version of Rust

term_size will officially support current stable Rust, minus two releases, but may work with prior releases as well. For example, current stable Rust at the time of this writing is 1.22.1, meaning term_size is guaranteed to compile with 1.20.0 and newer.

At the 1.23.0 stable release, term_size will be guaranteed to compile with 1.21.0 and newer, etc.

Upon bumping the minimum version of Rust (assuming it's within the stable-2 range), it must be clearly annotated in the CHANGELOG.md

Breaking Changes

term_size takes a similar policy to Rust and will bump the major version number upon breaking changes with only the following exceptions:

• The breaking change is to fix a security concern
• The breaking change is to be fixing a bug (i.e. relying on a bug as a feature)
• The breaking change is a feature isn't used in the wild, or all users of said feature have given approval prior to the change