Pádraig Brady

Nice article. See also: https://www.pixelbeat.org/programming/stdio_buffering/ It's also worth mentioning a recent improvement we made (in coreutils 8.28) to the operation of the `tail | grep` example in the article. tail now notices if the pipe goes away, so one could wait for something to appear in a log, like: tail -f /log/file | grep -q match then_do_something There are lots of gotchas to pipe handling really. See also: https://www.pixelbeat.org/programming/sigpipe_handling.html

There have been various attempts to improve on strcpy() etc. The current thinking is that strscpy() is the best general interface to this functionality. See the "improving ... strcpy" section at https://www.pixelbeat.org/programming/gcc/string_buffers.html

here's the best guide i could find on enabling those checks in gcc. it is unclear whether they take advantage of the carry bits, do you have a source for that information? http://www.pixelbeat.org/programming/gcc/integer_overflow.html

a few nice ones here too, http://www.pixelbeat.org/cmdline.html, http://www.pixelbeat.org/docs/linux_commands.html always worth looking at these types of lists imo, whilst some of the commands mightn't really fit into your workflow or seem useful immediately, they're often exactly the snippets of information that can save hours at a later stage..

Great site. A few other pages on it worth checking out: http://www.pixelbeat.org/docs/power_of_the_default.html http://www.pixelbeat.org/docs/web/access_log/monitoring.html http://www.pixelbeat.org/fslint/

