Coreutils - upstream mirror

These are the GNU core utilities.  This package is the union of
the GNU fileutils, sh-utils, and textutils packages.

Most of these programs have significant advantages over their Unix
counterparts, such as greater speed, additional options, and fewer
arbitrary limits.

The programs that can be built with this package are:

  [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown
  chroot cksum comm coreutils cp csplit cut date dd df dir dircolors dirname
  du echo env expand expr factor false fmt fold groups head hostid hostname
  id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp
  mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx
  pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum
  sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync
  tac tail tee test timeout touch tr true truncate tsort tty uname unexpand
  uniq unlink uptime users vdir wc who whoami yes

See the file NEWS for a list of major changes in the current release.

If you obtained this file as part of a "git clone", then see the
README-hacking file.  If this file came to you as part of a tar archive,
then see the file INSTALL for compilation and installation instructions.

Like the rest of the GNU system, these programs mostly conform to
POSIX, with BSD and other extensions.  For closer conformance, or
conformance to a particular POSIX version, set the POSIXLY_CORRECT
and the _POSIX2_VERSION environment variables, as described in
the documentation under "Standards conformance".

The ls, dir, and vdir commands are all separate executables instead of
one program that checks argv[0] because people often rename these
programs to things like gls, gnuls, l, etc.  Renaming a program
file shouldn't affect how it operates, so that people can get the
behavior they want with whatever name they want.

Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, Karl Berry,
Kaveh Ghazi, and François Pinard for help with debugging and porting
these programs.  Many thanks to all of the people who have taken the
time to submit problem reports and fixes.  All contributed changes are
attributed in the commit logs.

And thanks to the following people who have provided accounts for
portability testing on many different types of systems: Bob Proulx,
Christian Robert, François Pinard, Greg McGary, Harlan Stenn,
Joel N. Weber, Mark D. Roth, Matt Schalit, Nelson H. F. Beebe,
Réjean Payette, Sam Tardieu.

Thanks to Michael Stone for inflicting test releases of this package
on Debian's unstable distribution, and to all the kind folks who used
that distribution and found and reported bugs.

Note that each man page is now automatically generated from a template
and from the corresponding --help usage message.  Patches to the template
files (man/*.x) are welcome.  However, the authoritative documentation
is in texinfo form in the doc directory.

Pre-C99 build failure

In 2009 we added this requirement:
To build the coreutils from source, you must have a C99-conforming
compiler, due to the use of declarations after non-declaration statements
in several files in src/.  There is code in configure to find and, if
possible, enable an appropriate compiler.  However, if configure doesn't
find a C99 compiler, it continues nonetheless, and your build will fail.
There used to be a "c99-to-c89.diff" patch you could apply to convert
to code that even an old pre-c99 compiler can handle, but it was too
tedious to maintain, so has been removed.

HPUX 11.x build failure

A known problem exists when compiling on HPUX on both hppa and ia64
in 64-bit mode (i.e., +DD64) on HP-UX 11.0, 11.11, and 11.23.  This
is not due to a bug in the package but instead due to a bug in the
system header file which breaks things in 64-bit mode.  The default
compilation mode is 32-bit and the software compiles fine using the
default mode.  To build this software in 64-bit mode you will need
to fix the system /usr/include/inttypes.h header file.  After
correcting that file the software also compiles fine in 64-bit mode.
Here is one possible patch to correct the problem:

--- /usr/include/inttypes.h.orig	Thu May 30 01:00:00 1996
+++ /usr/include/inttypes.h	Sun Mar 23 00:20:36 2003
@@ -489 +489 @@
-#ifndef __STDC_32_MODE__
+#ifndef __LP64__

OSF/1 4.0d and AIX build failures

If you use /usr/bin/make on these systems, the build will fail due
to the presence of the "[" target.  OSF/1 make(1) appears to
treat "[" as some syntax relating to locks, while AIX make(1)
appears to skip the "[" target.  To work around these issues
the best solution is to use GNU make.  Otherwise, simply remove
all mention of "[$(EXEEXT)" from src/Makefile.

32 bit time_t build failures

On systems where it's determined that 64 bit time_t is supported
(indicated by touch -t <some time after 2038>), but that coreutils
would be built with a narrower time_t, the build will fail.
This can be allowed by passing TIME_T_32_BIT_OK=yes to configure,
or avoided by enabling 64 bit builds.  For example GCC on AIX defaults
to 32 bit, and to enable the 64 bit ABI one can use:
./configure CFLAGS=-maix64 LDFLAGs=-maix64 AR='ar -X64'

"make check" failure on IRIX 6.5 and Solaris <= 9

Using the vendor make program to run "make check" fails on these two systems.
If you want to run all of the tests there, use GNU make.

Running tests as root:

If you run the tests as root, note that a few of them create files
and/or run programs as a non-root user, 'nobody' by default.
If you want to use some other non-root username, specify it via
the NON_ROOT_USERNAME environment variable.  Depending on the
permissions with which the working directories have been created,
using 'nobody' may fail, because that user won't have the required
read and write access to the build and test directories.
I find that it is best to unpack and build as a non-privileged
user, and then to run the following command as that user in order
to run the privilege-requiring tests:

  sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root

If you can run the tests as root, please do so and report any
problems.  We get much less test coverage in that mode, and it's
arguably more important that these tools work well when run by
root than when run by less privileged users.

Reporting bugs:

Send bug reports, questions, comments, etc. to [email protected].
To suggest a patch, see the files README-hacking and HACKING for tips.

If you have a problem with 'sort', try running 'sort --debug', as it
can often help find and fix problems without having to wait for an
answer to a bug report.  If the debug output does not suffice to fix
the problem on your own, please compress and attach it to the rest of
your bug report.

IMPORTANT: if you take the time to report a test failure,
please be sure to include the output of running 'make check'
in verbose mode for each failing test.  For example,
if the test that fails is tests/df/, then you would
run this command:

  make check TESTS=tests/df/ VERBOSE=yes SUBDIRS=. >> log 2>&1

For some tests, you can get even more detail by adding DEBUG=yes.
Then include the contents of the file 'log' in your bug report.


There are many tests, but nowhere near as many as we need.
Additions and corrections are very welcome.

If you see a problem that you've already reported, feel free to re-report
it -- it won't bother me to get a reminder.  Besides, the more messages I
get regarding a particular problem the sooner it'll be fixed -- usually.
If you sent a complete patch and, after a couple weeks you haven't
received any acknowledgement, please ping us.  A complete patch includes
a well-written ChangeLog entry, unified (diff -u format) diffs relative
to the most recent test release (or, better, relative to the latest
sources in the public repository), an explanation for why the patch is
necessary or useful, and if at all possible, enough information to
reproduce whatever problem prompted it.  Plus, you'll earn lots of
karma if you include a test case to exercise any bug(s) you fix.
Here are instructions for checking out the latest development sources:

If your patch adds a new feature, please try to get some sort of consensus
that it is a worthwhile change.  One way to do that is to send mail to
[email protected] including as much description and justification
as you can.  Based on the feedback that generates, you may be able to
convince us that it's worth adding.  Please also consult the list of
previously discussed but ultimately rejected feature requests at:

WARNING:  Now that we use the ./bootstrap script, you should not run
autoreconf manually.  Doing that will overwrite essential source files
with older versions, which may make the package unbuildable or introduce
subtle bugs.

WARNING:  If you modify files like, m4/*.m4, aclocal.m4,
or any, then don't be surprised if what gets regenerated no
longer works.  To make things work, you'll have to be using appropriate
versions of the tools listed in bootstrap.conf's buildreq string.

All of these programs except 'test' recognize the '--version' option.
When reporting bugs, please include in the subject line both the package
name/version and the name of the program for which you found a problem.

For general documentation on the coding and usage standards
this distribution follows, see the GNU Coding Standards at:

For any copyright year range specified as YYYY-ZZZZ in this package
note that the range specifies every single year in that closed interval.

Mail suggestions and bug reports for these programs to
the address on the last line of --help output.


Copyright (C) 1998-2021 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts.  A copy of the license is included in the "GNU Free
Documentation License" file as part of this distribution.
  • test-localeconv failed when make check about coreutils@9.1 on openEuler_aarch64

    test-localeconv failed when make check about [email protected] on openEuler_aarch64

    I meet a problem:test-localeconv failed when make check about [email protected] on openEuler_aarch64

    Steps to reproduce the issue

    [root@localhost coreutils]# make -j126 check
    Testsuite summary for GNU coreutils 9.1
    # TOTAL: 370
    # PASS:  344
    # SKIP:  25
    # XFAIL: 0
    # FAIL:  1
    # XPASS: 0
    # ERROR: 0
    See gnulib-tests/test-suite.log
    [root@localhost spack-src]# vim gnulib-tests/test-suite.log
    FAIL: test-localeconv
    test-localeconv.c:53: assertion 'l->frac_digits == CHAR_MAX' failed
    FAIL test-localeconv (exit status: 134)
    [root@localhost gnulib-tests]# ./test-localeconv
    test-localeconv.c:53: assertion 'l->frac_digits == CHAR_MAX' failed
    Aborted (core dumped)

    Can you analyze why the error is reported, or what settings I'm missing?

    opened by Tom-python0121 10
  • Can't build with LLVM 5.0

    Can't build with LLVM 5.0

    Hi @pixelb @eggert ,

    i can't build coreutils 8.28 with LLVM/clang 5.0.0

    In file included from lib/mbsstr.c:32: ./lib/str-kmp.h:42:30: error: use of unknown builtin '__builtin_mul_overflow_p' [-Wimplicit-function-declaration] size_t *table = (size_t *) nmalloca (m, sizeof (size_t)); ^ ./lib/malloca.h:79:25: note: expanded from macro 'nmalloca' #define nmalloca(n, s) (xalloc_oversized (n, s) ? NULL : malloca ((n) * (s))) ^ ./lib/xalloc-oversized.h:46:4: note: expanded from macro 'xalloc_oversized' __builtin_mul_overflow_p (n, s, (__xalloc_count_type) 1) ^ 1 error generated.

    here are the logs

    opened by tpgxyz 9
  • fix cases where insecure randomness could be used

    fix cases where insecure randomness could be used

    Apologies for submitting on GitHub, it's so much more convenient. I will understand if no one sees this because I didn't follow the guidelines.


    • The existing code is dangerous because it can silently fail to seed the random number generator securely, either when fopen() fails or when read() returns fewer bytes than requested, which can happen if the call is interrupted by an interrupt. This is important for utilities like shred where cryptographic-quality randomness is important.
    • I removed the bytes_bound stuff because it didn't seem necessary anywhere it was used, and if get_nonce is ever called with bytes_bound < bufsize, then part of ISAAC's initial state will contain timestamps/PIDs, so it will not be uniformly random. Usually, stream ciphers like ISAAC require their initial state to be uniformly random, otherwise there will be statistical biases in the early output.

    I have not tested all the utilities this affects.

    (Full disclosure is appropriate in this case because any damage has already been done, fixing the problem in secret would not stop any attacks, but disclosing might encourage users to stop using the dangerous code and upgrade.)

    opened by defuse 7
  • Update rmdir usage

    Update rmdir usage

    Please consider merging this usage/man change to document recent breaking changes on rmdir tool.

    Related to this bug: And this commit:

    Alternatively revert the linked commit. Regards,

    opened by frikiluser 5
  • Fix some tail bugs

    Fix some tail bugs

    run below script (using inotify)

    let count=0; echo $count>>a.log; tail -F a.log & while true; do mv a.log a.log.$count; let count=count+1; echo $count>>a.log; done

    When the number of generated file is over the "/proc/sys/fs/inotify/max_user_watches", tail can't watch new a.log file.

    opened by mastojun 5
  • test or fail on BTRFS

    test or fail on BTRFS

    Building latest coreutils, running test on btrfs will FAIL. After digging on the test script, and run all the test case manually, I have found the reason. test fails on the last part, on line 58

      51 cp --sparse=always k k2 || fail=1
      52 if test $(stat -c %b k2) -ge $(stat -c %b k); then
      53   # If not sparse, then double check by creating with dd
      54   # as we're not guaranteed that seek will create a hole.
      55   # apfs on darwin 19.2.0 for example was seen to not to create holes < 16MiB.
      56   hole_size=$(stat -c %o k2) || framework_failure_
      57   dd if=k of=k2.dd bs=$hole_size conv=sparse || framework_failure_
      58   test $(stat -c %b k2) -eq $(stat -c %b k2.dd) || fail=1
      59 fi

    on ext4 file system, cp --sparse=always k k2 will create k2 smaller than k, thus skip the following tests on btrfs file system, cp --sparse=always k k2 will create k2 the same size of k, thus triggers the following tests in the if block on line 57, however, dd if=k of=k2.dd bs=$hole_size conv=sparse will create k2.dd smaller than k2, which is also smaller than k however, on line 58, this test expects k2 and k2.dd are the same size. I think on line 58, -eq should be -ge, because dd if=k of=k2.dd bs=$hole_size conv=sparse works as expected to create a file smaller than the source file.

    cp and dd works differently with --sparse on ext4 and btrfs

    opened by changyp6 4
  • Please publish a new release

    Please publish a new release

    As others have expressed, mailing lists are antiquated to deal with. Feel free to ignore and close this whenever it's seen.

    The last release was March 2020 with 8.32. That is the longest duration between a release for over a decade of coreutil releases.

    Not much came up searching the web, this projects README or the resource links provided in this issue template. I did come across an old mailing list question where the answer about release cadence was "whenever it's ready"..

    Is there a roadmap or related resource to get an idea of what's blocking that release? (this is a handy feature that platforms like Github or Gitlab can help with)

    I'm particularly interested in the cp --reflink=auto default introduced back in June 2020 (fun fact: it's been exactly one year since this commit was made). Some distros backport this, but it'd be nicer to rely on an official release.

    It can be confusing/unexpected to find that the behaviour differs between distros packaging for coreutils when the version is the same..

    opened by polarathene 4
  • Compiling a specific binary in this package

    Compiling a specific binary in this package

    I want to use this code as a basis for my project. I am forking the mv command, since it's relatively simple (~500 lines of dedicated code), and its functions closely match the purpose of my program.

    (In case you're curious, I'm making a trash program similar to trash-cli.)

    I tried doing make help and ./configure --help, but I found no option to simply compile one binary.

    I did a trace on the Makefile, and isolated the command that produces the mv binary: gcc -I. -I./lib -Ilib -I./lib -Isrc -I./src -g -O2 -MT src/mv.o -MD -MP -MF $depbase.Tpo -c -o src/mv.o src/mv.c &&\ echo " CCLD " src/mv;gcc -g -O2 -Wl,--as-needed -o src/mv src/mv.o src/remove.o src/copy.o src/cp-hash.o src/extent-scan.o src/force-link.o src/selinux.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a -lacl -lattr

    Of course, it doesn't work without all the object files already generated. I can't tell which lines are producing them, and after skimming the Makefile and, I've concluded that I have a newfound appreciation for docker build environments. (I'm mostly a Python programmer, and don't have too much experience with the in-depth GNU toolchains.)

    Unfortunately, I can't figure out how to compile it without, y'know, compiling everything else. I don't want to have to drag 50M of source code around just for a variation on a coreutils binary. How can I compile just `mv.c?

    opened by alxpettit 4
  • updated and now 'rm' does not work, command not found.

    updated and now 'rm' does not work, command not found.

    I've just updated ubuntu with sudo apt-get update and sudo apt-get upgrade -y but now when I try using the rm command it says command not found. I try sudo apt install coreutils but it's showing I'm on the latest version.

    opened by JasonUK786 3
  • Sort by version idiosyncrasy

    Sort by version idiosyncrasy

    I do understand that this github mirror is not a proper place for reporting bugs but I just refuse to use email do that because such a workflow IMO is absolutely inconvenient, so I'm reporting a problem here and if coreutils developers are interested they will fix it regardless.

    I have coreutils 8.32 installed (to be precise coreutils-8.32-18.fc33.x86_64)

    It looks like sort by version doesn't always work correctly. Consider this listing:

    This is exactly what you see when you sort by name.

    However when you change the sorting mode to "by version" then something weird happens:

    This doesn't look right and seems rather illogical. Why has "" become the last one on the list?

    Please fix.

    opened by birdie-github 3
  • Wrong format for

    Wrong format for "date" program in LANG=id_ID.UTF-8

    I'm not sure if this is translation related issues, but each time I run the "date" program the format is wrong and make me confused.

    How to reproduce:

    LANG=id_ID.UTF-8 date --date="2021-01-26T18:49:57+07:00"

    The result:

    Sel 26 Jan 2021 06:49:57  WIB

    Expected result:

    Sel 26 Jan 2021 18:49:57 WIB

    As you can see, the result is wrong. This is off by 12 hours.

    It's really frustrating if unaware user use "date" as logging program and they get incorrect result.

    Additional note:

    If I use LANG=id date, the result is Tue Jan 26 18:49:57 WIB 2021. It seem the time format is correct, but the language and date format is messed up.

    NB: I know I can use: date +"%a %d %b %Y %T %Z" with result Sel 26 Jan 2021 18:49:57 WIB to make correct date.

    opened by bayuah 3
  • info share of additional stress test cases for [ factor ] utility

    info share of additional stress test cases for [ factor ] utility

    hope you don't mind, I've taken the liberty of algorithmically coding up the primes listed in the testing scenarios for the factor utility, and also created 2 more derivative primes from the same set using combinations of string manipulations.

    Feel free to incorporate these into the test cases as you see fit. Aside from gnu-gawk's template codes, I hereby declare all code shown below to be classified under [ public domain ] :

           # gawk profile, created Sun Nov 27 17:55:45 2022
           # BEGIN rule(s)
           BEGIN {
         1         OFS = RS
         1     CONVFMT = "%.250g"
         1     ___=(____=(__=((_+=++_)^++_)^(_^_-_-_))-(_^_*(_+_)+_)) \
                         (_____=__-(_^_+(_+_)*(_^_-_)+(_+_)^_))        \
                         (______=__+=__+(_+(_+_^_)*_))                 \
                         (__=rev(substr("", __ = sprintf("%.f%.f", int(____*__),
                         int(_____*__)), gsub("["(_^_)(_^_*_+--_^_)"]+","",__))__))
         1     gsub("[" ((++_+_)*(_+_^_)-_) "]+","",___)
         1     print _____, ____, ______, __, rev(___)
        94  function rev(___, __, _)
        94     return \
               (_+=_^=_<_)^_<(__=+__ ? +__ : length(___)) \
                ? rev(substr(___,_=int(__/-_)-+-++__),__-_) \
                  rev(substr(___,_^!--_,_),_)          \
                :     substr((___)(__<=_++? "" : substr(___,_--,
                           _^_==__) substr(___,_,--_))___,__,__)

    and output from gnu-factor utility ::

         - 9223372036854775421: 9223372036854775421
         - 9223372036854775643: 9223372036854775643
         - 18446744073709551709: 18446744073709551709
         - 94441166490049640643114101303190314499640643114101: 94441166490049640643114101303190314499640643114101
         - 4346046994430930304346046940094664449905590304464482454586302332293465458630233229: 4346046994430930304346046940094664449905590304464482454586302332293465458630233229
    opened by mogando668 0
  • -ELOOP on recursive symlink. Version behavior difference.

    -ELOOP on recursive symlink. Version behavior difference.

    On 8.32, When install does: $ strace install -m 0444 -o 0 -g 0 -D "recursive softlink" ... ... newfstatat(AT_FDCWD, "recursive softlink", 0x7ffe91a254d0, 0) = -1 ELOOP (Too many levels of symbolic links)

    Which isn't really unexpected, when trying to deal with a softlink like that.

    But on 9.1, the install seems to proceed just fine? Now I know that softlinks are a POSIX rabbithole, but the difference in behavior is ... unexpected? To me it looks like this was unintentionally "fixed" by cleaning of some code? Anyway. I can't find a commit or a declaration of changes to behavior. But maybe I'm just looking in the wrong place.

    opened by milkylainen 0
  • zzzzzzz error in coreutils

    zzzzzzz error in coreutils

    error: opening directory '/tmp/nix-build-coreutils-9.0.drv-0/coreutils-9.0/': File name too long

    opened by PrivacyMagnet 1
  • tail: ignore any ESPIPE errors when a pipe reappears

    tail: ignore any ESPIPE errors when a pipe reappears

    Given /tmp/test is a pipe that is regularly disappearing and reappearing, when running tail -F -n +1 /tmp/test the behavior changed from:

    tail: '/tmp/test' has become inaccessible: No such file or directory
    tail: '/tmp/test' has appeared;  following new file
    tail: /tmp/test: cannot seek to offset 0: Illegal seek


    tail: '/tmp/test' has become inaccessible: No such file or directory
    tail: '/tmp/test' has appeared;  following new file
    [new content]
    opened by docteurklein 0
mass surveillance for block game - mirror

Snowstorm mass surveillance for block game Yet another Minecraft Server Scanner Scan the entire ipv4 address space for Minecraft servers, with dynamic

null 11 Mar 2, 2024
Extends cargo to execute the given command on multiple crates - upstream is at

cargo-multi GitLab CI: master: develop: Travis: master: develop: Extends cargo to execute the given command on multiple crates. Inspired by git multi.

Cyril Plisko 6 Feb 27, 2022
Cross-platform Rust rewrite of the GNU coreutils

uutils coreutils uutils is an attempt at writing universal (as in cross-platform) CLI utilities in Rust. This repository is intended to aggregate GNU

null 13k Dec 30, 2022
Cross-platform Rust rewrite of the GNU coreutils

Cross-platform Rust rewrite of the GNU coreutils

null 13k Jan 8, 2023
A box full of utilities, a unworthy replacement for coreutils / busybox / toybox.

Gearbox A box full of utilities, a unworthy replacement for coreutils / busybox / toybox. List of content How to setup Systems Ubuntu Arch How to buil

Gemlock 5 Jul 21, 2022
Mirror of

Redox is an operating system written in Rust, a language with focus on safety and high performance. Redox, following the microkernel design, aims to b

Redox OS 14.3k Jan 3, 2023
Mirror of

Build Status: Features Written safely in the Rust programming language Features both a command-line and GTK3 interface Support for Templates to define

Michael Murphy 143 Sep 24, 2022
Mirror of

Introduction Ion is a modern system shell that features a simple, yet powerful, syntax. It is written entirely in Rust, which greatly increases the ov

Redox OS 1.3k Jan 4, 2023
Federated blogging application, thanks to ActivityPub (now on — this is just a mirror)

Plume Website — Documentation — Contribute — Instances list Plume is a federated blogging engine, based on ActivityPub. It is written in Rust, with th

Plume 1.9k Jan 8, 2023
Mirror of

Documentation Examples Changelog Tutorial Termion is a pure Rust, bindless library for low-level handling, manipulating and reading information about

Redox OS 1.9k Dec 31, 2022
Mirror of

RustType RustType is a pure Rust alternative to libraries like FreeType. The current capabilities of RustType: Reading OpenType formatted fonts and fo

Redox OS 567 Dec 5, 2022
Everyday-use client-side map-aware Arch Linux mirror ranking tool

Rate Arch Mirrors This is a tool, which fetches mirrors, skips outdated/syncing Arch Linux mirrors, then uses info about submarine cables and internet

Nikita Almakov 196 Jan 2, 2023
memflow based dxgi screen mirror prototype

memflow-mirror work in progress framebuffer mirror based on memflow. Installation Compile the guest-agent on Windows with: cargo build --release --bin

null 21 May 9, 2022
Check the reproducibility status of your Arch Linux packages (read-only mirror)

arch-repro-status A CLI tool for querying the reproducibility status of the Arch Linux packages using data from a rebuilderd instance such as reproduc

Arch Linux 12 Nov 16, 2022
A library that creates a terminal-like window with feature-packed drawing of text and easy input handling. MIRROR.

BearLibTerminal provides a pseudoterminal window with a grid of character cells and a simple yet powerful API for flexible textual output and uncompli

Tommy Ettinger 43 Oct 31, 2022
Userspace libpcap-based tool to mirror your dns traffic

DNS traffic mirroring tool (dns-mirror) Description Userspace libpcap-based tool. dns-mirror sniffs dns packets on the given interface and proxies it

Timofey 1 Mar 15, 2022
Mirror of oxipng for pre-commit.

oxipng pre-commit mirror Mirror of oxipng for pre-commit. Installation Add to your pre-commit config: - repo:

Adam Johnson 11 Jan 15, 2022
By mirroring traffic to and from your machine, mirrord surrounds your local service with a mirror image of its cloud environment.

mirrord lets you easily mirror traffic from your Kubernetes cluster to your development environment. It comes as both Visual Studio Code extension and

MetalBear 2.1k Jan 3, 2023
Rust wrapper for gphoto2 (mirror of

GPhoto2-rs Rust bindings to libgphoto2 What about gphoto-rs? I know about the other crate (gphoto and gphoto2-sys which was created by @dcuddeback, bu

Maxicarlos08 14 Dec 29, 2022
This is a mirror of

plate Rust library for writing simpler Vulkan code Installation Add the library to your Cargo.toml file: [dependencies] plate = "0.5" Example Example

Pedro Casotti 15 Sep 10, 2022