Convert Figma logo to code with AI

dalance logoprocs

A modern replacement for ps written in Rust

5,018
109
5,018
17

Top Related Projects

4,595

A dead simple, no frills Go cross compile tool

6,293

htop - an interactive process viewer

19,111

A monitor of resources

26,263

Glances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, Mac OS and Windows operating systems.

2,155

A TUI system monitor written in Rust

9,759

Yet another cross-platform graphical process/system monitor.

Quick Overview

Procs is a modern replacement for the traditional ps command-line utility. It provides a more user-friendly and feature-rich way to display and manage system processes on Unix-like operating systems. Written in Rust, procs offers enhanced performance and a colorful, customizable output.

Pros

  • Colorful and customizable output for better readability
  • Cross-platform support (Linux, macOS, Windows)
  • Faster performance compared to traditional ps command
  • Advanced sorting and filtering options

Cons

  • May require installation on systems where ps is already available
  • Learning curve for users accustomed to traditional ps syntax
  • Might not have all the advanced features of ps for complex system administration tasks

Getting Started

To install procs, you can use one of the following methods:

  1. Using Cargo (Rust package manager):

    cargo install procs
    
  2. On macOS using Homebrew:

    brew install procs
    
  3. On Arch Linux using pacman:

    pacman -S procs
    

Once installed, you can start using procs by simply running the procs command in your terminal. For example:

procs

This will display a list of running processes with default columns. You can customize the output using various options and flags. For instance, to sort processes by CPU usage:

procs --sortd cpu

To filter processes by name:

procs firefox

For more advanced usage and customization options, refer to the project's documentation on GitHub.

Competitor Comparisons

4,595

A dead simple, no frills Go cross compile tool

Pros of gox

  • Cross-compilation support for multiple platforms and architectures
  • Simple and straightforward command-line interface
  • Lightweight and focused on a single task (cross-compilation)

Cons of gox

  • Less actively maintained (last commit in 2019)
  • Limited features compared to more comprehensive process management tools
  • No process monitoring or detailed system information display

Code comparison

gox:

func main() {
    // ...
    var buildToolchain []string
    var ldflags string
    var outputTpl string
    // ...
}

procs:

fn main() -> Result<()> {
    let mut opt = Opt::from_args();
    let config = Config::read(&opt)?;
    let mut term = Term::new(&config)?;
    // ...
}

Summary

gox is a simple cross-compilation tool for Go projects, while procs is a modern replacement for the ps command with advanced process monitoring features. gox excels in its focused approach to cross-compilation, making it easy to build Go binaries for multiple platforms. However, it lacks the comprehensive process management and system monitoring capabilities of procs.

procs offers a more feature-rich experience for process monitoring and system information display, with active development and regular updates. It provides a modern alternative to traditional process viewing tools, but doesn't focus on cross-compilation like gox does.

The choice between these tools depends on the specific needs of the user: cross-compilation for Go projects (gox) or advanced process monitoring and system information display (procs).

6,293

htop - an interactive process viewer

Pros of htop

  • More mature and widely adopted project with a larger user base
  • Offers a more traditional, ncurses-based interface familiar to many users
  • Provides detailed per-process information and interactive process management

Cons of htop

  • Written in C, which may be less approachable for some contributors
  • Limited to Unix-like systems, not cross-platform
  • Slower development cycle compared to procs

Code Comparison

htop (C):

void Process_toggleTag(Process* this) {
    this->tag = !this->tag;
    this->updated = true;
}

procs (Rust):

pub fn toggle_tag(&mut self) {
    self.tag = !self.tag;
    self.updated = true;
}

Both projects aim to provide system process monitoring and management capabilities. htop offers a more traditional, feature-rich interface with interactive process management, while procs focuses on performance and cross-platform support. htop is written in C and has a longer history, whereas procs is implemented in Rust, potentially offering better memory safety and easier contribution for Rust developers. The code comparison shows similar functionality implemented in their respective languages, with procs benefiting from Rust's more modern syntax and safety features.

