workflow-manager

Workflow manager for batch command execution with conditional logic

Version: 9.0.1 | Size: 3.0MB | Author: Warith Al Maawali

License: Proprietary | Website: https://www.digi77.com

---

File Information

Property	Value
Binary Name	workflow-manager
Version	9.0.1
Build Date	2025-11-09T07:20:09.678807717Z
Rust Version	1.82.0
File Size	3.0MB
JSON Data	View Raw JSON

SHA256 Checksum

c7828d53640d076c11a34dd302c6122ea7131cd26211912e76efe6c43a49cdae

---

Features

Feature	Description
Feature	Template-based workflow management
Feature	Conditional command execution
Feature	Batch processing with retry logic
Feature	State tracking and logging
Feature	Concurrent execution support
Feature	Pause steps with user confirmation
Feature	Pattern matching and regex conditions
Feature	JSON path expression support
Feature	Prerequisites validation before execution
Feature	System state checking and probes
Feature	Reusable probe functions for conditions

Security Features

Feature	Description
Authentication	Secure authentication with certificate pinning
Encryption	TLS 1.3 for all network communications
Inputvalidation	All inputs are validated and sanitized
Ratelimiting	Built-in rate limiting for network operations

System Requirements

Requirement	Value
OS	Linux (Debian-based)
Privileges	root/sudo for system operations
Dependencies	OpenSSL, libcurl

Global Options

Flag	Description
-h, --help	Print help information
-v, --version	Print version information
-n, --info	Display detailed information
-e, --examples	Show usage examples
--json	Output in JSON format
--json-pretty	Pretty-print JSON output with indentation
--json-human	Enhanced JSON output with improved formatting (like jq)
--verbose	Enable verbose output
--quiet	Suppress non-essential output
--no-color	Disable colored output
--config <FILE>	Use custom configuration file
--timeout <SECS>	Set timeout (default: 30)
--retry <COUNT>	Retry attempts (default: 3)

Commands

Commands

create

Create a new workflow template

Usage:

workflow-manager create [OPTIONS]

add

Add a step to a workflow template

Usage:

workflow-manager add [OPTIONS]

pause

Add a pause step to a workflow template

Usage:

workflow-manager pause [OPTIONS]

list

List all workflow templates

Usage:

workflow-manager list [OPTIONS]

show

Show details of a workflow template

Usage:

workflow-manager show [OPTIONS]

run

Run a workflow template

Usage:

workflow-manager run [OPTIONS]

update

Update a step in a workflow template

Usage:

workflow-manager update [OPTIONS]

delete-step

Delete a step from a workflow template

Usage:

workflow-manager delete-step [OPTIONS]

delete

Delete an entire workflow template

Usage:

workflow-manager delete [OPTIONS]

state

Query system state

Usage:

workflow-manager state [OPTIONS]

prereq

Validate workflow prerequisites

Usage:

workflow-manager prereq [OPTIONS]

Examples

Template Management

Create, list, view, and delete workflow templates

Creates a new empty workflow template named 'my-workflow'

workflow-manager create my-workflow

Expected Output: Template 'my-workflow' created successfully

Creates a workflow with a descriptive label

workflow-manager create backup-workflow --description 'Daily backup routine'

Expected Output: Template 'backup-workflow' created successfully

Shows all available workflow templates

workflow-manager list

Expected Output: Workflow Templates (2 total)

Displays the full structure of a workflow template

workflow-manager show my-workflow

Expected Output: Workflow Template: my-workflow

Permanently removes a workflow template

workflow-manager delete my-workflow

Expected Output: Template 'my-workflow' deleted successfully

Adding Commands to Workflows

Add steps to workflows. Use comma-separated commands for multiple steps in one call, or add individually.

Adds a single command as step 1

workflow-manager add my-workflow 'echo Hello World'

Expected Output: Step 1 added to template 'my-workflow'

Note

Single command creates one step

Add multiple steps in one command using comma separation

workflow-manager add w1 "sudo ip-fetch","sudo online-auth check-login","ip addr show"

Expected Output: 3 steps added to template 'w1'

Note

Comma-separated commands create multiple steps automatically

Create a diagnostic workflow with 3 steps at once

workflow-manager add diagnostics "./health-control net-check","./tor-switch status","./dns-leak test"

Expected Output: 3 steps added to template 'diagnostics'

Note