I started writing the basic commands in a comment, but it got kind of long. You'd best look at a reference. http://tnerual.eriogerg.free.fr/vimqrc.html http://www.pixelbeat.org/vim.tips.html http://www.rayninfo.co.uk/vimtips.html I'd start with looking at commands that allow you to quickly move around in buffers first (/, f, t, w, e, b etc). Then start combining those with actions (ct", dw etc). Then "timesavers" such as macros and built-in conveniences (q, gqq, marks etc). The rest will come to you.

Another maintainer and I follow issues and pull requests on a GitHub mirror. But email works fine for us and many other projects. Regarding poor UX, it is difficult to dispute with that claim without a specific example. Note that a lot of the features we support are standardized by POSIX. Even if we dislike the behavior, it is better to comply with the standards so the programs don't behave differently than users expect. The sentence you quote isn't meant to put down users. These programs are often much more complex than meets the eye, and there are lots of common gotchas that people have run into (and will continue to do so) [1]. Of course we would love for these programs to be useful for everyone. However, feature requests are often incompatible with existing behavior, incompatible with other feature requests, or have existing functionality elsewhere. For those reasons we cannot accept every feature request. [1] https://www.pixelbeat.org/docs/coreutils-gotchas.html

I'm to young for Netscape, but do you mean this [^1] interface, that's truncating the subject and hiding the body? Also, which use-cases do you have where you need to see 20 emails at once? [^1]: https://www.pixelbeat.org/docs/netscape_email/ns_4_email.jpg

Well, you can have a higher screen resolution than 640x480, resize those columns, hide the ones you don't use... Look at the Thunderbird 1 and 3 screenshots on that page http://www.pixelbeat.org/docs/netscape_email/

See also: * How the GNU coreutils are tested: https://www.pixelbeat.org/docs/coreutils-testing.html * Exploration of each of the coreutils commands: https://ratfactor.com/slackware/pkgblog/coreutils * Command line text processing with GNU Coreutils: https://learnbyexample.github.io/cli_text_processing_coreutils/ (my ebook that covers 20+ text processing tools)

It's not Python, it's a generic Unix problem. This is why stdbuf exists. http://www.pixelbeat.org/programming/stdio_buffering/

I'll start by saying... I'm not a developer by any serious sense anymore. I did C over a decade ago and realized it was just not for me With that out it the way... This rust infatuation seems like those people using one click tools to interpolate videos with "AI" The end result is objectively worse and it's done because of subjective opinion: (gleefully) these artifacts are so SMOOTH! Moving coreutils to rust is similar. The unit test coverage is low, and the problems they're seeing don't inspire confidence Predictability in the tools is being traded for memory safety. I'd worry about using these behind any scripts, an extra \n from an obscure pipe driven bug could mean portability disaster Edit: For example, these quirks https://www.pixelbeat.org/docs/coreutils-gotchas.html

The POSIX timezones having - and + reversed once cost me a day of pulling hairs: http://www.pixelbeat.org/docs/linux_timezones/

Shouldn't the link be http://www.pixelbeat.org/docs/web/comments/

I'm more than happy to include findrepo on the betterthengrep.com/more-tools page. If you'll make a page for it, or at least have something for newbies to read, I'll add a link. My concern is that someone who's new to all of this isn't going to understand what to do if I just link to http://www.pixelbeat.org/scripts/findrepo

One could consider PyLine to be the Python equivalent to Pipeable Ruby: http://code.activestate.com/recipes/437932-pyline-a-grep-like-sed-like… Or funcpy: http://www.pixelbeat.org/scripts/funcpy

Don't rely on vim syntax highlighting. By default it highlights shell scripts according to original Bourne shell syntax rather than POSIX. See the note on this page http://www.pixelbeat.org/programming/shell_script_mistakes.html and this linked mailing list thread http://groups.google.com/group/vim_dev/t/41139a32772b2f5f

Yet more nifty commands http://www.pixelbeat.org/cmdline.html

ps_mem.py - Determine how much RAM is currently being used per program, is useful when top command failed to report actual memory shared due to copy-on-write among multiple processes. http://www.pixelbeat.org/scripts/ps_mem.py http://wiki.apache.org/spamassassin/TopSharedMemoryBug

Is Everyone Leaving Google? As far as I can tell from the outside, many of the well-known employees of Google are still happily with the company. Someone might want to check this table ( http://www.pixelbeat.org/misc/google_stars.html ) to evaluate whether these "Google Stars" are still with the company in order to get a feeling of whether the sentiment of top employees abandoning Google holds true.

This is just wrong. The Virtual Memory Size (VSZ as he calls it in the article) is not what is important. Measuring actual memory preasure and costs on modern Linux is pretty non-trivial, just look at this wiki page about Spam Assassin: http://wiki.apache.org/spamassassin/TopSharedMemoryBug He needs to measure the real size of a multi-process daemon like apache by using a script like the ps_mem.py: http://www.pixelbeat.org/scripts/ps_mem.py That can measure the real memory use of each daemon, and while I don't think the overall picture will change much, measuring VSZ is just inaccurate.

I learnt the same trick some years ago, from an article called Shell Scripts Matter: https://dev.to/thiht/shell-scripts-matter So I took some of the advice and tips offered in there, and wrote a template file to be used as a baseline when writing scripts for any project that might need one: https://github.com/j1elo/shell-snippets/blob/master/template.sh Other resources that I link in the readme of that repo, because they were a great guide to write better and more robust scripts, are: - Writing Robust Bash Shell Scripts: https://www.davidpashley.com/articles/writing-robust-shell-scripts/ - Common shell script mistakes: http://www.pixelbeat.org/programming/shell_script_mistakes.html - Bash Pitfalls: http://mywiki.wooledge.org/BashPitfalls - The Bash Hackers Wiki: https://wiki.bash-hackers.org/ EDIT: -for anyone who would like to read some actual examples- I have to manage a bunch of scripts so actually a slightly more up to date version of the template is put into practice by means of a common bash.conf file that then gets sourced by all scripts: https://github.com/Kurento/adm-scripts/blob/master/bash.conf.sh

Read man pages. For every command you run, assume there is a man page, and assume there is quick help, there usually and often are both. $ man man # The man command has a man page about itself. $ man -help # The man command has quick help. A lot of this stuff is 40 years of accumulated and evolving conventions. Quick ref might not be available for a particular command, or might be found with -h, -help or --help. Read the bash man page. Or whichever shell you're using, but if you haven't set it yourself it's probably bash. The bash man page is pretty large, so don't read it all at once. Here's table of contents script that will give you a man page's table of contents. Make yourself a bin directory at /home/yourlogin/bin, then put it and other little tools that you write in there. Make them executable, and put that directory on your path. ("bin" is an old convention for "binary" or compiled programs. Ironically, most of what you put in there will not be binary. :) $ cat ~/bin/toc #! /usr/bin/env bash if [[ $# == 2 ]]; then man -S $2 -P "grep -E '^[^ ]'" $1 else man -P "grep -E '^[^ ]'" $1 fi $ toc time TIME(1) General Commands Manual TIME(1) NAME SYNOPSIS DESCRIPTION OPTIONS FORMATTING THE OUTPUT EXAMPLES ACCURACY DIAGNOSTICS AUTHOR SEE ALSO $ toc time 2 TIME(2) Linux Programmer's Manual TIME(2) NAME SYNOPSIS DESCRIPTION …

Yep, just ran ps_mem.py (http://www.pixelbeat.org/scripts/ps_mem.py) and here's my entire server. Not a busy one, but it lets you see what a running api server and accompanying programs look like. Private + Shared = RAM used Program 184.0 KiB + 31.5 KiB = 215.5 KiB atd 240.0 KiB + 55.0 KiB = 295.0 KiB cron 240.0 KiB + 68.0 KiB = 308.0 KiB upstart-socket-bridge 304.0 KiB + 72.0 KiB = 376.0 KiB upstart-udev-bridge 392.0 KiB + 79.0 KiB = 471.0 KiB sudo 696.0 KiB + 26.0 KiB = 722.0 KiB dhclient3 604.0 KiB + 189.0 KiB = 793.0 KiB getty (6) 940.0 KiB + 49.0 KiB = 989.0 KiB dbus-daemon 660.0 KiB + 366.0 KiB = 1.0 MiB udevd (3) 1.0 MiB + 71.0 KiB = 1.0 MiB rsyslogd 1.1 MiB + 35.5 KiB = 1.1 MiB redis-server 1.0 MiB + 122.5 KiB = 1.2 MiB init 964.0 KiB + 733.0 KiB = 1.7 MiB polkitd 1.4 MiB + 823.5 KiB = 2.2 MiB console-kit-daemon 2.5 MiB + 1.1 MiB = 3.6 MiB nginx (5) 1.3 MiB + 3.2 MiB = 4.6 MiB sshd (5) 5.4 MiB + 75.5 KiB = 5.5 MiB api_server <==== Go Program 13.8 MiB + 963.0 KiB = 14.7 MiB bash (2) 22.5 MiB + 314.0 KiB = 22.8 MiB mysqld 41.9 MiB + 5.1 MiB = 47.0 MiB python2.7 (2) 79.4 MiB + 542.0 KiB = 79.9 MiB java --------------------------------- 190.3 MiB =================================

Here's my full bash reading list: - ShellCheck: life-changing BASH linter and testing toolkit https://github.com/koalaman/shellcheck - 30 interesting commands for the Linux shell – Víctor López Ferrando https://www.lopezferrando.com/30-interesting-shell-commands/ - 7 Surprising Bash Variables https://zwischenzugs.com/2019/05/11/seven-surprising-bash-variables/ - anordal/shellharden https://github.com/anordal/shellharden/blob/master/how_to_do_things_sa… - barryclark/bashstrap https://github.com/barryclark/bashstrap - BashPitfalls : Greg's Wiki http://mywiki.wooledge.org/BashPitfalls - Common shell script mistakes http://www.pixelbeat.org/programming/shell_script_mistakes.html - Comparison of all the UNIX shells http://hyperpolyglot.org/unix-shells - Defensive Bash Programming https://www.kfirlavi.com/blog/2012/11/14/defensive-bash-programming/in… or https://jonlabelle.com/snippets/view/markdown/defensive-bash-programmi… - Bash FAQ and Cookbook https://mywiki.wooledge.org/BashFAQ - Detecting the use of "curl | bash" server side …