Looks like this is a Windows CRLF line ending issue. Could you check whether this is coming from your editor or your Git settings? @gabrielbudke

One quick way to fix it:

sudo apt install dos2unix
dos2unix your_program.sh

Let me know how it goes!

Could you try running file your_program.sh and bash your_program.sh and share the output as well?

Also, could you share the output of running pwd and ls as well?

I’ve tried to run it locally following the README.md file and some other answers in this forum, but i cannot run without problem.

Here are my logs:

➜ ./your_program.sh 
bash: ./your_program.sh: cannot execute: required file not found

Here’s a link to my repo:

gabrielbudke/codecrafters-claude-code-python: Build your own Claude Code

Feel free to fix the same issue in the other tester repos, and just tag me to merge them. Looks like it affects three other repos.

The default Ruby version has been updated across all supported challenges.

Previously running on v3.4, we’ve now upgraded to v4.0.

To use the latest version, be sure to update the buildpack version in your repo as well.

The default Rust version has been updated across all supported challenges.

Previously running on v1.94, we’ve now upgraded to v1.95.

To use the latest version, be sure to update the buildpack version in your repo as well.

I was reading the source code for the DNS tester and noticed a naming collision.

It looks like a bit of copy-paste debt from the grep challenge, the go.mod for the DNS tester is currently identifying itself as the grep-tester dns-server-tester/go.mod at e491a49873be71b5810e0e67525d16d6b3e1a5e1 · codecrafters-io/dns-server-tester · GitHub

This also flows into the internal imports and the Makefile.

I’ve raised a PR to tidy this up so it correctly identifies as dns-server-tester, which should help avoid naming collisions .

PR Link: chore: fix incorrect module naming and internal paths by dhotrey · Pull Request #36 · codecrafters-io/dns-server-tester · GitHub

Also, I noticed that in the Makefiles for most of the testers, the copy_course_file directive points to /repo/build-your-own-<x>/contents/course-definition.yml, but in practice, in most repos, it has been moved to the root: /repo/build-your-own-<x>/course-definition.yml.

example from http-server-tester :

copy_course_file:
	hub api \
		repos/codecrafters-io/build-your-own-http-server/contents/course-definition.yml \
		| jq -r .content \
		| base64 -d \
		> internal/test_helpers/course_definition.yml

If you guys give me the go-ahead, I don’t mind fixing and raising a PR for this pattern across the other testers as well!

I’ve tried running the same commands from multiple clients connected locally, and everything is fine

Here are my logs:

[tester::#FY6] [client-1] ✔︎ Received ["OK", 23, 1, "1"]
[tester::#FY6] [client-2] $ redis-cli GET banana
[tester::#FY6] [client-2] Sent bytes: "*2\r\n$3\r\nGET\r\n$6\r\nbanana\r\n"
[tester::#FY6] [client-2] Received bytes: "$-1\r\n"
[tester::#FY6] [client-2] Received RESP null bulk string: "$-1\r\n"
[tester::#FY6] Expected bulk string, found null bulk string ($-1\r\n)
[tester::#FY6] Test failed
[tester::#FY6] Terminating program
[your_program] key: banana | client_data:  {}
[your_program] DEBUGGG !!!! 
[tester::#FY6] Program terminated successfully

And here’s a snippet of my code:

There might be a few things going on here, but two issues stand out:

1. This condition seems unnecessary. You can simplify this by just going through the else branch and assigning the full data:

partitionToFetch.TopicFetchResponse.Records = data.

2. The reversal logic here also looks unnecessary, since extracting the lower 7 bits is already correct:

I’ve extended your membership by two weeks so you can have a bit more time to experiment. Let me know how it goes!

The OCaml track now includes the Build your own Git challenge.

Ready to put your OCaml skills to the test? Jump into the OCaml track, and let us know how it goes!

andy1li:

brew remove codecrafters

Yes, this worked. Thank you. @andy1li

brew remove codecrafters

Then reinstall using the instructions on the setup page and try again. Let me know if this still doesn’t work.

push changes: run git command: fatal: unable to access ‘https://git.codecrafters.io/769d7af23164b99c/’: gnutls_handshake() failed: The TLS connection was non-properly terminated.
. Error: exit status 128

trying this command listed in setup.

``curl -fsSL ``https://codecrafters.io/install.sh`` | bashcodecrafters ping``

Still not working.

Could you give it another try and let me know how it goes? @fly-434

#PZ7 comes before the functions portion of the challenge so the tests won’t cover this case. The second example I gave, checking that a function is equal to itself, is also not tested for as far as I know.

I guess the case of checking for self-initialization of globals was deferred until we had working scopes and a resolver, since we would have to revisit the self-initialization problem anyway?

Since you’ve finished the Resolving and Binding extension, does Stage #de8 (Identifier Resolution) cover the problematic case you’ve encountered?

Let me know if you’re still running into any issues.

Let us know if anything else looks off!

The default Kotlin version has been updated across all supported challenges!

Previously running on v2.2, we’ve now upgraded to v2.3.

To use the latest version, be sure to update the buildpack version in your repo as well.

fun foo() {}
print foo == foo;

Thus the AST nodes representing foo must hold an Rc to the same data, and cloning that data during node creation would be an error (returns false for the above test instead of true).

print clock();
fun clock() {
  return 0;
}
print clock();

I think that we need to allow clock to be shadowed by the new definition. This means that the root program environment needs to be populated with our builtins, rather than using a separate lookup table (which would prevent shadowing). I had made this mistake previously, however there doesn’t seem to be a test for it.

There might also be a test to see whether the “evaluate” function from before can also handle builtins, not just “run”.

We’re investigating it now and will share an update as soon as we have a fix

On the tester side, we run everything inside a temporary working directory (“workspace”), so any file writes are isolated and won’t overwrite anything.

Suggestion: Try running your program from a separate temporary folder as well. That should help avoid unintended overwrites.

The ExternalCommandHandler is placed before CdCommandHandler. This causes cd to be picked up as an external command instead of your builtin.

On many systems, there’s an external binary with the same name as shell builtins (e.g. /usr/bin/cd). But running that won’t change your Java process’s working directory, it only affects the subprocess, which exits immediately.

Adding a 1 second sleep before outputting the job number/pid didn’t help.

From my shell:

$ sleep 15 &
[1] 50410

From bash:

ps -o pid,ppid,cmd -p 50410
PID PPID CMD
50410 50348 sleep 15

$ ps -o pid,ppid,cmd -p 50348
PID PPID CMD
50348 1484 python3 app/main.py

Even using pstree, I don’t see anything anomalous (apart from some zombie processes I need to reap):

      |-tmux: server(1483)-+-bash(1484)---python3(50348)-+-sleep(50350)
      |                    |                             |-sleep(50410)
      |                    |                             `-sleep(50631)

I don’t know what else to try. Can I find somewhere the code that checks for the presence of the child process or is it closed source?

I also tried commenting out enable_raw_mode(), but the issue still persists.

Suggestions:

1. Use our CLI to test against previous stages by running:

codecrafters test --previous

2. Focus on fixing the early stages first, as later stages depend on them.

Give that a try and let me know if it works!

I also tried your testing code above but for some reason my mac didn’t catch and print the redundant characters so I didn’t notice it.