Ronald Pringadi's Technical Notes

The following bash code might come in handy if you want to benchmark how long a program runs. The example assumes you want to pass two parameters along to the program. A timestamp is captured at the start and end of execution, and the difference (the processing time) is printed in seconds.

A few useful additions.

One thing to know about the script above: the ### YOUR COMMAND HERE ### line is just a comment — bash doesn’t run anything. If you copy-paste and try it, you’ll get Processing time is: 0 because the timer fires at _start_time, immediately advances to _end_time, and there’s nothing in between. Replace that comment with the actual command you want to measure, e.g.:

The simpler answer: time. If “how long did this take?” is the only question you’re asking, bash already has a builtin for it:

The three numbers are: wall-clock time (real), CPU time spent in user-mode code (user), and CPU time spent in kernel calls (sys). When user + sys is much less than real, your program was waiting on something (disk, network, sleep). When they’re roughly equal, it was CPU-bound.

The time keyword also wraps a whole pipeline or compound command:

The richer answer: /usr/bin/time. The standalone GNU time binary (different program, same name — note the explicit path or you’ll get the bash builtin) reports a lot more:

That’s the one to reach for when you care about memory usage, page faults, or context switches alongside timing. Some distros don’t ship it by default — apt install time or dnf install time if it’s missing.

Sub-second timing without date +%s. The original script’s resolution is one second, which is too coarse for anything fast. A few ways to get finer numbers:

$EPOCHREALTIME is a string like 1715000123.456789 with microsecond resolution. It’s free — no fork, no exec — so it’s safe to call inside a hot loop. The catch: bash arithmetic is integer-only, so you need awk or bc to do the floating-point subtraction.

When you want statistical confidence: hyperfine. If the question is “is my new version actually faster?” — you want averages over many runs, with warmup, and ideally a confidence interval. hyperfine is the modern tool for this:

It runs each command repeatedly, discards the warmup runs (which are usually slower because of cold caches), reports mean ± standard deviation, and gives you a relative-speedup figure. If you’re benchmarking anything where one-off variance matters — and that’s most things — this beats running time three times and squinting at the numbers.

Two gotchas worth knowing.

• System clock changes break date +%s. If NTP slews the clock backwards mid-run, your _processing_time can be negative or inflated. $EPOCHREALTIME has the same problem (both read CLOCK_REALTIME). For benchmarking, the correct clock is CLOCK_MONOTONIC, which never goes backwards — but bash doesn’t expose it directly. Use time or hyperfine for anything that needs to survive a clock change.
• Disk caches make repeated runs misleadingly fast. The first run of a program reads cold data from disk; the second run hits the page cache and looks 10x faster. Either drop caches between runs (echo 3 | sudo tee /proc/sys/vm/drop_caches on Linux) or — easier — let hyperfine handle the warmup phase for you.

2026 update: This post originally used ssh-keygen -t rsa. The current recommendation (e.g. GitHub’s SSH key guide) is Ed25519 — it produces shorter keys, is faster, and is considered more secure. Use RSA (4096-bit) only as a fallback for systems that don’t support Ed25519.

The -C “your_email@example.com” flag is just a comment/label embedded in the public key — it has no effect on the cryptography. It’s helpful for identifying which key is which when you have several. You can put any string there (or omit -C entirely). 🔐

Assume that your main server (the one you use the most) is ServerA. And from ServerA, you want to automatically login to ServerB. For illustration purpose, ServerB can be a repo server and you don’t want to keep being asked for password everytime you want to commit files.

1. At ServerA issue:

This will create a public + private key for ServerA.

2. Enter (empty) for passphrase

3. Copy over the newly created public key from ServerA to ServerB:

Note that once the file arrives at ServerB, it named as id_ed25519.pub.ServerA (not id_ed25519.pub), and it will be stored at ronald’s home directory at ServerB.

4. Ssh to ServerB, and issue this command:

ServerA public key will be merged/appended to ServerB authorized_keys file.

This way everytime you want to access ServerB from ServerA, you won’t be asked for a password. 🎉

The basic command for creating a symbolic link (a “symlink” or “soft link”) to a folder or file is ln -s:

The first argument is the target (what the link points at), the second is the link name (what gets created). I get this order backwards every time — the mnemonic that finally stuck is “ln -s is like cp: source first, destination second.”