All steps share the same timeout and condition settings

Adds a command with a 10-minute timeout

workflow-manager add my-workflow 'tar czf backup.tar.gz /data' --timeout 600

Expected Output: Step added with 600 second timeout

Runs only if the previous command succeeded

workflow-manager add my-workflow 'cleanup.sh' --condition if_success

Expected Output: Step added with conditional execution

Runs only if previous output contains 'ERROR'

workflow-manager add my-workflow 'notify-admin.sh' --if-contains 'ERROR'

Expected Output: Step added with pattern matching condition

Workflow Execution

Run workflows and control execution behavior

Executes all commands in the workflow sequentially

sudo workflow-manager run my-workflow

Expected Output: ✅ Workflow completed: Success

Note

Conditions are evaluated before each step

Shows what would be executed without running commands

sudo workflow-manager run my-workflow --dry-run

Expected Output: Dry run: 5 steps would be executed

Note

Use for testing workflows before execution

Managing Individual Steps

Update, delete, and inspect individual workflow steps

View all steps with their IDs and details

workflow-manager show my-workflow

Expected Output: Step 1: echo Hello Step 2: ./backup.sh Step 3: ./cleanup.sh

Note

Use this to identify step IDs before updating or deleting

Remove step #2 from the workflow

workflow-manager delete-step my-workflow 2

Expected Output: Step 2 deleted from 'my-workflow'

Note

Step IDs are renumbered after deletion

Change step #1 command and timeout

workflow-manager update my-workflow 1 'echo Updated Command' --timeout 300

Expected Output: Step 1 updated successfully

Note

All step properties can be updated

Efficient Batch Building

Build complete workflows quickly by chaining multiple 'add' commands with &&

Create workflow and add 3 steps in one command chain

workflow-manager create tor-recovery && workflow-manager add tor-recovery './routing-switch recover internet' --timeout 60 && workflow-manager add tor-recovery './health-control net-check' -c if_success && workflow-manager add tor-recovery './tor-switch start' -c if_success --timeout 120

Expected Output: Template created, 3 steps added successfully

Note

Use && to chain commands efficiently

Add 4 diagnostic steps with conditional execution

workflow-manager add diagnostics './health-control net-check' --timeout 30 && workflow-manager add diagnostics './tor-switch status' -c if_success && workflow-manager add diagnostics './dns-leak test' -c if_success && workflow-manager add diagnostics './integrity-check verify' -c if_success

Expected Output: 4 steps added to diagnostics workflow

Build complete backup workflow with pause and cleanup

workflow-manager add backup 'tar czf backup.tar.gz /data' && workflow-manager pause backup --message 'Check backup size' -c if_success && workflow-manager add backup 'rsync backup.tar.gz remote:/backups' -c if_success && workflow-manager add backup 'rm backup.tar.gz' -c if_success

Expected Output: Backup workflow with 4 steps created

Note

Mix commands and pauses for interactive workflows

Conditional Logic

All available condition types with practical examples

Always execute (default behavior, runs regardless)

workflow-manager add my-workflow './check-status.sh' -c always

Expected Output: Step added with 'always' condition

Execute only if previous step succeeded (exit code 0)

workflow-manager add my-workflow './deploy.sh' -c if_success

Expected Output: Step added with if_success condition

Note

Most common condition for sequential workflows

Execute only if previous step failed (exit code ≠ 0)

workflow-manager add my-workflow './rollback.sh' -c if_fail

Expected Output: Step added with if_fail condition

Note

Useful for error recovery and rollback scenarios

Execute if previous output contains pattern "success"

workflow-manager add my-workflow './alert-success.sh' --if-contains "success"

Expected Output: Step added with pattern matching condition

Note

Case-sensitive - matches JSON like \"status\":\"success\"

Execute if previous output does NOT contain "errors"

workflow-manager add my-workflow './continue.sh' --if-not-contains "errors"

Expected Output: Step added with negative pattern condition

Note

Case-sensitive - checks for absence of \"errors\" in JSON output

Execute if previous output exactly equals "ready"

workflow-manager add my-workflow './handle-done.sh' --if-equals "ready"

Expected Output: Step added with exact match condition

Note

Exact match (case-sensitive) - output is trimmed before comparison

Execute if previous output matches regex pattern

workflow-manager add my-workflow './process-result.sh' --if-regex '^status: (ok|success)$'

