Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).
Indeed, even writing this utility in C is trivial and has 0 extra dependency for a pure C/C++ project. Avoiding #embed also removes the dependency to a C++23 capable compiler, which might not be available in uncommon scenarios.
Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.
> it's safe to rely on
Is there any guarantee they won't break backwards compatibility again?
I wrote this almost ten years ago and it still works fine: https://github.com/jcalvinowens/diveutils/blob/master/consta...
Arguably it could be a little C helper, but I wanted this particular piece of the project to be more accessible so I used a scripting language.
I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.
Perl is obsolete and was replaced by Python for all usages in practice.
Right... except for the use case I pointed out. That being that perl is available on virtually every unix like operating system, not just Linux, and python isn't.
Also, perl has other uses. Perl is much more competent at awk/sed/grep like tasks than python, and it can also be much faster. More people should be writing perl, imo. There's a ton of programs written in C that should just be perl.
> a unix-like system without perl
QNX was one. Don't know if they started to include it in newer versions than 6.5 though
-i output in C include file style.
Just write a Python script that does the whole thing.