like ~~grep~~ UBER, but for binaries


bingrep Build Status

Greps through binaries from various OSs and architectures, and colors them. Current backends:

  • ELF 32/64, arm, x86, openrisc - all others will parse and color, but relocations won't show properly
  • Mach 32/64, arm, x86
  • Unix and BSD archive printer
  • PE (debug only)

NOTE: Building requires rustc version 1.20 or greater. If you're using a distro's rust compiler, consider using to install your rustc compiler and associated binaries.






bingrep is available through cargo, via cargo install bingrep, or you can build, and install the resulting binary wherever you like.


Tested with stable rustc 1.38.0.

cargo build --release

Now copy the resulting binary in <path_to_bingrep>/target/release/bingrep wherever you like.



bingrep /bin/ls

To dump internal debug representation of the parsed binary:

bingrep -d /bin/ls

To demangle symbols, use -D or --demangle:

bingrep -D /bin/ls

Meta Analysis (Experimental)

You can print a hextable (WIP) via --hex or an overview of file offset ranges via --ranges.



Search functionality is being added.

You can try it out using bingrep --search "string" or bingrep -s "string". Currently only works for ELF targets.

Please chime in on for how this functionality will:

  1. Be presented,
  2. What API will be exposed
  3. What usecases are most important (e.g., how do you like to search binaries)
  4. How it will be implemented


Why is this repo called bingrep, it's nothing like grep at all

That's a good question; I was using this as a personal development tool for some time, and I was conferring with someone from the internet about some binary stuff, when I decided I should just upload this to a proper repo instead of sending pictures. So I quickly created a repo, I felt like I had been greppin' through binaries, so that was the name I uploaded. Even worse, I named it bg as the produced executable at the time of the upload, and this of course immediately conflicted with the unix command bg. There's an issue for a better name, you can chime in too!

Why do you/should I use this instead of X ?

For some of my projects or workflows I need to very quickly see the load address, offset, or size of a symbol/program header/section header/export/import. I got tired of using objdump/nm/X because really, I just needed to colorize addresses, sizes etc., so I can quickly identify them and move on. So I wrote this, very quickly, and named it a bad name (sorry!). Then I went totally overboard and started coloring everything, everywhere. You love it, don't worry. Also you're free to use anything you want, whatever makes you happy and productive!

Is there anything to work on?

Yes, there are several open issues. I think I'd actually like to port the symbol map functionality (which enables printing every binary that exports a symbol) from, as well as implement a "reverse symbol map", which finds every binary that calls/imports a symbol.

