pixelbeat

http://www.pixelbeat.org/scripts/ansi2html.sh

For example this command never finishes, but consumes a constant (small) amount of mem.

  seq inf | shuf -n1

Thanks for the reference ;)

The yes command (which is generally useful for generating repetitive text):

    $ yes-old | pv > /dev/null ^C
    ... 55.8MiB/s ...
    $ yes-new | pv > /dev/null ^C
    ... 3.44GiB/s ...

Also we more than doubled the speed of wc -l (by avoiding function call overhead):

    $ yes | pv | wc-old -l ^C
    ... 230MiB/s ...
    $ yes | pv | wc-new -l ^C
    ... 558MiB/s ...

    $ seq-old inf | pv > /dev/null ^C
    ... 13.3MiB/s ...
    $ seq-new inf | pv > /dev/null ^C
    ... 497MiB/s ...

    xargs basename -a < a.txt

Summary of that is you can filter using xargs like:

    get_file_paths | xargs basename -a

https://github.com/coreutils/gnulib/blame/master/lib/fts.c#L...

https://github.com/coreutils/gnulib/commit/49078a78

http://www.pixelbeat.org/scripts/urldiff http://www.pixelbeat.org/scripts/idiff

See also mergely which supports diffing URLs: http://pixelbeat/programming/diffs/#mergely

https://twitter.com/pixelbeat_/status/587703133717057537

    paste -d '' <(printf '%s\n' $(seq 2 9) T J Q K A | sed 'p;p;p') \
    <(yes $'H\nD\nS\nC' | head -n52) |
    shuf -n5

You can generate HTML (and from that png or whatever) with http://www.pixelbeat.org/scripts/ansi2html.sh like

    $ COLUMNS=80 timeout 1 htop > t.ansi
    $ ansi2html.sh --bg=dark < t.ansi > t.html

    $ COLUMNS=80 htop -b | ansi2html.sh ...

https://github.com/diafygi/gnu-pricing

I've noted a few techniques I've used on my blog to get pages served in a single request to users, including using SSIs and avoid cloudflare's "rocket loader"

http://www.pixelbeat.org/docs/web/about/#performance

http://www.pixelbeat.org/programming/gcc/integer_overflow.ht...

1. cp will detect holes < 128KiB

2. cp --sparse=always it will avoid speculative preallocation used on file systems like XFS, which can have a significant impact on sparsification.

For example the yes command (generally useful for generating repetitive text):

    $ yes-old | pv > /dev/null ^C
    ... 55.8MiB/s ...
    $ yes-new | pv > /dev/null ^C
    ... 3.44GiB/s ...

It's interesting there are so many potential improvements in such widely used tools. For example we also more than doubled the speed of wc -l (by avoiding function call overhead):

    $ yes | pv | wc-old -l ^C
    ... 230MiB/s ...
    $ yes | pv | wc-new -l ^C
    ... 558MiB/s ...

    $ seq-old inf | pv > /dev/null ^C
    ... 13.3MiB/s ...
    $ seq-new inf | pv > /dev/null ^C
    ... 497MiB/s ...

I've noted some compile time and run time checking options at:

http://www.pixelbeat.org/programming/gcc/integer_overflow.ht...

Possibly mv might also benefit from this option to error out on EXDEV?

Feel free to discuss these things on coreutils@gnu.org

We try to be accomodating, and your suggestions here definitely have merit and are worth further discussion.

We have to be careful about doing too much (adding edge cases and complexity), though in this case how about:

    canon_src = canonicalize(src);
    canon_dst = canonicalize(dst);
    int ret = rename(src, dst);
    if (ret == EXDEV) {
      /* Note if there are symlinks being recreated
         between the canonicalize() and rename() above,
         then it's better to not fall back to a
         cross device copy anyway.  */
      if (common_prefix(canon_src, canon_dst))
          ret = EINVAL; /* Treat like "copy into self" */
    }

1. Not reinventing the wheel

2. Implicit use of multiple cores

Things could be improved I agree.

For example posix_spawn() could be efficiently implemented on glibc to avoid kernel overhead for fork()+exec() from large processes. Then language runtimes could use that to implement their "shell out" routines.

Also pipefail doesn't cater for SIGPIPE as detailed at http://www.pixelbeat.org/programming/sigpipe_handling.html which can be awkward.