Seriously! According to the time command in fish, cldr (my program) takes around 4-5 ms to print files, tldr takes 80-100ms. (PS, on my server, cldr actually takes less than 1 ms to fetch the file, while tldr takes closer to 150 ms. That’s 150 times faster!!!)
This started a couple days ago when a friend of mine alerted me to the fact that the official tldr repo now takes ai contributions for their pages (aka the cheat sheet files that are printed) and for the actual program code. She then showed me a repo called ethical-tldr which does not allow for the use of ai contributions in the pages or program code.
However, their even though their client doesn’t allow vibe coding, it is still written in Python, which itself takes ai contributions.
So, I decided to learn C from scratch and make my own tldr client that’s faster and better than theirs in *every way! Introducing cldr! I am especially proud of the list and search functionality because the interface is just gorgeous.
Note, ABSOLUTELY NO AI was used in the making of this, I learned and wrote everything on my own in just the past 3 days, I don’t think I even copied much or any code from websites.
*There’s still like two things I haven’t implemented that the official client does, but they’re very minor and I’d be willing to bet that 99% of you won’t know the difference.
This looks like a colossally bad idea:
if (!strcmp(platform, "windows") && !isSpecificPlatform) { debugLog("Falling back to rm -rf", 2); debugLog(strfmt("rm -rf exited with code %d",system(strfmt("rm -rf %s", path))), 3); }In addition,
Per the Makefile, this project is built using GCC. GCC itself accepts AI contributions, provided that the code is “legally insignificant” (meaning less than around 15 lines of code) or is part of test cases: https://gcc.gnu.org/ai-policy.html
For the first part: You’re probably right! I’m not sure of a safer way to do it though. This specific part is an artifact of the original method I used, which I don’t think would have worked on windows (according to some stack overflow post), but the current code might actually work fine, I just don’t have access to anything running windows and would rather not set up a VM.
Second: That’s highly disappointing! I think their policy is fairly well thought out, in a way that allows for accountability and auditability, so I might be okay with continuing to use it, I’ll have to think about it. If you know of an alternative I could use, I will happily take suggestions!
To add to the last comment, I’d also suggest not mixing logging and business code. That is to say that you should put the
systemcall on its own line, so that it is clear that it’s not just a logging call:if (!strcmp(platform, "windows") && !isSpecificPlatform) { debugLog("Falling back to rm -rf", 2); int result = system(strfmt("rm -rf %s", path)); debugLog(strfmt("rm -rf exited with code %d", result), 3); }It may just be a me problem, but I have a tendency to skim over the logging lines unless I’m intentionally reading code carefully, in which case the system call may get overlooked
You can call
rmsafer manner, but you’ll need to fork and use one of theexeclfunctions directly. That way you don’t have to worry about escaping the path. The old implement would potentially delete unrelated data if the path contained whitespace, and could even execute arbitrary commands, since it essentially runsbash -c "rm -rf $path"Those are really good points! I’ve been sanitizing other inputs for shell breakage, but never considered checking this. Either way, I have since removed the rm -rf part of the code, instead opting to only use my “good” method of traversing the directory
Update to my comment: I changed it up a little bit to remove that bit of code. You can optionally uncomment part of the code to re-enable it, in case the current implementation doesn’t work on windows