If you also like hacking on binary stuff, the backend this uses,, is responsible for the actual loading, parsing, etc., and there are several open issues on that repo as well if you feel like contributing.

  • pager issue

    pager issue

    When using pager like less or more, bingrep works. However sometimes when it quits, it will panic. Here is a result when using bingrep with rustc with pager more.


    1. This seems to happen for some binaries, e.g., there is no such a panic for /bin/ls on my machine.
    2. Other pager, e.g., view (from nvim) works fine when used like bingrep /path/to/target | view - however will hang forever when using wrongly, e.g., bingrep /path/to/target | view.
    ~ > RUST_BACKTRACE=1 bingrep ~/.cargo/bin/rustc  | more
    thread 'main' panicked at 'Cannot print table to standard output : Broken pipe (os error 32)', /home/hongxu/.cargo/registry/src/
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at /checkout/src/libstd/sys/unix/backtrace/tracing/
       1: std::sys_common::backtrace::print
                 at /checkout/src/libstd/sys_common/
                 at /checkout/src/libstd/sys_common/
       2: std::panicking::default_hook::{{closure}}
                 at /checkout/src/libstd/
       3: std::panicking::default_hook
                 at /checkout/src/libstd/
       4: std::panicking::rust_panic_with_hook
                 at /checkout/src/libstd/
       5: std::panicking::begin_panic
                 at /checkout/src/libstd/
       6: std::panicking::begin_panic_fmt
                 at /checkout/src/libstd/
       7: prettytable::TableSlice::print_tty
       8: bingrep::format_elf::Elf::print::{{closure}}
       9: bingrep::format_elf::Elf::print
      10: bingrep::run
      11: bingrep::main
      12: __rust_maybe_catch_panic
                 at /checkout/src/libpanic_unwind/
      13: std::rt::lang_start
                 at /checkout/src/libstd/
                 at /checkout/src/libstd/
      14: __libc_start_main
      15: _start
    ~ > file ~/.cargo/bin/rustc
    /home/hongxu/.cargo/bin/rustc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.9, not stripped
    ~ > /home/hongxu/.cargo/bin/rustc --version                                                                                                                                                               
    rustc 1.24.0-nightly (2d4df9584 2017-12-10)
    opened by hongxuchen 11
  • crashes running on itself

    crashes running on itself

    rustc 1.30.0-nightly (73c78734b 2018-08-05)
    binary: rustc
    commit-hash: 73c78734bae8f2947a4bfdeabebeeb84ccf0b0e1
    commit-date: 2018-08-05
    host: x86_64-unknown-linux-gnu
    release: 1.30.0-nightly
    LLVM version: 7.0

    repo is at 41a73a85920aa0c37846c6d7e5c391c292de1731

    cargo build
    RUST_BACKTRACE=1 ./target/debug/bingrep target/debug/bingrep


                                                                         0x0                                0x0
                781870    GLOBAL     FUNC        _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i8$GT$3fmt17h4c27396496188f2dE
                                                                         0x91       .text(16)               0x0
                781910    GLOBAL     FUNC        _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i8$GT$3fmt17h62566deaeb3faf4cE
                                                                         0x91       .text(16)               0x0
                7819b0    GLOBAL     FUNC        _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i16$GT$3fmt17hf381e43bda4c6951E
                                                                         0x92       .text(16)               0x0
                781a50    GLOBAL     FUNC        _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i16$GT$3fmt17h93eac570e2e7c86eE
                                                                         0x92       .text(16)               0x0
                785bc0    GLOBAL     FUNC        _ZN4core3fmt9Formatter12pad_integral17h0a1e2b34e19c7ddcE
                                                                         0x3d7      .text(16)               0x0
                782cc0    GLOBAL     FUNC        _ZN49_$LT$i8$u20$as$u20$core..slice..SliceContains$GT$14slice_contains17h417b7695ed3578c1E
                                                                         0x12       .text(16)               0x0
                 853b0    GLOBAL     OBJECT      _ZN4core3str15UTF8_CHAR_WIDTH17h727782c8fa92515fE
                                                                         0x100      .rodata(5)              0x0
                785290    GLOBAL     FUNC        _ZN4core3num21_$LT$impl$u20$u64$GT$25checked_next_power_of_two17h9ebcca98f19e8d85E
                                                                         0x29       .text(16)               0x0
                787d30    GLOBAL     FUNC        _ZN82_$LT$$LT$$u27$a$GT$$u20$as$u20$core..fmt..Write$GT$9write_str17h2ae040e1ef527b3cE
                                                                         0x24e      .text(16)               0x0
                7884f0    GLOBAL     FUNC        _ZN4core3fmt8builders8DebugSet5entry17h69411f4b5bb034afE
                                                                         0xe        .text(16)               0x0
                7897e0    GLOBAL     FUNC        _ZN62_$LT$core..num..bignum..Big32x40$u20$as$u20$core..cmp..Ord$GT$3cmp17hfee4d6134a187f3dE
                                                                         0x55       .text(16)               0x0
                     0    GLOBAL     FUNC        __register_atfork
                                                                         0x0                                0x0
                     0    GLOBAL     FUNC        __cxa_atexit
                                                                         0x0                                0x0
                     0    GLOBAL     FUNC        __xstat64
                                                                         0x0                                0x0
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadOffset(131072)', libcore/
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at libstd/sys/unix/backtrace/tracing/
       1: std::sys_common::backtrace::print
                 at libstd/sys_common/
                 at libstd/sys_common/
       2: std::panicking::default_hook::{{closure}}
                 at libstd/
       3: std::panicking::default_hook
                 at libstd/
       4: std::panicking::rust_panic_with_hook
                 at libstd/
       5: std::panicking::continue_panic_fmt
                 at libstd/
       6: rust_begin_unwind
                 at libstd/
       7: core::panicking::panic_fmt
                 at libcore/
       8: core::result::unwrap_failed
                 at /checkout/src/libcore/
       9: <core::result::Result<T, E>>::unwrap
                 at /checkout/src/libcore/
      10: bingrep::format_elf::Elf::print::{{closure}}
                 at /home/matthias/.cargo/registry/src/
                 at src/
      11: bingrep::format_elf::Elf::print
                 at src/
      12: bingrep::run
                 at src/
      13: bingrep::main
                 at src/
      14: std::rt::lang_start::{{closure}}
                 at /checkout/src/libstd/
      15: std::panicking::try::do_call
                 at libstd/
                 at libstd/
      16: __rust_maybe_catch_panic
                 at libpanic_unwind/
      17: std::rt::lang_start_internal
                 at libstd/
                 at libstd/
                 at libstd/
      18: std::rt::lang_start
                 at /checkout/src/libstd/
      19: main
      20: __libc_start_main
      21: _start
    opened by matthiaskrgr 10
  • Error on running command

    Error on running command


    I see below error. Didnt find any solution useful on google to resolve this..

    ajith@ashetty:~/Desktop/bingrep-master$ cargo build --release --verbose Updating registry Updating git repository failed to parse registry's information for: colored

    Caused by: the given version requirement is invalid

    opened by ajithshetty2383 8
  • Create git tag for releases

    Create git tag for releases

    I'd like to package this tool in Homebrew. However, like many other package managers, a tag release is required. As such, the source code for each versions can be downloaded through some url.

    I noticed there are version bumps in Cargo.toml, so all you need to do is to create git tag (or even better creating Github Release).


    opened by xu-cheng 7
  • bingrep is reported as a lib

    bingrep is reported as a lib

    Running bingrep on bingrep, says that it is a lib:

    is_lib: true

    While unrelated to this issue, I would also like to note that Soname prints Some("lib") when it is a lib. Maybe it would be better to match on that value and present the name of the lib directly.

    opened by lilianmoraru 7
  • Skip zero-sized ranges

    Skip zero-sized ranges

    Thanks for this awesome tool!

    I ran into a panic when trying bingrep against /bin/ls and the problem was that it was trying to represent the .bss section as a range in the binary, but as you know that section takes no space in the binary.

    opened by ebroto 5
  • memory allocation of 18446744073709551610 bytes failed[1]

    memory allocation of 18446744073709551610 bytes failed[1]

    HI ! I found a memory allocation of 18446744073709551610 bytes failed in the current master e232665 POC :

    $ ./bingrep out/default/crashes/poc 
    ELF EXEC EM_UNKNOWN-little-endian @ 0x8049080:
    e_phoff: 0x80 e_shoff: 0xc e_flags: 0x10000 e_ehsize: 0 e_phentsize: 3 e_phnum: 0 e_shentsize: 36992 e_shnum: 2 e_shstrndx: 0
    memory allocation of 18446744073709551610 bytes failed[1]    552937 abort      ./bingrep out/default/crashes/poc
    opened by p870613 4
  • Outdated Cargo.lock file?

    Outdated Cargo.lock file?

    bingrep is currently failing to build for Homebrew with Rust 1.49 on Apple Silicon:

    It appears this is due to a stale lock file, causing cargo install --locked to pull in dependencies that do not work for bingrep on Apple Silicon. Is it possible for the Cargo.lock file to be updated? If this could be done with a new release, that would be especially helpful.


    opened by carlocab 4
  • How to correctly page bingrep output with color?

    How to correctly page bingrep output with color?

    I just recently discovered bingrep and think it's quite cool. But, in my haste, I decided to try and bingrep ~/.cargo/bin/rg and found it spit out 35000 lines of very nice colorful output. So then tried bingrep ~/.cargo/bin/rg | less and...aww, no color.

    But bingrep -h tells me about the --color option and, yay, color...but also a lot of ^O characters everywhere.

    So, I'm just wondering: is there a way to page bingrep output and make it look like the non-paged output?

    opened by mathomp4 4
  • Linking memrange (via metagoblin) causes GPL license violation

    Linking memrange (via metagoblin) causes GPL license violation

    Disclaimer: IANAL. I'm trying my best to be correct but I may be wrong.

    FWICS this package depends on metagoblin and theban_interval_tree, both of which in turn depend on memrange. Since memrange is GPL-3, it effectively requires any derivative work to be licensed GPL-3 as well. theban_interval_tree seems to try to do that. However, both metagoblin and bingrep specify only the MIT license.

    if you wish to continue depending on memrange, I believe you need to redistribute both packages as GPL-3. I think you can still license the source files specific to those packages under the MIT license but the combined work must be licensed GPL-3.

    opened by mgorny 4
  • Bingrep also doesn't support ELF objects with many sections

    Bingrep also doesn't support ELF objects with many sections

    bingrep 0.6.2 doesn't handle ELF files with many sections.

    (This is a follow up on

    To reproduce:

    $ cat 
    for i in range(0x10000):
    	print("void func" + str(i) + "(void){}")
    print("int main() {}")
    $ python3 >huge.c
    $ clang -c -ffunction-sections -o hostHuge2.o huge.c
    $ bingrep hostHuge2.o 
    ELF REL X86_64-little-endian @ 0x0:
    e_phoff: 0x0 e_shoff: 0x8bd640 e_flags: 0x0 e_ehsize: 64 e_phentsize: 0 e_phnum: 0 e_shentsize: 64 e_shnum: 0 e_shstrndx: 1
    Dyn Syms(0):
    Dynamic Relas(0):
    Dynamic Rel(0):
    Plt Relocations(0):
    Shdr Relocations(0):
    Dynamic: None
    Soname: None
    Interpreter: None
    is_64: true
    is_lib: false
    little_endian: true
    entry: 0

    Readelf correctly handles the extra sections:

    ELF Header:
      Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF64
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              REL (Relocatable file)
      Machine:                           Advanced Micro Devices X86-64
      Version:                           0x1
      Entry point address:               0x0
      Start of program headers:          0 (bytes into file)
      Start of section headers:          9164352 (bytes into file)
      Flags:                             0x0
      Size of this header:               64 (bytes)
      Size of program headers:           0 (bytes)
      Number of program headers:         0
      Size of section headers:           64 (bytes)
      Number of section headers:         0 (65546)
      Section header string table index: 1 <corrupt: out of range>
    Section Headers:
      [Nr] Name              Type             Address           Offset
           Size              EntSize          Flags  Link  Info  Align
      [ 0]                   NULL             0000000000000000  00000000
           000000000001000a  0000000000000000           0     0     0
      [ 1] .strtab           STRTAB           0000000000000000  007c0140
           00000000000fd4fa  0000000000000000           0     0     1
      [ 2] .text             PROGBITS         0000000000000000  00000040
    opened by zhuowei 4
  • mach: better load command info

    mach: better load command info

    Load commands could use some love when it comes to printing their content.

    Should be very straighforward, e.g. this is output currently:

       0 LC_SEGMENT_64
       1 LC_SEGMENT_64
       2 LC_SEGMENT_64
       3 LC_ID_DYLIB
       5 LC_SYMTAB
       6 LC_DYSYMTAB
       7 LC_UUID
      11 LC_LOAD_DYLIB
      12 LC_LOAD_DYLIB
      13 LC_LOAD_DYLIB
      14 LC_LOAD_DYLIB
      15 LC_LOAD_DYLIB
      16 LC_LOAD_DYLIB
      17 LC_LOAD_DYLIB
      28 LC_DATA_IN_CODE

    Would be nice to either summarize the important data in the load command (the version, the uuid, etc.) or just fully print the values of each (more noisy).

    I'll pretty much merge anything that does this in a reasonable manner

    enhancement help wanted 
    opened by m4b 0
  • survey: binary search string results + api + usecases

    survey: binary search string results + api + usecases



    So I've begun adding search functionality, and I already find it very useful. In particular, this is a usecase I find myself having:

    1. I want to search a binary for a string; this string could be a symbol I'm looking for, or an actual string in the binary, or it could be an import, or it could be referenced by a relocation.
    2. I want the search results to display these matches in a semantically meaningful manner

    There are a number of issues at hand here. It's in the beginning stages, so I'd like to ask for everyone (anyone's) input about:

    1. what their common usecase for "grepping" a binary is
    2. how they'd like to see this information displayed
    3. how they'd like to present the search to the program
    4. what they'd expect to be output

    Again, there's a lot going on here, so I'll open up with a particular example which addresses the uses I usually have, but I'd really like to know what other people want!

    Grepping for a static string

    I'm debugging/analyzing a binary. I want to see if "hello world" is somewhere in the binary. So I run:

    bingrep merp -s "hello"

    I want to know a few things:

    1. at what offset(s) the string occurred in the binary, if any
    2. how this offset would be normalized into the virtual address space of the section/program header/whatever
    3. where, semantically, could we interpret this offset and/or vm address w.r.t. what we know about the binaries sections/segments/etc?

    It might look something like this:

    Matches for "hello":
      ├──PT_LOAD(2) ∈ 0x724
      ├──.rodata(16) ∈ 0x724
      Idx   Name              Type   Flags    Offset   Addr     Size    Link   Entsize   Align  
      16    .rodata   SHT_PROGBITS   ALLOC    0x720    0x720    0x12           0x0       0x4    
      ├──.strtab(28) ∈ 0x9f
      Idx   Name            Type   Flags   Offset    Addr   Size     Link   Entsize   Align  
      28    .strtab   SHT_STRTAB           0x1668    0x0    0x20a           0x0       0x1 

    Which is trying to say that hello was found at offset 0x724 in the binary; it is normalized to 0x724 in the PT_LOAD program header (for elf); to the .rodata section in the section headers, and here is that section header.

    Similarly, it was also found in a strtab section header, which normalized is to the offset of 0x9f starting from 0x1668

    Grepping for a symbol

    Similarly, suppose we're looking simply for whether puts is called by our binary, and if so, what are the details of the symbol, and if possible, where is it called.

    Perhaps using the same api, we search for:

    bingrep binary -s puts

    and this returns to us a couple of hits, which are semantically quite different:

    Dyn Syms(8):
                   Addr   Bind       Type        Symbol                        Size   Section     Other  
                     0    GLOBAL     FUNC        puts                          0x0                0x0    
    Plt Relocations:
              201018 X86_64_JUMP_SLOT puts


    What i'd like in both of these cases, if possible, is a unified api for querying the contents of a binary for a search string, and very importantly:

    1. an efficient, terse, but understable presentation of this information

    I don't want it to be busy; I want with similar color coding techniques to highlight the information I need; and I want the output to be semantically relevant, e.g., the search string is used against symbol names in the symbol table, etc.

    Ideally, this is presented finally to the user as some kind of tabular structure, or a summary of a group of tabular structures, each tailored to the semantic content the string matched against, perhaps in different categories, like:

    raw string:
     - [ offset, vmaddr, phdr ]
     - [ offset, vmaddr, shdr ]
     - dynamic entry
     - symtab entry
     - debugging entry
     - locations 

    etc., for any various number of different kinds of matches, and categories.

    Implementation Details

    I'm not a big text search aficionado, so if anyone wants to help with the actual search string api, e.g., regexes, case insensitive, etc., as well as efficiency concerns, that would be great - i'm all ears - or in the case of PRs, very grateful!


    If you have a usecase, or an idea of how to present this information usefully, I'm interested in your feedback.

    The master branch right now contains a very, very prototypical implementation invoked via:

    bingrep <binary> -s "your string"

    it is case sensitive, but also accidentally works with prefixes.

    It currently dumps the regular print, then scans the binary, and pushes all matches, then normalizes the string against the program and section headers. I've started experimented with other "semantic" output, and there's definitely a lot of potential, hence this issue :)

    Output is like:

    Matches for "hello":
      ├──PT_LOAD(2) ∈ 0x724
      ├──.rodata(16) ∈ 0x724
      ├──.strtab(28) ∈ 0x9f
    enhancement help wanted question 
    opened by m4b 3
  • add search string

    add search string

    re #1:

    I'd like to do:

    bingrep "function_name" <some binary>

    which will return any matches for the function in the various "sections" of the binary, e.g., in the dynamic symbol table, the strippable symbol table, the string table, etc.

    enhancement help wanted 
    opened by m4b 0
  • executable name sucks

    executable name sucks

    Current Candidate(s)

    • bingrep (no rename)
    • binocular
    • bing

    bg cannot be used without path prefix because of bg for job backgrounding in bash/posix.

    so we need to choose a better one. i'm thinking two letters (lets jump on the grep shortname bandwagon renaissance we're in the middle of).

    Some candidates:

    1. binocular
    2. binlens
    3. ~~od (ObjDump)~~
    4. ng (biNGrep)
    5. ig (bInGrep)
    6. bd (BinDump)
    7. bing (BINGrep)
    8. bgrep

    Or also any other name :P

    opened by m4b 31