19,111

A monitor of resources

Pros of btop

  • More comprehensive system monitoring, including CPU, memory, disks, and network
  • Highly customizable interface with themes and layout options
  • Interactive UI with mouse support for easier navigation

Cons of btop

  • Higher resource usage due to more extensive monitoring features
  • Steeper learning curve for configuration and customization
  • Less focused on process management compared to procs

Code Comparison

btop (C++):

void get_cpu_sensors(void) {
    static vector<fs::path> temp_sensors;
    if (temp_sensors.empty()) get_sensors(temp_sensors, "temp");
    for (const auto& sensor : temp_sensors) {
        // ... (sensor reading logic)
    }
}

procs (Rust):

pub fn collect_proc(interval: Duration) -> Vec<Proc> {
    let mut procs = Vec::new();
    for prc in procfs::process::all_processes().unwrap() {
        // ... (process collection logic)
    }
    procs
}

Both projects aim to provide system monitoring capabilities, but they differ in scope and implementation. btop offers a more comprehensive and visually appealing system monitor with extensive customization options, while procs focuses primarily on process management with a simpler interface. The code snippets demonstrate the different languages used (C++ for btop, Rust for procs) and their approaches to data collection.

26,263

Glances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, Mac OS and Windows operating systems.

Pros of Glances

  • More comprehensive system monitoring, including network, disk, and sensors
  • Web-based interface for remote monitoring
  • Supports multiple operating systems (Linux, macOS, Windows)

Cons of Glances

  • Higher resource usage due to more extensive monitoring
  • Steeper learning curve with more complex configuration options
  • Written in Python, which may be slower than Rust-based Procs

Code Comparison

Glances (Python):

from glances.outputs.glances_curses import GlancesCursesClient

class GlancesStandalone(GlancesCursesClient):
    def __init__(self, config=None, args=None):
        super(GlancesStandalone, self).__init__(config=config, args=args)

Procs (Rust):

pub fn new() -> Config {
    Config {
        color_mode: ColorMode::Auto,
        pager: true,
        interval: Duration::from_millis(1000),
        watch: false,
    }
}

The code snippets show the initialization of the main application classes for both projects. Glances uses a class-based approach in Python, while Procs employs a struct-based configuration in Rust, reflecting the different programming paradigms of the two languages.

2,155

A TUI system monitor written in Rust

Pros of ytop

  • More visually appealing interface with colorful graphs and charts
  • Provides a comprehensive system overview including CPU, memory, disk, and network usage
  • Offers customizable layouts and color schemes

Cons of ytop

  • Less frequently updated compared to procs
  • Fewer command-line options and filtering capabilities
  • Limited to displaying system-wide information rather than detailed per-process data

Code Comparison

ytop (Rust):

pub fn draw<B: Backend>(f: &mut Frame<B>, app: &App) {
    let chunks = Layout::default()
        .direction(Direction::Vertical)
        .constraints([Constraint::Percentage(50), Constraint::Percentage(50)].as_ref())
        .split(f.size());
    draw_cpu(f, app, chunks[0]);
    draw_mem(f, app, chunks[1]);
}

procs (Rust):

pub fn new() -> Finder {
    Finder {
        regex: None,
        keywords: Vec::new(),
        negate: false,
        case_sensitive: false,
    }
}

Both projects are written in Rust and focus on system monitoring, but they serve different purposes. ytop provides a more visual, high-level system overview, while procs offers detailed process information with powerful filtering capabilities. ytop is better suited for users who prefer graphical representations, while procs is ideal for those who need in-depth process data and advanced filtering options.

9,759

Yet another cross-platform graphical process/system monitor.

Pros of bottom

  • More visually appealing and customizable interface with charts and graphs
  • Supports cross-platform remote monitoring via SSH
  • Offers a more comprehensive set of system metrics, including network and disk I/O

