Windows troubleshooting:
- Works on my system, therefore it's not an issue.
- Must be a hardware error.
- Obviously it's just cheap hardware.
- Have you tried turning it off and on again?
- Here's some obscure error code that leads nowhere.
- Have you tried "sfc /scannow"?
AS IF SFC IS A FUCKING SILVER BULLET!!!
- Our Indian support chap from answers.microsoft.com will help you.

RRRREEEEEEEEEEEEE!!!!!!!
Solution: quietly weep and reinstall your system.

Linux troubleshooting:
- There are good quality log files.
- You can run the program from the command-line and read both stdout and stderr from it.
- You can usually run the program with high verbosity options to help you track down the error.
- Even daemons can have their commands spawned from a dedicated shell, to see why they failed.
- Usually it's a configuration error and you can easily edit the configuration file.
- More often than not, the program will tell you why it failed.

Solution: usually easy to find.

I fucking love Windows. Because you know, it's so easy to troubleshoot and the support is so great!!!

Forget about coffee, nothing wake you up faster than a colleague mentioning your name in the slack channel where the stderr of the app writes.

What features would you want in a logger?

Here's what I'm planning so far:
- Tagged entries for easy scanning of log file
- Support for indenting to group similar sequential entries
- Multiple entry types (normal, info, event, warning, error, fatal, debug, verbose)
- Meta entries, so the logger logging about itself, e.g. disk i/o failures.
- Ability to add custom entry types, including tag, log-level, etc.
- Customizable timestamp function
- Support for JS's async nature -- this equates to passing a unique key per 'thread'; the logger will re-write all the parent blocks for context, if necessary. if that sounds confusing, it's okay; just trust that it makes sense.
- Caching, retries, etc. in the event of disk i/o issues.
- Support for custom writers, allowing you to e.g. write logs to an API rather than console or disk.

How about these features?
- Multiple (named) logs with separate writers (console, disk, etc.)
- Ability to individually enable/disable writing of specific entry types. (want verbose but not info? sure thing, weirdo!)
- Multiple writers per log. Combined with the above, this would allow you to write specific entry types (e.g. error, warning, fatal) to stderr instead of stdout, or to different apis.
- Ability to write the same log entry to multiple logs simultaneously

What do you think of these features?
What other features would you want?
I'm open to suggestions!

My company decided to reinvent the wheel by writing its own queue system instead of using the existing message queue service.

And it uses plain PHP with exec() to run the workers.

Where do we store the job? We use mongoDB which is already used in our existing projects. We can query the collection/table each time the queue service start, execute the jobs, and let it exit if there's no job anymore. Don't worry, systemd will start the queue service again once it exits.

How to monitor the workers? Yep, we use ps and grep to check if the worker's PID still exists in the OS.

What about error stack traces? Nice question, we redirect the stdout and stderr when exec()-ing into a file.

What about timeout? We don't need it, let's just assume no one is going to write while(true).

It works flawlessly! /s

Studied linux src/man.c today.
fprintf (stderr, "gimme gimme gimme\n");

Feelin' good.

Me: Ugh. I always forget to change my Slack status before leaving my computer. I wish it would just update when I locked my computer. And maybe cleared the status/set me back to active when I unlocked my computer.
*realization that I’m a programmer now*

——
A week later:
... it throws a nilError exception on every running of the Automator action to the stderr file it’s configured with, but it does what I programmed it to do. What? Why? What have I done?

Every once in a while, I find myself having to redirect both stdout and stderr to a file (or to stdout) in bash. Every time I have to Google it.

I just learned the hard way not to recklessly daemonize stuff; I ran into a case where my Python script crashes Python itself.

The issue was that one of the query that “requests” package makes for OS was not fork safe, thus causing a segfault. Since Python drops dead as soon as it receives SIGSEGV, all I had was macOS crash log (which is oftentimes hard to decipher). I spent like good one hour before I found “faulthandler” package which enabled me to log the stack trace to stderr and see what the f*<k was going on.

I mean, I’ve seen quite a lot of occurrences of thread safety issues, but now it’s fork safety!?

Maybe I should be sticking to Docker or something unless the situation *really* requires me to daemonize something lol

Dumb question time!
I'm writing a bash script that outputs some progress info to stdout (stuff like "Doing this... ok", "Doing that... ok") before outputing a list of names (to stdout too).

I'd like to be able to pipe this list of names to a second script for processing, by doing a simple :
~$ script1 | script2

Unfortunately, as you may have guessed, the progress info is piped as well, and is not displayed on the screen.
Is it considered a bad practice to redirect that progress info to stderr so it is not sent into the pipe ?

Is there any "design pattern" for this kind of usecase, where you want to be able to choose what to display and what to pipe to a program that accepts input from stdin ?

How bash does not support redirecting stderr to /dev/null when using read redirection inside command substitution is F*CKING ANNOYING.
x=$(</foo/non_exitence_file.txt 2>/dev/null)

Why do people still use this shit of a shell?

Wrapping applications is PITA. It would be cool and all, but the app outputs debug(ish) messages into stderr, which just makes me write more spaghetti :'(