Expected Output: Step added with regex condition

Note

Supports full regex syntax for complex matching

Execute if output does NOT match regex (counting: skip if 4+ HARDENED found)

workflow-manager add my-workflow './skip-if-hardened.sh' --if-not-regex 'HARDENED.*HARDENED.*HARDENED.*HARDENED'

Expected Output: Step added with if_not_regex condition

Note

Inverse regex match - useful for counting occurrences. Pattern matches 4+ 'HARDENED' words.

Execute if fewer than 5 services are active (counting with regex quantifiers)

workflow-manager add my-workflow './alert-few-services.sh' --if-not-regex '(service.*active.*){5,}'

Expected Output: Step added with if_not_regex condition

Note

Uses regex quantifiers {5,} to count occurrences. Step runs if pattern does NOT match (< 5 services).

Execute if JSON field $.status equals 'connected'

workflow-manager add my-workflow './handle-connected.sh' --if-json-path '$.status="connected"'

Expected Output: Step added with JSON path condition

Note

Previous output must be valid JSON

Execute if JSON array element matches value

workflow-manager add my-workflow './finland-detected.sh' --if-json-path '$.data.records[0].country_name="Finland"'

Expected Output: Step added with JSON path array condition

Note

Supports array indexing [0], [1], etc. for nested JSON arrays

Execute if nested JSON path with array matches

workflow-manager add my-workflow './proxy-active.sh' --if-json-path '$.data.records[0].connection_status.connection_type="Proxy"'

Expected Output: Step added with complex nested JSON path condition

Note

Can navigate through objects and arrays: $.path.to.array[index].field

Execute if JSON boolean field is true

workflow-manager add my-workflow './ip-online.sh' --if-json-path '$.ip_connectivity=true'

Expected Output: Step added with JSON boolean condition

Note

Supports true/false without quotes

Execute if JSON number field matches

workflow-manager add my-workflow './status-check.sh' --if-json-path '$.status_code=2'

Expected Output: Step added with JSON number condition

Note

Numbers don't need quotes: =2 not ="2"

Advanced Features

Pause steps and advanced workflow management

Adds an interactive pause point in the workflow

workflow-manager pause my-workflow --message 'Review results before continuing'

Expected Output: Pause step added to workflow

Note

User must press Enter to continue workflow execution

Conditional pause only if previous step succeeded

workflow-manager pause backup --message 'Verify backup integrity' -c if_success

Expected Output: Conditional pause step added

Note

Combine pauses with conditions for smart workflows

Real-World Kodachi Workflows

Practical workflows using actual Kodachi commands

Check IP geolocation and verify country

workflow-manager create ip-verify && workflow-manager add ip-verify 'sudo ip-fetch --json' --timeout 60 && workflow-manager add ip-verify 'echo Finland detected' --if-json-path '$.data.records[0].country_name="Finland"' && workflow-manager run ip-verify

Expected Output: Finland detected

Note

Uses JSON path with array indexing to check nested geolocation data

Verify authentication and session status

workflow-manager create auth-check && workflow-manager add auth-check 'sudo online-auth check-login --json' --timeout 30 && workflow-manager add auth-check 'echo Session valid' --if-contains 'valid' && workflow-manager run auth-check

Expected Output: Session valid

Note

Pattern matching on authentication response to confirm valid login

Complete system health and network connectivity check

workflow-manager create health-audit && workflow-manager add health-audit 'sudo health-control net-check --json' --timeout 60 && workflow-manager add health-audit 'echo Network online' --if-json-path '$.ip_connectivity=true' && workflow-manager add health-audit 'sudo routing-switch status --json' -c if_success --timeout 30 && workflow-manager run health-audit

Expected Output: Network online

Note

Combines network check with JSON boolean evaluation and cascading conditions

Verify Tor service health and responsiveness

workflow-manager create tor-verify && workflow-manager add tor-verify 'sudo tor-switch get-tor-status --json' --timeout 30 && workflow-manager add tor-verify 'echo Tor responding' --if-json-path '$.data.is_responding=true' && workflow-manager run tor-verify

Expected Output: Tor responding

Note

Checks Tor daemon status using JSON path boolean evaluation

Prerequisites

Define system state requirements that must be met before workflow execution

Prerequisites block in profile JSON - validates state before execution