Cons of bottom

  • Higher resource usage due to its graphical nature
  • Steeper learning curve for users accustomed to simpler process viewers
  • Less frequent updates and potentially slower development cycle

Code Comparison

bottom (Rust):

let mut app = App::default();
app.run().expect("Failed to run bottom");

procs (Rust):

let mut config = Config::new();
config.insert_kind(ProcessKind::All);
let processes = collect_processes(&config)?;

Both projects are written in Rust and aim to provide system monitoring capabilities. bottom focuses on a more feature-rich, graphical approach, while procs emphasizes simplicity and efficiency in a command-line interface. bottom offers a wider range of system metrics and visual representations, making it suitable for users who prefer a comprehensive dashboard. procs, on the other hand, excels in providing quick, lightweight process information with lower resource overhead.

The choice between the two depends on the user's specific needs, with bottom being more suitable for detailed system monitoring and procs for quick process checks and resource-constrained environments.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

procs

procs is a replacement for ps written in Rust.

Actions Status codecov

Changelog Crates.io procs homebrew

Documentation quick links

Features

  • Colored and human-readable output
    • Automatic theme detection based on terminal background
  • Multi-column keyword search
  • Some additional information which are not supported by ps
    • TCP/UDP port
    • Read/Write throughput
    • Docker container name
    • More memory information
  • Pager support
  • Watch mode (like top)
  • Tree view

Platform

  • Linux is supported.
  • macOS is experimentally supported.
    • macOS version is checked on GitHub Actions environment only.
    • The issues caused by real-machine are welcome.
  • Windows is supported.
  • FreeBSD is experimentally supported.

Installation

Download binary

Download from release page, and extract to the directory in PATH.

Packaging status

Nixpkgs

You can install from Nixpkgs.

nix-env --install procs

snapcraft

You can install from snapcraft.

sudo snap install procs

homebrew

You can install from homebrew.

brew install procs

MacPorts

You can install from MacPorts.

sudo port install procs

Alpine Linux

You can install from the Alpine Linux repository.

The correct repository (see above link for the most up-to-date information) should be enabled before apk add.

sudo apk add procs

Arch Linux

You can install from the Arch Linux extra repository.

sudo pacman -S procs

Scoop

You can install with scoop.

scoop install procs

Fedora

sudo dnf install procs

Windows

winget install procs

RPM

You can install with rpm.

sudo rpm -i https://github.com/dalance/procs/releases/download/v0.14.6/procs-0.14.6-1.x86_64.rpm

Cargo

You can install with cargo.

cargo install procs

Installation Notes

Permissions issues

On macOS, normal users can't access any information on other users' processes. On Linux, normal users can't access some information (ex. Read/Write throughput) of other users.

If you want to show this information, you should use sudo.

$ sudo procs
[sudo] password for ...:

If you want to skip password input, you can add the following entry to /etc/sudoers.

[user or group] ALL= NOPASSWD: [procs binary path]
// ex. myuser ALL= NOPASSWD: /usr/local/bin/procs

Usage

In the following screenshots, config/large.toml is used as the configuration.

Show all processes

Type procs only. It shows the information of all processes.

procs

procs

Search by non-numeric keyword

If you add any keyword as argument, it is matched to USER, Command by default.

procs zsh

If you want to add columns matching to non-numeric keyword, nonnumeric_search option can be used in configuration file.

procs_zsh

Search by numeric keyword

If a numeric is used as the keyword, it is matched to PID by default. Numeric is treated as exact match, and non-numeric is treated as partial match by default.

procs --or 6000 60000 60001 16723

If you want to add columns matching to numeric keyword, numeric_search option can be used in configuration file.

procs_port

Note that procfs permissions only allow identifying listening ports for processes owned by the current user, so not all ports will show up unless run as root.

Logical operation of search keywords

If there are some keywords, logical operation between the keywords can be specified by commandline option.

  • --and : The processes that match with all keywords are shown.
  • --or : The processes that match with any keyword are shown.
  • --nand: The processes are shown unless these match with all keywords.
  • --nor : The processes are shown unless these match with any keyword.

