Giter Site home page Giter Site logo

checked-command's Introduction

mapped-command

Version 0.2.x is a very thin wrapper to std::process::Command and can be found here: in the 0.2 branch

Provides an alternative to rust's std::process::Command which is more testable, flexible and prevents the way to easy class of bugs where the programmer forgets to check the exit status of a process as intuition tels us a "failed command" should return a error. (But the error in std::process::Command is about failing to launch a sub-process and doesn't care about exit codes at all).

For now this is focused on cases which wait until the subprocess is completed and then map the output (or do not care about the output).

Currently this type contains following features:

  • by default check the exit status

  • bundle a mapping of the captured stdout/stderr to an result into the command, i.e. the Command type is Command<Output, Error> e.g. Command<Vec<String>, Error>.

  • implicitly define if stdout/stderr needs to be captured to prevent mistakes wrt. this, this is done through through the same mechanism which is used to define how the output is mapped, e.g. Command::new("ls", ReturnStdoutString) will implicitly enabled stdout capturing and disable stderr capturing.

  • allow replacing command execution with an callback, this is mainly used to allow mocking the command.

  • besides allowing to decide weather the sub-process should inherit the environment and which variables get removed/set/overwritten this type also allows you to whitelist which env variables should be inherited.

  • do not have &mut self pass through based API. This makes it more bothersome to create functions which create and return commands, which this types intents to make simple so that you can e.g. have a function like fn ls_command() -> Command<Vec<String>, Error> which returns a command which if run runs the ls command and returns a vector of string (or an error if spawning, running or utf8 validation fails).

  • be generic over Output and Error type but dynamic over how the captured stdout/err is mapped to the given Result<Output, Error>. This allows you to e.g. at runtime switch between different function which create a command with the same output but on different ways (i.e. with different called programs and output mapping, e.g. based on a config setting).

Mini Example

Use cargo run --example readme to run this:

use mapped_command::{Command, CommandExecutionWithStringOutputError as Error, MapStdoutString};

fn ls_command() -> Command<Vec<String>, Error> {
    Command::new(
        "ls",
        MapStdoutString(|out| {
            let lines = out.lines().map(Into::into).collect::<Vec<_>>();
            Ok(lines)
        }),
    )
}

fn main() {
    let entries = ls_command().run().unwrap();
    println!("ls:");
    for entry in entries {
        println!("\t{}", entry);
    }
}

For other examples e.g. about how the mocking works take a look at the examples dir or the module level documentation produced by rustdoc which likely should be hosted on docs.rs. Be aware that the link leads to the latest released version and might as such be out of sync if updates have not yet been released.

License

Licensed under either of

at your option.

Contribution

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.

checked-command's People

Contributors

rustonaut avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar

checked-command's Issues

Various enchancements.

  • support spawn mechanics (returning a Child<Output, Error> wrapping the std Child + mapping function)
    • might need some special handling for output mapping
  • allow piping stdout/stderr to /dev/null if not captured
  • allow defining the expected exit status (and if it's checked) default based on the OutputMapping.
  • provide unix extension trait methods
  • provide windows extension trait methods, maybe.

Include Output in Error's Display impl

The current Display implementation of Error includes the ExitStatus.
But it might be usefull to also include the output of stderr if aviable.
It's probably not a good idea to also include stdout.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.