# Example profile with prerequisites (edit JSON manually):
{
  "prerequisites": {
    "required": [
      {"check": "state.online", "expect": true, "error": "Internet connection required"},
      {"check": "state.torrify", "expect": false, "error": "System must not be torrified"},
      {"check": "state.tor_running", "expect": true, "error": "Tor must be running"}
    ],
    "on_failure": "abort"
  }
}

Expected Output: ✅ Prerequisites validated or ❌ Prerequisites not met - aborting

Note

If prerequisites is null or not present, no prerequisite checks are performed

Validate prerequisites without running the workflow

workflow-manager prereq check initial_terminal_setup_wireguard_torrify

Expected Output: ✅ All prerequisites met or ❌ Prerequisite failures listed

Note

Use this to test prerequisites before execution

System State Checking

Query current system state for debugging and validation

Show all system states as JSON

workflow-manager state

Expected Output: {"online": true, "torrify": false, "dnscrypt": true, "routing_mode": "wireguard", "tor_running": true}

Check specific state (online connectivity)

workflow-manager state online

Expected Output: {"state": "online", "value": true}

Note

20 states available: online, routing_mode, vpn_connected, dnscrypt, ipv6_disabled, dns_kodachi_managed, firewall_active, kill_switch_armed, network_hardened, disk_encrypted, security_score, torrify, tor_running, tor_dns_active, tor_verified, mac_spoofing, bluetooth_enabled, wifi_enabled, authenticated, tor_instances_count

Probe Functions

Define reusable probe functions in profiles for complex conditions

Define probes at profile level and use in step conditions

# Example profile with probes (edit JSON manually):
{
  "probes": {
    "harden_count": {
      "probe_type": "count",
      "expression": "count('harden', previous_output)",
      "description": "Count 'harden' occurrences"
    },
    "is_hardened": {
      "probe_type": "expression",
      "expression": "probe('harden_count') >= 4"
    }
  },
  "steps": [
    {
      "id": 2,
      "cmd": "echo 'Already hardened, skipping'",
      "condition": {
        "type": "if_probe",
        "probe": "is_hardened",
        "expect": true
      }
    }
  ]
}

Expected Output: Step executes based on probe evaluation

Note

Probe types: builtin, expression, count

Global Settings Reference

Complete reference for workflow-level configuration options and their interactions

All available global settings with default values

# Global Settings in profile JSON:
{
  "global_settings": {
    "kill_policy": "stop",
    "continue_policy": true,
    "max_log_size": 10485760,
    "default_timeout": 300,
    "working_dir": "."
  }
}

Expected Output: kill_policy: "stop" (how to handle step failures) continue_policy: true (whether to continue after failures) max_log_size: 10485760 bytes (max log file size) default_timeout: 300 seconds (default step timeout) working_dir: "." (base directory for commands)

Note

Global settings apply to entire workflow unless overridden at step level

kill_policy determines workflow behavior when steps fail

kill_policy options:
- "stop": Stop entire workflow on first failure (default, safest)
- "continue": Continue executing remaining steps even after failures
- "skip_remaining": Skip remaining steps but don't mark workflow as failed

Expected Output: Use 'stop' for critical workflows (security, setup) Use 'continue' for recovery workflows (best-effort attempts) Use 'skip_remaining' for conditional workflows (skip if condition met)

Note

continue_policy=true overrides kill_policy completely - always continues regardless of kill_policy value

Priority logic: continue_policy overrides kill_policy

# Interaction between kill_policy and continue_policy:
If continue_policy = true:
  → Always continue (kill_policy ignored)
If continue_policy = false:
  → Check kill_policy:
     - "stop" → stop workflow
     - "continue" → continue workflow
     - "skip_remaining" → skip remaining steps

Expected Output: continue_policy acts as master override switch kill_policy provides granular control when continue_policy=false

Note

For security-critical workflows: kill_policy='stop', continue_policy=false. For recovery workflows: kill_policy='continue', continue_policy=true

default_timeout applies to all steps, working_dir sets base path for relative commands

# Timeout and working directory:
{
  "global_settings": {
    "default_timeout": 180,
    "working_dir": "/home/kodachi/k900/dashboard/hooks"
  },
  "steps": [
    {
      "cmd": "./health-control net-check",
      "timeout": 60
    }
  ]
}

Expected Output: Steps without explicit timeout use default_timeout (180s) Commands execute from working_dir path Step-level timeout (60s) overrides default