To remove all symlinks in the current directory (and only symlinks — leaving regular files and directories untouched):

-type l is the filter that matches symlinks specifically. -maxdepth 1 keeps the search from descending into subdirectories, so you only kill the symlinks at the top level.

A few useful additions: symlinks have sharp edges.

Symlinks look simple — “a file that points to another file” — but they have a handful of behaviors that catch people out. The ones below are the ones I’ve actually been bitten by.

Symlinks vs. hard links. The -s in ln -s is the difference. Without it, you get a hard link: a second directory entry pointing to the same inode. Hard links don’t break if you move or rename the original (because both names refer to the same data). Symlinks store a path and break if the target moves. Hard links can’t span filesystems and can’t point to directories (the kernel forbids it to prevent loops); symlinks can do both.

Inspecting a symlink. A few different tools answer different questions:

readlink -f is the one I reach for most — it tells you where a symlink ultimately resolves, even through chains of symlinks-pointing-to-symlinks.

Relative vs. absolute targets. The path you pass as the target is stored verbatim. If you write a relative target, it’s resolved relative to the directory the link lives in, not the directory you ran the command from. This trips people up:

Rule of thumb: use absolute paths unless you specifically want the link to follow when both source and link move together (common pattern: shipping a relative symlink inside a tarball or git repo).

The rm -rf on a symlink-to-directory trap. This one is genuinely dangerous:

The trailing slash changes the command from “delete this symlink” to “delete what’s inside the directory the symlink points to.” If you’re in the habit of tab-completing paths, your shell often appends the slash for you. Be deliberate when removing symlinks to directories.

Updating an existing symlink. By default ln -s refuses to overwrite. The flags vary depending on what you’re replacing:

Forgetting -n on a directory symlink is one of those bugs that’s invisible until you wonder why your link “didn’t take” — and meanwhile a stray newtarget entry is hiding in the linked directory.

Finding broken symlinks. Symlinks happily survive their targets being deleted. To find ones that no longer point anywhere valid:

-xtype l means “the symlink’s target is not a real file/directory we can stat” — i.e. the link is dangling. Useful as a periodic sanity check after you’ve moved or removed a directory that other things might have linked to.

Finding what links to a given target. The reverse question — “is anything pointing at this file?” — has no fast answer; you have to scan:

The first form matches the symlink’s stored target string; the second works for hard links (same inode). There’s no equivalent of “give me everything that resolves to this path,” because resolving every symlink on the system would be expensive — you’d be running readlink -f on every link in the search tree.

Here are a few commands you can use to find out which Linux distribution you’re on — pick whichever your system has:

Of those, cat /etc/*-release is the most reliable on modern systems. The wildcard catches both /etc/os-release (the systemd-mandated standard, present on virtually all distros since around 2012) and any distro-specific files like /etc/redhat-release, /etc/lsb-release, or /etc/debian_version — so you don’t need to know in advance what the file is called.

If you only want a clean machine-readable answer and don’t care about the others, source /etc/os-release and read its variables directly:

A few useful additions: commands that work the same across distros.

One of the joys of Linux is that once you’ve learned the basics, the same commands work whether you’re on Ubuntu, Fedora, Arch, Alpine, or Amazon Linux. Here are some that show up in almost every troubleshooting session:

What kernel and architecture am I on?

How much memory and disk do I have?

What’s running and using resources?

Who am I, where am I, what’s the time?

Networking basics. The classic ifconfig and netstat are deprecated in favor of ip and ss, which ship with iproute2 and are present on every modern distro:

Which desktop am I running? If you ssh into a graphical box and aren’t sure whether it’s GNOME, KDE Plasma, XFCE, Cinnamon, or something else, two environment variables will tell you:

Both are set by the display manager when you log in graphically; they’re empty if you’re on a headless box or in a plain ssh shell that didn’t inherit them. If they come back empty but you know there’s a desktop running, this works too:

X11 or Wayland? Once you’ve got a desktop, the next question is which display server it’s drawing through. The simplest check is the session-type variable, set by systemd’s logind:

If that’s empty (again, common over plain ssh), use loginctl to ask the session manager directly:

And if you want to see whether the Wayland or X11 socket actually exists on the system:

Why this matters: some tools behave differently or don’t work at all under Wayland (screenshot utilities, screen sharing, global hotkey daemons, automation tools like xdotool). When something graphical “just doesn’t work” on a modern Linux desktop, “are you on Wayland?” is often the first question to ask.

Looking for files and text.

Permissions and ownership.

Service management. Systemd is the init system on virtually every mainstream distro now (Debian, Ubuntu, RHEL/Fedora, SUSE, Arch). The same systemctl commands work everywhere:

Alpine and a few minimalist distros use OpenRC instead (rc-service, rc-update) — worth knowing when you ssh into a small container.

Where the distros do diverge: package management. This is the one place you have to know which family you’re on:

If a script needs to work across families, the cleanest pattern is to detect $ID from /etc/os-release and dispatch:

That’s the foundation. Once you have these committed to muscle memory, ssh-ing into an unfamiliar Linux box stops being intimidating — the same handful of commands answer the same handful of questions everywhere.

Login to your Linux shell menu as root

At VIM, 1st comment out anonymous_enable by adding a # sign at the beginning of the line
# anonymous_enable=YES
2nd remove comment at local enable by removing the # sign
local_enable=YES

Tail is a very useful tool for monitoring an error stream. Sometimes the output from tail can have too much information, and its black-and-white monotone output can be hard to follow with the eyes.

The basic: a Linux terminal has the capability to colorize text. For example:

will produce a simple text saying, well:

Sample text nicely highlighted

But with some terminal color tagging such as:

The \e above is identical to \033. I’d suggest using \033 because it’s safer in a programming language such as PHP. PHP will not recognize \e, but it will recognize \033, as you’ll see below.

Sample text nicely highlighted

Some basic coloring tables can be seen at bashguru.com:

With the help of perl, which most likely comes with all Linux distros, here’s a way to colorize your tail output. Let’s assume that every time you log something you will have a date-time prefixing your log. For example:

Let’s create a script that can colorize the date portion. Create an executable Linux bash file:

Then copy and paste the following into your empty logwatch.sh:

Voilà!

[22-Dec-2011 20:28:45] E_DATASOMETHING ……
Too much information …….
Too much information …….
[22-Dec-2011 20:28:46] E_FATAL Something
Too much information …….
Too much information …….
Too much information …….

If you need something more complex — say you want to highlight several words in the file — you can use the scripting power of PHP. (I’m rusty with my perl.) Save the script below as colorize.php, and you can have the words blah, na, wa, and — highlighted on the fly:

A few useful additions.

The simpler path: grep –color. If you only need to highlight a single pattern, you don’t need perl or PHP at all — grep can do it, and the –color=always flag forces color even through a pipe (where grep otherwise drops it because stdout isn’t a terminal):

The trailing .* is the trick that makes this work as a highlighter rather than a filter — it matches every line, so nothing gets dropped, but the alternation patterns still get colored where they appear. The -E flag enables extended regex.

The line-buffering gotcha. When you chain tail -f through several filters, each program in the pipeline buffers its output by default. The result: nothing appears on screen for several seconds, then a wall of lines all at once — useless for live monitoring. Force line-buffering on each stage:

–line-buffered is the GNU grep flag; -u is the equivalent for sed; for awk, use fflush() after each print. If you don’t see live output through your pipeline, this is almost always why.

Purpose-built tools. If colorizing logs is something you do often, two tools save you from rolling your own:

• ccze — pipe a log into it (tail -f /var/log/syslog | ccze -A) and it auto-colorizes by recognizing common log formats (syslog, Apache, Squid, etc.). The -A flag emits ANSI for piping; without it, ccze prefers its own curses-based UI.
• multitail — like tail -f but with split panes for watching multiple files at once, plus per-pattern highlighting via a config file. Heavier but powerful when you’re staring at three log files at the same time.

Both are in the standard repos for Debian/Ubuntu/Fedora — apt install ccze multitail or equivalent.

Two reset bookkeeping notes. If your colored output starts “leaking” — i.e. text after a match keeps showing up colored — your reset escape (\e[0m) didn’t fire. Common causes: a trailing newline got stripped before the reset, or you forgot the reset entirely. Always pair \e[Xm with \e[0m. And if you ever end up in a terminal stuck in some weird color state, the command reset (or tput reset) puts everything back to defaults.