A bash-like Unix shell written in Rust

Cicada Unix Shell Cicada is a simple Unix shell written in Rust. Documents Install cicada Environment Variables Cicada Builtins Completion RC File His

Hugo Wang 921 Dec 28, 2022
Provides assert_eq! like macros with colorized diff output

similar-asserts similar-asserts is a crate that enhances the default assertion experience by using similar for diffing. It supports comparing either D

Armin Ronacher 74 Nov 29, 2022
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

null 294 Dec 23, 2022
singe's grep - a fast grep using single-file parallelism

singrep singe's grep - a fast grep using single-file parallelism singrep makes use of deterministic kernel file cache'ing to read the file fast enough

Dominic White 44 Nov 18, 2022
Like grep, but uses tree-sitter grammars to search

tree-grepper Works like grep, but uses tree-sitter to search for structure instead of strings. Installing This isn't available packaged anywhere. That

Brian Hicks 219 Dec 25, 2022
A simple rust implmentation of uber-go/ratelimit.

ratelimit-rs This package provides a simple Rust implementation of uber-go/ratelimit( -- a rate limiter based on

bee0_0 3 Jun 27, 2022
`grep` but with PEG patterns. Define grammars (e.g. `digit`), functions for matching. No more regex syntax!

PEG peggrep Example file demo_file: THIS LINE IS THE 1ST UPPER CASE LINE IN THIS FILE. this line is the 1st lower case line in this file. This Line Ha

IchHabeKeineNamen 3 Apr 18, 2023
Fgr - Find & Grep utility with SQL-like query language

fgr Find & Grep utility with SQL-like query language. Examples # Find all files with name equal to sample under the current directory: fgr -e name=sam

Igor 3 Dec 22, 2022
GREP like cli tool written in rust.

Show [ grep,tail,cat ] like cli tool written in rust. Only one release as of now which does very basic function,code has been refactored where other f

Siri 4 Jul 24, 2023
A bit like tee, a bit like script, but all with a fake tty. Lets you remote control and watch a process

teetty teetty is a wrapper binary to execute a command in a pty while providing remote control facilities. This allows logging the stdout of a process

Armin Ronacher 259 Jan 3, 2023
Baby's first Rust CLI project. Basic implementation of grep. Written in about 100 SLOC.

minigrep Coding project from Chapter 12 of the The Rust Programming Language book. Usage Compile and run as so minigrep QUERY FILENAME QUERY being the

Anis 2 Oct 2, 2021
Grep with human-friendly search output

hgrep: Human-friendly GREP hgrep is a grep tool to search files with given pattern and print the matched code snippets with human-friendly syntax high

Linda_pp 345 Jan 4, 2023
A toy re-implementation of GNU Grep by Rust.

Mini Grep Mini Grep is a simple rust re-implementation of GNU Grep, which means it could just implement limited functions, such as searching specific

PeterWrght 1 Jul 15, 2022
A syntax-highlighting pager for git, diff, and grep output

Get Started Install delta and add this to your ~/.gitconfig: [core] pager = delta [interactive] diffFilter = delta --color-only [delta]

Dan Davison 16k Dec 31, 2022
A rough transliteration of ls and grep from Toybox into Rust

Toybox to Rust (transliteration) A rough port of ls and grep from Toybox by trying to follow the original structure of the C code. Building Your syste

null 0 Dec 25, 2021
A simplified recreation of the command-line utility grep written in Rust.

smolgrep A simplified recreation of the command-line utility grep written in Rust. Download and run Download Rust On Mac/Linux Open a terminal and ent

Thi Dinh 0 Dec 27, 2021
clone of grep cli written in Rust. From Chapter 12 of the Rust Programming Language book

minigrep is a clone of the grep cli in rust Minigrep will find a query string in a file. To test it out, clone the project and run cargo run body poem

Raunak Singh 1 Dec 14, 2021
Command-line tool that provides a workflow for extending, editing, diffing, and writing to vim-style grep lines.

Grug Grug is a command-line tool that provides a workflow for expanding, editing, diffing, and writing edits to files using vim-styled grep lines (suc

null 4 Apr 25, 2023
A minimal version of 'grep' implemented in Rust. Exercise in the "The Rust Programming Language" book.

Minigrep - A simple grep-like tool implemented in Rust This simple CLI tool searches for a given pattern in a specified file and as a result, it print

Filip Szutkowski 3 Mar 15, 2024