Note

max_log_size prevents runaway log growth. Logs are truncated when limit reached. Default 10MB is suitable for most workflows

Prerequisites Explained

Complete guide to workflow prerequisites - requirements that must be met before workflow runs

Prerequisites define conditions that must be true before workflow executes

# Prerequisites in profile JSON:
{
  "prerequisites": {
    "authenticated": true,
    "online": true,
    "torrify": false,
    "on_failure": "abort"
  }
}

Expected Output: authenticated: User must be logged in with valid session online: Internet connectivity required torrify: Tor routing must be active (true) or inactive (false) on_failure: Action when prerequisites not met

Note

Prerequisites are checked BEFORE any steps execute. All must pass (AND logic)

on_failure controls behavior when prerequisites fail

on_failure options:
- "abort": Stop workflow execution immediately (default, safest)
- "skip": Skip workflow but don't fail (useful for optional workflows)
- "warn": Show warning but continue anyway (use with caution)

Expected Output: abort: Critical prerequisites (auth, security) skip: Optional workflows (diagnostics, reporting) warn: Non-critical checks (informational only)

Note

Example: auth workflows use on_failure='abort' because running unauthenticated operations is unsafe

Real-world prerequisite patterns for different workflow types

# Common prerequisite patterns:
# Security-critical workflow:
"prerequisites": {
  "authenticated": true,
  "on_failure": "abort"
}

# Tor setup workflow:
"prerequisites": {
  "online": true,
  "torrify": false,
  "on_failure": "abort"
}

# Recovery workflow (run anytime):
"prerequisites": {}  # Empty - no requirements

Expected Output: Security workflows: Require authentication Setup workflows: Require specific system state Recovery workflows: No prerequisites (always available)

Note

Combine prerequisites with AND logic - all must pass. For OR logic, create separate workflows

Backend implementation of prerequisite checks

# How prerequisites are checked:
authenticated: Check ~/.kodachi/auth/session file exists and valid
online: Ping check or DNS resolution test
torrify: Check routing-switch status for active Tor routing

Expected Output: Each prerequisite type has specific system check Failed checks trigger on_failure behavior Prerequisite status shown in workflow output

Note

Use 'workflow-manager prereq check ' to test prerequisites without running workflow

Condition Types Deep Dive

Comprehensive reference for all condition types and evaluation logic

Complete list of condition types with brief descriptions

# All supported condition types:
1. "always" - Always execute (unconditional)
2. "never" - Never execute (placeholder/disabled)
3. "if_success" - Execute if previous step succeeded (exit code 0)
4. "if_fail" - Execute if previous step failed (exit code != 0)
5. "if_pattern" - Execute if previous output matches pattern (glob)
6. "if_not_pattern" - Execute if previous output does NOT match pattern
7. "if_json_path" - Execute if JSON path query returns true
8. "if_expression" - Execute if complex boolean expression evaluates true
9. "if_probe" - Execute based on probe function result

Expected Output: Each condition type evaluates differently Conditions determine whether step executes or skips Multiple steps can have same condition type

Note

Conditions are evaluated sequentially - each step checks its condition before executing

Pattern matching uses glob syntax for flexible text matching

# Pattern matching (if_pattern, if_not_pattern):
{
  "condition": {
    "type": "if_pattern",
    "pattern": "*SUCCESS*"
  }
}

Pattern syntax (glob-style):
- "*" matches any characters (wildcard)
- "?" matches single character
- "[abc]" matches any char in brackets
- "[!abc]" matches any char NOT in brackets
- "**" recursive directory match

Case-sensitive by default!

Expected Output: Patterns match against previous step's output Wildcards allow partial matching Case matters: 'SUCCESS' != 'success'

Note

Use if_not_pattern for exclusion logic (e.g., skip if output contains ERROR)

if_json_path evaluates JSON output from previous command

# JSON path evaluation (if_json_path):
{
  "condition": {
    "type": "if_json_path",
    "path": "$.status.connected",
    "expect": true
  }
}

JSON path syntax:
- "$" root object
- ".field" object field access
- "[index]" array index access
- ".." recursive descent
- "*" wildcard (all elements)

Expected Output: Extracts value at path and compares to 'expect' Useful for structured command output (health-control, tor-switch) Path evaluation uses JSONPath standard

Note