The default operation can be specified in the configuration file. See [search] section.

Show Docker container name

If you have access permission to docker daemon ( unix:///var/run/docker.sock ), Docker column is added.

procs growi

procs_docker

Note that procs gets the container information through UNIX domain socket, so Docker Toolbox on macOS (doesn't use UNIX domain socket) is not supported. Docker Desktop for Mac is supported but not tested.

Pager

If output lines exceed terminal height, pager is used automatically. This behavior and pager command can be specified by configuration file.

Linux / macOS

On Linux and macOS, less is the default pager. If there is not less, more is used. Instead of them, built-in pager can be used by configuration use_builtin.

Windows

On Windows, built-in pager is always used.

Watch mode

If --watch or --watch-interval <second> option is used, procs automatically updates output like top. If --watch is used, the update interval becomes 1s. The update interval can be specified by the argument of --watch-interval. There are some keyboard shortcuts to control.

  • n: Change the sort column to the next column
  • p: Change the sort column to the previous column
  • a: Change the sort order to ascending
  • d: Change the sort order to descending
  • q: Quit

Tree view

If --tree option is used, processes are sorted by dependency order and dependency tree is shown at left side.

procs --tree

procs_tree

If TreeSlot column exists in config, dependency tree is shown at the slot.

Sort column

Column sort order can be changed by --sorta or --sortd option. The last character of --sorta and --sortd means sort order: "a"scending and "d"escending.

The column for sort is selected by the option keyword. The keyword is matched with column kind that is shown by --list option. If --sorta cputime, column is sorted by CpuTime with ascending order. If --sortd rss, column is sorted by VmRss with descending order. The keyword is matched partially and case is ignored.

The default sort is specified by [sort] section in the configuration file.

procs --sortd cpu

procs_sort

Insert column

--insert option inserts new column to the position of Slot column or MultiSlot column. The column for insert is selected by the option keyword. The keyword is the same as sort option. A Slot column can be used by an inserted column. If many insertions are required, many Slot columns should be added. A MultiSlot column can be used by many inserted columns. If there is a MultiSlot, all the remaining columns are inserted to the MultiSlot, and the subsequent Slot / MultiSlot is not used. Unused Slot / MultiSlot is not shown.

Shell completion

--gen-completion option generates shell completion files under the current directory. The following shells are supported.

  • zsh
  • bash
  • fish
  • powershell
  • elvish

--gen-completion-out option generates shell completion to stdout. You can source it directly on some shells.

source <(procs --gen-completion-out bash)

Configuration

Configuration path

You can change configuration by writing a configuration file. There are some configuration examples in config directory of this repository. config/large.toml is the default configuration before procs v0.9.21.

The locations of the configuration file is OS-specific:

  • Linux: ~/.config/procs/config.toml, /etc/procs/procs.toml
  • macOS: ~/Library/Preferences/com.github.dalance.procs/config.toml, /etc/procs/procs.toml
  • Windows: ~/AppData/Roaming/dalance/procs/config/config.toml

For compatibility, if ~/.procs.toml exists, it will be preferred to the OS-specific locations.

Specify a configuration from command line

--use-config option can specify a built-in configuration. --load-config option can specify a configuration file path.

Configuration example

The complete example of a configuration file can be generated by --gen-config option.

[[columns]]
kind = "Pid"
style = "BrightYellow|Yellow"
numeric_search = true
nonnumeric_search = false

[[columns]]
kind = "Username"
style = "BrightGreen|Green"
numeric_search = false
nonnumeric_search = true
align = "Right"

[style]
header = "BrightWhite|Black"
unit = "BrightWhite|Black"
tree = "BrightWhite|Black"

[style.by_percentage]
color_000 = "BrightBlue|Blue"
color_025 = "BrightGreen|Green"
color_050 = "BrightYellow|Yellow"
color_075 = "BrightRed|Red"
color_100 = "BrightRed|Red"

[style.by_state]
color_d = "BrightRed|Red"
color_r = "BrightGreen|Green"
color_s = "BrightBlue|Blue"
color_t = "BrightCyan|Cyan"
color_z = "BrightMagenta|Magenta"
color_x = "BrightMagenta|Magenta"
color_k = "BrightYellow|Yellow"
color_w = "BrightYellow|Yellow"
color_p = "BrightYellow|Yellow"

[style.by_unit]
color_k = "BrightBlue|Blue"
color_m = "BrightGreen|Green"
color_g = "BrightYellow|Yellow"
color_t = "BrightRed|Red"
color_p = "BrightRed|Red"
color_x = "BrightBlue|Blue"

[search]
numeric_search = "Exact"
nonnumeric_search = "Partial"
logic = "And"

[display]
show_self = false
show_thread = false
show_thread_in_tree = true
cut_to_terminal = true
cut_to_pager = false
cut_to_pipe = false
color_mode = "Auto"

[sort]
column = 0
order = "Ascending"

[docker]
path = "unix:///var/run/docker.sock"

[pager]
mode = "Auto"

[[columns]] section

[[columns]] section defines which columns are used. The first [[columns]] is shown at left side, and the last is shown at right side.

KeyValueDefaultDescription
kindSee kind listColumn type
styleSee style listColumn style
numeric_searchtrue, falsefalseWhether the column can be matched with numeric keywords
nonnumeric_searchtrue, falsefalseWhether the column can be matched with non-numeric keywords
alignLeft, Right, CenterLeftText alignment
max_width[Number]Maximum column width
min_width[Number]Minimum column width
header[String]Alternate header description

kind list

procs kindps STANDARD FORMATDescriptionLinuxmacOSWindowsFreeBSD
Ccgroup-not supported-Control group by compressed formato
CgroupcgroupControl groupo
CommandargsCommand with all argumentsoooo
ContextSw-not supported-Context switch countooo
CpuTimecputimeCumulative CPU timeoooo
Docker-not supported-Docker container nameoo
EipeipInstruction pointero
ElapsedTime-not supported-Elapsed timeoooo
Enve output modifierEnvironment variablesoo
EspespStack pointero
FileNamecommFile nameoo
GidegidGroup IDoooo
GidFsfgidFile system group IDo
GidRealrgidReal group IDooo
GidSavedsgidSaved group IDooo
GroupegroupGroup nameoooo
GroupFsfgroupFile system group nameo
GroupRealrgroupReal group nameooo
GroupSavedsgroupSaved group nameooo
MajFltmaj_fltMajor page fault countoooo
MinFltmin_fltMinor page fault countooo
MultiSlot-not supported-Slot for --insert optionoooo
NiceniNice valueooo
PgidpgidProcess group IDooo
PidpidProcess ID ( or Thread ID sorrunded by [] )oooo
PolicypolicyScheduling policyoo
PpidppidParent process IDoooo
PrioritypriPriorityoooo
ProcessorpsrCurrently assigned processoroo
ReadBytes-not supported-Read bytes from storageoooo
RtPriorityrtprioReal-time priorityo
SecContextlabelSecurity contexto
Separator-not supported-Show | for column separationoooo
SessionsidSession IDooo
ShdPndpendingPending signal mask for processoo
SigBlkblockedBlocked signal maskoo
SigCgtcaughtCaught signal maskoo
SigIgnignoredIgnored signal maskoo
SigPndpendingPending signal mask for threado
Slot-not supported-Slot for --insert optionoooo
Ssb-not supported-Speculative store bypass statuso
StartTimestart_timeStarting timeoooo
StatesProcess stateooo
TcpPort-not supported-Bound TCP portsoo
ThreadsnlwpThread countooo
TreeSlot-not supported-Slot for tree columnoooo
TtyttyControlling TTYooo
UdpPort-not supported-Bound UDP portsoo
UideuidUser IDoooo
UidFsfuidFile system user IDo
UidLogin-not supported-Login user IDo
UidRealruidReal user IDooo
UidSavedsuidSaved user IDooo
UsageCpu%cpuCPU utilizationoooo
UsageMem%memMemory utilizationoooo
UsereuserUser nameoooo
UserFsfuserFile system user nameo
UserLogin-not supported-Login user nameo
UserRealruserReal user nameooo
UserSavedsuserSaved user nameooo
VmData-not supported-Data sizeoo
VmExetrsText segments sizeoo
VmHwm-not supported-Peak resident set sizeooo
VmLib-not supported-Library code sizeo
VmLock-not supported-Locked memory sizeo
VmPeak-not supported-Peak virtual memory sizeoo
VmPin-not supported-Pinned memory sizeoo
VmPte-not supported-Page table entries sizeo
VmRssrssResident set sizeoooo
VmSizevszPhysical page sizeoooo
VmStack-not supported-Stack sizeoo
VmSwap-not supported-Swapped-out virtual memory sizeoo
WchanwchanProcess sleeping kernel functionoo
WorkDir-not supported-Current working directoryo
WriteByte-not supported-Write bytes to storageoooo

style list

  • BrightBlack
  • BrightRed
  • BrightGreen
  • BrightYellow
  • BrightBlue
  • BrightMagenta
  • BrightCyan
  • BrightWhite
  • Black
  • Red
  • Green
  • Yellow
  • Blue
  • Magenta
  • Cyan
  • White
  • Color256
  • ByPercentage
  • ByState
  • ByUnit

There are some special styles like ByPercentage, ByState, ByUnit. These are the styles for value-aware coloring. For example, if ByUnit is chosen, color can be specified for each unit of value ( like K, M, G,,, ). The colors can be configured in [style.by_unit] section.

Other colors can be configured as the same as color.

[style] section

[style] section defines colors of header, unit and each styles. The available list of color is below.

SubsectionKeyValueDefaultDescription
headerSee color listBrightWhite|BlackHeader color
unitSee color listBrightWhite|BlackUnit color
treeSee color listBrightWhite|BlackTree color
by_percentagecolor_000See color listBrightBlue|BlueColor at 0% - 25%
by_percentagecolor_025See color listBrightGreen|GreenColor at 25% - 50%
by_percentagecolor_050See color listBrightYellow|YellowColor at 50% - 75%
by_percentagecolor_075See color listBrightRed|RedColor at 75% - 100%
by_percentagecolor_100See color listBrightRed|RedColor at 100% -
by_statecolor_dSee color listBrightRed|RedColor at D state
by_statecolor_rSee color listBrightGreen|GreenColor at R state
by_statecolor_sSee color listBrightBlue|BlueColor at S state
by_statecolor_tSee color listBrightCyan|CyanColor at T state
by_statecolor_zSee color listBrightMagenta|MagentaColor at Z state
by_statecolor_xSee color listBrightMagenta|MagentaColor at X state
by_statecolor_kSee color listBrightYellow|YellowColor at K state
by_statecolor_wSee color listBrightYellow|YellowColor at W state
by_statecolor_pSee color listBrightYellow|YellowColor at P state
by_unitcolor_kSee color listBrightBlue|BlueColor at unit K
by_unitcolor_mSee color listBrightGreen|GreenColor at unit M
by_unitcolor_gSee color listBrightYellow|YellowColor at unit G
by_unitcolor_tSee color listBrightRed|RedColor at unit T
by_unitcolor_pSee color listBrightRed|RedColor at unit P
by_unitcolor_xSee color listBrightBlue|BlueColor at other unit

color list

  • BrightBlack
  • BrightRed
  • BrightGreen
  • BrightYellow
  • BrightBlue
  • BrightMagenta
  • BrightCyan
  • BrightWhite
  • Black
  • Red
  • Green
  • Yellow
  • Blue
  • Magenta
  • Cyan
  • White
  • Color256

Colors can be configured by theme through |.

style = "BrightWhite|Black" # BrightWhite for dark theme and Black for light theme
style = "BrightWhite"       # BrightWhite for both theme

The first color is for dark theme, and the second is for light theme. If only a color is specified, the color is applied to both theme.

Color256 can be specified by 0-255 value like below:

style = "223|112" # 223 for dark theme and 112 for light theme
style = "223"     # 223 for both theme

[search] section

[search] section defines option for Keyword search.

KeyValueDefaultDescription
numeric_searchExact, PartialExactWhether numeric keywords match exactly or partially
nonnumeric_searchExact, PartialPartialWhether non-numeric keywords match exactly or partially
logicAnd, Or, Nand, NorAndLogical operation between keywords
caseSmart, Insensitive, SensitiveSmartCase sensitivity in search

case

case is case sensitivity in search.

  • Smart: If keyword contains uppercase character, case sensitive search. Otherwise case insensitive search
  • Insensitive: case insensitive search
  • Sensitive: case sensitive search

[display] section

[display] section defines option for output display.

KeyValueDefaultDescription
show_selftrue, falsefalseWhether the self process ( procs ) is shown
show_self_parentstrue, falsefalseWhether the parents which have self as the only child process are shown
show_threadtrue, falsefalseWhether the thread information is shown ( Linux only )
show_thread_in_treetrue, falsetrueWhether the thread information is shown in tree mode ( Linux only )
show_parent_in_treetrue, falsetrueWhether the parent process is shown in tree mode
show_children_in_treetrue, falsetrueWhether the children processes are shown in tree mode
show_headertrue, falsetrueWhether header row is shown
show_footertrue, falsefalseWhether footer row is shown
show_kthreadstrue, falsetrueWhether processes which belong to kthread are shown ( Linux only )
cut_to_terminaltrue, falsetrueWhether output lines are truncated for output into terminal
cut_to_pagertrue, falsefalseWhether output lines are truncated for output into pager
cut_to_pipetrue, falsefalseWhether output lines are truncated for output into pipe
color_modeAuto, Always, DisableAutoThe default behavior of output coloring without --color commandline option
separator[String]│String used as Separator
ascending[String]▲Ascending sort indicator
descending[String]▼Descending sort indicator
tree_symbols[String; 5][│, ─, ┬, ├, └]Symbols used by tree view
abbr_sidtrue, falsetrueWhether machine SID is abbreviated ( Windows only )
themeAuto, Dark, LightAutoDefault theme

If color_mode is Auto, color is enabled for terminal and pager, disabled for pipe.

If theme is Auto, theme is detected from terminal automatically. Some terminal don't support the automatic detection, so Dark or Light can be specified explicitly.

abbr_sid

Windows SID is too long, so it is abbreviated by default. If abbr_sid is false, SID is fully shown like below:

S-1-5-21-789457439-2186958450-1652286173-1001

If abbr_sid is true, SID is shown like below:

S-1-5-21-...-1001

[sort] section

[sort] section defines the column used for sort and sort order.

KeyValueDefaultDescription
column[Number]0Column number to used for sort
orderAscending, DescendingAscendingSort order

If column is 0, value is sorted by the left column.

[docker] section

[docker] section defines how to communicate to docker daemon.

KeyValueDefaultDescription
path[Path]unix:///var/run/docker.sockUNIX domain socket to docker daemon

[pager] section

[pager] section defines the behavior of pager.

KeyValueDefaultDescription
modeAuto, Always, DisableAutoThe default behavior of pager usage without --pager commandline option
detect_widthtrue, falsefalseWhether auto mode detects terminal width overflow
use_builtintrue, falsefalseWhether built-in pager is used
command[Command]less -SRPager command

If mode is Auto, pager is used only when output lines exceed terminal height. Default pager is less -SR ( if less is not found, more -f ).