Example: health-control --json returns JSON, use if_json_path to check specific fields like $.security.score

if_expression allows complex boolean logic combining multiple checks

# Expression conditions (if_expression):
{
  "condition": {
    "type": "if_expression",
    "expression": "probe('hardened_count') >= 4 && !contains('ERROR', previous_output)"
  }
}

Supported operators:
- Comparison: ==, !=, <, >, <=, >=
- Logical: &&, ||, !
- Functions: contains(), count(), probe()
- Variables: previous_output, step_id, workflow_status

Expected Output: Expressions evaluated at runtime Combine multiple conditions with logical operators Access probe functions and workflow state

Note

Most powerful condition type - use for complex decision logic. Example: skip step if already hardened AND no errors detected

if_probe evaluates reusable probe functions defined in profile

# Probe-based conditions (if_probe):
{
  "probes": {
    "is_connected": {
      "probe_type": "builtin",
      "check": "network_status"
    }
  },
  "steps": [
    {
      "condition": {
        "type": "if_probe",
        "probe": "is_connected",
        "expect": true
      }
    }
  ]
}

Expected Output: Define probe once, use in multiple steps Probe types: builtin (system checks), expression (custom logic), count (occurrence counting) Cleaner than repeating same condition

Note

See Category 11 'Probe Functions' for detailed probe documentation

Step Configuration Reference

Complete reference for all step-level configuration options

All available step configuration fields with example values

# Complete step structure:
{
  "id": 1,
  "type": "command",
  "cmd": "sudo health-control net-check",
  "description": "Check network connectivity",
  "condition": {
    "type": "always"
  },
  "timeout": 60,
  "confirm": false,
  "nice_level": 0
}

Expected Output: id: Unique step number (required, integer) type: Step type (required: 'command', 'pause', 'include') cmd: Command to execute (required for command type) description: Human-readable label (required) condition: Execution condition (required object) timeout: Max execution seconds (optional, uses default_timeout if omitted) confirm: Require user confirmation (optional, default false) nice_level: Process priority -20 to 19 (optional, default 0)

Note

Required fields: id, type, cmd (if command type), description, condition. All others optional with sensible defaults

Three step types with different requirements and behaviors

# Step types explained:
1. "command" - Execute shell command
   Requires: cmd field
   Example: "cmd": "sudo tor-switch status"

2. "pause" - Wait for user input or delay
   Requires: message field (shown to user)
   Example: "message": "Press Enter to continue..."

3. "include" - Include another workflow profile
   Requires: profile field
   Example: "profile": "base-recovery-sequence"

Expected Output: command: Most common type for executing system operations pause: Interactive workflows requiring user decisions include: Compose complex workflows from smaller reusable pieces

Note

Include type allows workflow composition - build libraries of reusable profiles and chain them together

Step-level timeout overrides global default_timeout

# Timeout behavior:
{
  "global_settings": {
    "default_timeout": 300
  },
  "steps": [
    {
      "cmd": "quick-command",
      "timeout": 10
    },
    {
      "cmd": "slow-command"
      # Uses default_timeout (300s)
    }
  ]
}

Expected Output: Omit timeout to use default (300s from global_settings) Specify timeout for time-sensitive commands Timeout prevents hanging on stuck commands

Note

Set timeout=0 for no limit (use carefully). Commands killed with SIGTERM after timeout, then SIGKILL if unresponsive

confirm adds safety for destructive operations, nice_level controls CPU priority

# Confirm and nice_level:
{
  "cmd": "sudo health-control panic hard",
  "confirm": true,
  "nice_level": -10
}

confirm: true prompts user before executing
nice_level: -20 (highest priority) to 19 (lowest priority)
  - Negative values require root (higher CPU priority)
  - Positive values lower priority (background tasks)
  - 0 is default (normal priority)

Expected Output: Use confirm=true for dangerous commands (panic, wipe, reset) Use negative nice_level for critical real-time operations Use positive nice_level for background tasks

Note

Example: Recovery workflows use nice_level=-5 for priority, diagnostic scripts use nice_level=10 for background execution

Environment Variables

Variable	Description	Default	Values
RUST_LOG	Set logging level	info	error
NO_COLOR	Disable all colored output when set	unset	1

Exit Codes

Code	Description
0	Success
1	General error
2	Invalid arguments
3	Permission denied
4	Network error
5	File not found

---