Added dig checks for Cloudflare and Google DNS resolvers.
EditImproved output formatting with clearer headers and status markers.
EditModified script to conditionally show 'Common fixes' only on failures.
EditValidated script syntax and output behavior.
VerifyI want to modify /usr/local/bin/nextdns-doctor script to also check if dig works when using cloudflare or Google DNS as the resolver. This can help identify issues where nextdns is specifically unable to resolve domains. Let me know if this check is already covered.
Considering coding tasks
I need to respond since the user asked me to modify a script. I should check if that’s already covered. This seems more like a coding task rather than system design, which confuses me a little. There's a system design coach and developer available, but the user is focused on coding. I’ll need to inspect the file and use the tools, keeping in mind that the path might be outside the current working directory.
Inspecting permissions for checks
I need to determine if the current system is properly configured for checks. My tool runs directly to the local daemon instead of using Cloudflare or Google. It looks like the system resolver and curl aren't specific enough. Since upstream NextDNS only reaches via HTTPS, it seems there's no coverage. I should modify the script in /usr/local/bin, but I'm not sure if I need permissions or if using sudo will be necessary. Time to inspect permissions!
ls -l /usr/local/bin/nextdns-doctor && id -un && test -w /usr/local/bin/nextdns-doctor; echo writable=$?-rwxr-xr-x 1 kiran staff 9246 Apr 28 20:16 /usr/local/bin/nextdns-doctor kiran writable=0
Modifying DNS checks
I need to refine the design by adding a section for "Public DNS resolver sanity check." This should probably come after the direct queries to the daemon. I want to check with public resolvers like @1.1.1.1 and @8.8.8.8, since if local NextDNS fails while public succeeds, it points to a specific issue with NextDNS. If both fail, it might indicate a general DNS or UDP issue. I think it’s important to warn rather than fail if public DNS fails due to network blocking.
Adjusting resolver failure messages
I think I might need to warn users if the "public resolver failed," indicating that external DNS to public resolvers could be blocked or the network is down. It shouldn’t mean there’s a NextDNS failure. If NextDNS fails while public resolves successfully, I should mention that public resolvers are working, likely pointing to a NextDNS-specific issue. I need to modify our function to return a pass/fail status and consider adding a dig_domain global. I also need to account for IPv6 issues and enhance our dig functions accordingly.
Considering DNS record queries
I'm thinking about using www.google.com to check if it returns a CNAME or A record. Using +short could show both the CNAME and the IP address. Currently, my regex only matches if the first line contains an IP. It seems to work fine for google.com, but I should also consider using example.com to test further. I'm leaning towards sticking with google.com as my primary example since it’s reliable. I’ll need to ensure my regex can handle this properly.
Implementing DNS checks
I'm thinking about how to set up a simple public DNS resolver sanity check.
I'll define a function that runs a DIG command to check if servers like Cloudflare and Google can resolve the DNS for "google.com." I'll want to ensure that if the command works, I note it, but if it fails, I'll provide a warning. Adding checks for more servers like 1.0.0.1 and 8.8.4.4 might be helpful.
It’s important to keep track of successes and failures, so I can give useful diagnostic info later.
Handling variable settings
I need to be cautious with the set -u option for variables, as it can lead to errors if they're not set. I’m considering using local variables within functions. Also, arithmetic operations will be important.
When composing my output, I should keep in mind that it could be multi-line, especially since passing results might produce several IP addresses that create additional lines after a success message. I want to ensure everything remains tidy and clear!
Running script considerations
I need to run bash with the -n option. After that, maybe I can run the relevant section? I'm thinking the full script might not require root privileges, so it may just execute. I wonder if running bash -n first will help catch any issues before I proceed. It’s important to be careful here, so I'll take it step by step to make sure everything works smoothly!
bash -n /usr/local/bin/nextdns-doctor && echo syntax-oksyntax-ok
Testing network functionality
I think I need to run a test snippet for public access. Perhaps I could use a script, although that might take some time. I could run a command like dig @1.1.1.1... to check connectivity. It’s important to ensure that my environment has the dig tool available before proceeding. I’m just trying to cover all my bases here!
dig @1.1.1.1 google.com +time=3 +tries=1 +short | head -3; dig @8.8.8.8 google.com +time=3 +tries=1 +short | head -3142.251.43.78 142.250.207.78
sed -n '120,175p' /usr/local/bin/nextdns-doctor# ---------------------------------------------------------------------------
section "Direct queries to the daemon"
run_dig() {
local server="$1" label="$2"
local out
out=$(dig "@$server" google.com +time=3 +tries=1 +short 2>&1)
if [[ "$out" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ ]]; then
pass "dig @$server google.com → $out ($label)"
else
fail "dig @$server google.com failed: $(echo "$out" | tr '\n' ' ') ($label)"
fi
}
run_dig 127.0.0.1 "IPv4 loopback"
run_dig ::1 "IPv6 loopback"
# ---------------------------------------------------------------------------
section "Public DNS resolver sanity check"
public_dns_ok=0
run_public_dig() {
local server="$1" label="$2"
local out
out=$(dig "@$server" google.com +time=3 +tries=1 +short 2>&1)
if [[ "$out" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ ]]; then
pass "dig @$server google.com → $out ($label)"
public_dns_ok=$((public_dns_ok+1))
else
warn "dig @$server google.com failed: $(echo "$out" | tr '\n' ' ') ($label)"
fi
}
run_public_dig 1.1.1.1 "Cloudflare"
run_public_dig 8.8.8.8 "Google"
if (( public_dns_ok > 0 )); then
info "public DNS works; if loopback NextDNS dig failed above, the issue is likely NextDNS-specific"
else
warn "public DNS resolvers did not answer; this may be a broader network/firewall issue, not just NextDNS"
fi
# ---------------------------------------------------------------------------
section "System DNS configuration"
resolver1=$(scutil --dns 2>/dev/null | awk '/^resolver #1$/{flag=1;next} /^resolver #/{flag=0} flag && /nameserver\[/{print $NF}')
if [[ -z "$resolver1" ]]; then
warn "could not parse resolver #1 from scutil --dns"
else
info "resolver #1 nameservers:"
echo "$resolver1" | sed 's/^/ /'
if echo "$resolver1" | grep -qE '^(127\.0\.0\.1|::1)$'; then
pass "system DNS points at the local nextdns daemon"
else
warn "system DNS does NOT point at 127.0.0.1 — apps will bypass nextdns. Run 'sudo nextdns activate' (or reinstall with -auto-activate)."
fi
fiConsidering DNS details
I’m thinking about delivering a concise answer while checking if I've covered everything directly. Maybe I should add tests and mention the public failures to avoid repeating mistakes. There's a concern about multi-line output in the pass. I might need to improve by including the IPv6 DNS addresses like 2606:4700:4700::1111 and 2001:4860:4860::8888, since the user referred to Cloudflare and Google DNS. I want to ensure clarity without overcomplicating it!
Done.
This check was not already covered directly. The script had:
dig @127.0.0.1 and dig @::1 — checks NextDNS local daemondscacheutilBut it did not test public DNS resolvers like Cloudflare or Google directly.
I added a new section:
It now checks:
Behavior:
PASS if public DNS worksWARN if public DNS fails, since some networks intentionally block external DNSI also ran:
and syntax is OK.
can you also make the ouput look cleaner
Improving script output
I think we need to modify the script for a cleaner output, since the user wants that. It seems like we might be focusing more on code modification rather than system design. I'll consider whether we can simply clean the existing output. It looks like the multi-line outputs from dig IPs might be causing formatting issues, so summarizing the first line could help. Maybe I can implement functions for indentation and formatting to keep things minimal and organized.
Refining output format
I need to make my output cleaner by defining status with symbols, possibly keeping "PASS." I'd like to avoid newlines and aim for indented helpers. There’s the idea of changing the pass/fail/warn formatting with glyphs, but I need to keep it simple without overdoing it. For terminals, using fixed width like "✓ PASS" seems good, and for non-terminals, glyphs might be fine too. I might implement helper functions for clarity and detail.
can you also make the ouput look cleaner
resume
Improving output formatting
I need to think about how to make my outputs cleaner and more organized. So, it’s time to modify them further. I’ve already adjusted some functions, but I think I need to refine them even more by using indents and a single line for summaries. I'll also need to check the file to see what else might need inspecting. Let's keep moving forward with this!
bash -n /usr/local/bin/nextdns-doctor && echo syntax-oksyntax-ok
/usr/local/bin/nextdns-doctorNextDNS doctor
host: Kirans-MacBook-Pro
time: Wed Apr 29 13:01:50 IST 2026
! NOTE not running as root and sudo unavailable without a password; some checks will be skipped
▸ Binary & install
✓ PASS nextdns binary on PATH (/opt/homebrew/bin/nextdns)
version: nextdns version 1.47.2
✓ PASS LaunchDaemon plist present at /Library/LaunchDaemons/nextdns.plist
▸ Daemon process & service
✓ PASS nextdns process is running
36209 /opt/homebrew/bin/nextdns run
skipped 'sudo launchctl list' (need root)
✓ PASS control socket /var/run/nextdns.sock exists
skipped 'sudo nextdns status' (need root)
▸ Port 53 listeners
! WARN port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verify
▸ Direct queries to the daemon
✓ PASS NextDNS IPv4 loopback (127.0.0.1) resolves google.com → 142.251.210.142
✓ PASS NextDNS IPv6 loopback (::1) resolves google.com → 142.251.210.142
▸ Public DNS resolver sanity check
✓ PASS Cloudflare DNS (1.1.1.1) resolves google.com → 142.251.223.14
✓ PASS Google DNS (8.8.8.8) resolves google.com → 142.250.207.78
public DNS works; if loopback NextDNS dig failed above, the issue is likely NextDNS-specific
▸ System DNS configuration
resolver #1 nameservers: 127.0.0.1 127.0.0.1
✓ PASS system DNS points at the local nextdns daemon
Wi-Fi DNS override: 127.0.0.1
▸ System resolver path (what apps actually use)
✓ PASS system resolver resolves www.google.com → 216.239.38.120
▸ End-to-end HTTPS
✓ PASS HTTPS to www.google.com works → code=200 ip=2001:4860:4802:32::78 t=0.620894s
▸ Upstream NextDNS reachability
✓ PASS NextDNS upstream reachable via dns.nextdns.io → 400 t=0.215911s
✓ PASS NextDNS upstream reachable via 45.90.28.0 → 400 t=0.132613s
✓ PASS NextDNS upstream reachable via 45.90.30.0 → 400 t=1.189558s
▸ Configured profile & key settings
discovery-dns
cache-size 0
listen localhost:53
profile 59aefc
auto-activate true
hardened-privacy false
report-client-info true
▸ Recent daemon logs (last 5 min)
2026-04-29 12:59:42.228445+0530 0x7bbcf Activity 0x135e48 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.228713+0530 0x792a1 Activity 0x135e4b 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.228713+0530 0x7bbc9 Activity 0x135e4c 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.228852+0530 0x7bbd1 Activity 0x135e4d 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.228914+0530 0x7bbcd Activity 0x135e4e 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.236300+0530 0x7bbd2 Activity 0x135e4f 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.243423+0530 0x7bbde Activity 0x135ea0 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.243435+0530 0x7bbd7 Activity 0x135ea1 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.243914+0530 0x7bbd8 Activity 0x135ea2 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.420110+0530 0x7bbde Activity 0x135ea3 36209 0 nextdns: (Security) SecTrustEvaluateIfNecessary
2026-04-29 12:59:42.486819+0530 0x7bbcd Info 0x0 36209 0 nextdns: Connected 139.84.131.131:443 (con=41ms tls=162ms, TCP, TLS13)
2026-04-29 12:59:42.486822+0530 0x7bbcd Info 0x0 36209 0 nextdns: Connected 139.84.131.131:443 (con=41ms tls=162ms, TCP, TLS13)
▸ Summary
✓ 14 pass ! 1 warn ✗ 0 fail
Warnings:
- port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verify
Common fixes (run manually as needed):
# Recover from a broken activation (system DNS stuck on 127.0.0.1 with no daemon)
sudo networksetup -setdnsservers Wi-Fi empty
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Clean reinstall of the launchd service
sudo nextdns deactivate; sudo nextdns stop; sudo nextdns uninstall
sudo nextdns install -profile <profile-id> -report-client-info -auto-activate
# Run in foreground with verbose logs (best for debugging)
sudo nextdns stop
sudo nextdns run -debug
# in another terminal: dig @127.0.0.1 google.com
# Force activation if auto-activate didn't redirect system DNS
sudo nextdns activateImproving log output
I’m thinking about how to make the logs cleaner, particularly by possibly hiding the Security SecTrust details. Using --style compact might help format the mac log output more efficiently because the current lines are pretty huge. Filtering with grep -v 'SecTrustEvaluateIfNecessary' could help, too, so that I’d be left with just the last eight non-SecTrust lines. If there are no relevant lines left, I might say there aren’t any. The user asked for clearer output, so I need to make this happen!
Improving log formatting
I’m looking to improve the most recent logs. I can use a command to get logs from the last five minutes with the compact style while filtering out irrelevant entries. The grep command returns a nonzero exit code but shouldn’t be a problem here.
To keep things cleaner, I’m thinking about using awk to format the log output, particularly by extracting information after "nextdns:". However, I might need to retain the timestamps for clarity. I also notice some duplicates in the configuration. So, I'll tidy up both the logs and the config!
bash -n /usr/local/bin/nextdns-doctor && /usr/local/bin/nextdns-doctor | sed -n '1,220p'NextDNS doctor
host: Kirans-MacBook-Pro
time: Wed Apr 29 13:02:14 IST 2026
! NOTE not running as root and sudo unavailable without a password; some checks will be skipped
▸ Binary & install
✓ PASS nextdns binary on PATH (/opt/homebrew/bin/nextdns)
version: nextdns version 1.47.2
✓ PASS LaunchDaemon plist present at /Library/LaunchDaemons/nextdns.plist
▸ Daemon process & service
✓ PASS nextdns process is running
36209 /opt/homebrew/bin/nextdns run
skipped 'sudo launchctl list' (need root)
✓ PASS control socket /var/run/nextdns.sock exists
skipped 'sudo nextdns status' (need root)
▸ Port 53 listeners
! WARN port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verify
▸ Direct queries to the daemon
✓ PASS NextDNS IPv4 loopback (127.0.0.1) resolves google.com → 142.251.210.142
✓ PASS NextDNS IPv6 loopback (::1) resolves google.com → 142.251.210.142
▸ Public DNS resolver sanity check
✓ PASS Cloudflare DNS (1.1.1.1) resolves google.com → 142.251.223.14
✓ PASS Google DNS (8.8.8.8) resolves google.com → 142.250.207.78
public DNS works; if loopback NextDNS dig failed above, the issue is likely NextDNS-specific
▸ System DNS configuration
resolver #1 nameservers: 127.0.0.1 127.0.0.1
✓ PASS system DNS points at the local nextdns daemon
Wi-Fi DNS override: 127.0.0.1
▸ System resolver path (what apps actually use)
✓ PASS system resolver resolves www.google.com → 216.239.38.120
▸ End-to-end HTTPS
✓ PASS HTTPS to www.google.com works → code=200 ip=2001:4860:4802:32::78 t=0.487589s
▸ Upstream NextDNS reachability
✓ PASS NextDNS upstream reachable via dns.nextdns.io → 400 t=0.177928s
✓ PASS NextDNS upstream reachable via 45.90.28.0 → 400 t=0.124560s
✓ PASS NextDNS upstream reachable via 45.90.30.0 → 400 t=0.879006s
▸ Configured profile & key settings
listen: localhost:53
profile: 59aefc
cache-size: 0
auto-activate: true
report-client-info: true
hardened-privacy: false
discovery-dns: (empty)
▸ Recent daemon logs (last 5 min)
2026-04-29 12:59:37.960 I nextdns[36209:792a1] Query 127.0.0.1:50418 UDP/53 127.0.0.1 AAAA gspe1-ssl.ls.apple.com. 59aefc (qry=40/res=40) 855ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6180:100:d0::89f:9001]:443: read: connection reset by peer
2026-04-29 12:59:37.960 I nextdns[36209:792a1] Query 127.0.0.1:50418 UDP/53 127.0.0.1 AAAA gspe1-ssl.ls.apple.com. 59aefc (qry=40/res=40) 855ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6180:100:d0::89f:9001]:443: read: connection reset by peer
2026-04-29 12:59:37.960 I nextdns[36209:792a1] Query 127.0.0.1:58552 UDP/53 127.0.0.1 A msgstore-001.www.notion.so. 59aefc (qry=44/res=44) 1944ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6180:100:d0::89f:9001]:443: read: connection reset by peer
2026-04-29 12:59:37.960 I nextdns[36209:792a1] Query 127.0.0.1:58552 UDP/53 127.0.0.1 A msgstore-001.www.notion.so. 59aefc (qry=44/res=44) 1944ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6180:100:d0::89f:9001]:443: read: connection reset by peer
2026-04-29 12:59:39.538 I nextdns[36209:79277] Network change detected: awdl0 up
2026-04-29 12:59:39.538 I nextdns[36209:79277] Network change detected: awdl0 up
2026-04-29 12:59:42.486 I nextdns[36209:7bbcd] Connected 139.84.131.131:443 (con=41ms tls=162ms, TCP, TLS13)
2026-04-29 12:59:42.486 I nextdns[36209:7bbcd] Connected 139.84.131.131:443 (con=41ms tls=162ms, TCP, TLS13)
▸ Summary
✓ 14 pass ! 1 warn ✗ 0 fail
Warnings:
- port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verify
Common fixes (run manually as needed):
# Recover from a broken activation (system DNS stuck on 127.0.0.1 with no daemon)
sudo networksetup -setdnsservers Wi-Fi empty
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Clean reinstall of the launchd service
sudo nextdns deactivate; sudo nextdns stop; sudo nextdns uninstall
sudo nextdns install -profile <profile-id> -report-client-info -auto-activate
# Run in foreground with verbose logs (best for debugging)
sudo nextdns stop
sudo nextdns run -debug
# in another terminal: dig @127.0.0.1 google.com
# Force activation if auto-activate didn't redirect system DNS
sudo nextdns activatebash -n /usr/local/bin/nextdns-doctor && /usr/local/bin/nextdns-doctor | sed -n '/Recent daemon logs/,$p'▸ Recent daemon logs (last 5 min)
Query 127.0.0.1:55005 UDP/53 127.0.0.1 65 gspe1-ssl.ls.apple.com. 59aefc (qry=40/res=40) 854ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6180:...
Query 127.0.0.1:62038 UDP/53 127.0.0.1 AAAA api.apple-cloudkit.com. 59aefc (qry=40/res=40) 1402ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:61...
Query 127.0.0.1:50418 UDP/53 127.0.0.1 AAAA gspe1-ssl.ls.apple.com. 59aefc (qry=40/res=40) 855ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:618...
Query 127.0.0.1:58552 UDP/53 127.0.0.1 A msgstore-001.www.notion.so. 59aefc (qry=44/res=44) 1944ms : doh resolve: read tcp [2403:a080:c0a:99bf:c001:4d06:2614:691]:60425->[2400:6...
Network change detected: awdl0 up
Connected 139.84.131.131:443 (con=41ms tls=162ms, TCP, TLS13)
▸ Summary
✓ 14 pass ! 1 warn ✗ 0 fail
Warnings:
- port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verify
Common fixes (run manually as needed):
# Recover from a broken activation (system DNS stuck on 127.0.0.1 with no daemon)
sudo networksetup -setdnsservers Wi-Fi empty
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Clean reinstall of the launchd service
sudo nextdns deactivate; sudo nextdns stop; sudo nextdns uninstall
sudo nextdns install -profile <profile-id> -report-client-info -auto-activate
# Run in foreground with verbose logs (best for debugging)
sudo nextdns stop
sudo nextdns run -debug
# in another terminal: dig @127.0.0.1 google.com
# Force activation if auto-activate didn't redirect system DNS
sudo nextdns activateEvaluating output formatting
I’m looking into an issue with using one_line "$resolver1" since one_line uses printf "%s" without a newline, which might affect how tr handles it. That's good to note! I also noticed that when using paste -sd ', ' -, it separates two IPs with a comma but no space, which isn't critical but something to think about. I could replace that with awk, but it seems okay. Just need to ensure I've covered everything already.
Done. I cleaned up the output formatting in /usr/local/bin/nextdns-doctor.
Changes include:
▸ Section name✓ PASS, ! WARN, ✗ FAILdig output — shows one IP plus (+N more) instead of dumping all answersI also ran:
and executed the script to verify the output looks good.
Only show the common fixes section if something has failed
Modifying the script
I see that I need to modify the script. It seems pretty straightforward, but I’ll want to make sure I use the right tools for the job. Getting this done correctly is important, especially if adjustments need to be made or if it could impact something else down the line. I’ll keep my focus on what tools might be necessary to complete this script modification smoothly and effectively!
bash -n /usr/local/bin/nextdns-doctor && /usr/local/bin/nextdns-doctor | tail -30Wi-Fi DNS override: 127.0.0.1
▸ System resolver path (what apps actually use)
✓ PASS system resolver resolves www.google.com → 216.239.38.120
▸ End-to-end HTTPS
✓ PASS HTTPS to www.google.com works → code=200 ip=2001:4860:4802:32::78 t=0.552275s
▸ Upstream NextDNS reachability
✓ PASS NextDNS upstream reachable via dns.nextdns.io → 400 t=0.226681s
✓ PASS NextDNS upstream reachable via 45.90.28.0 → 400 t=0.132508s
✓ PASS NextDNS upstream reachable via 45.90.30.0 → 400 t=0.870493s
▸ Configured profile & key settings
auto-activate: true
discovery-dns: (empty)
hardened-privacy: false
cache-size: 0
listen: localhost:53
profile: 59aefc
report-client-info: true
▸ Recent daemon logs (last 5 min)
Timestamp Ty Process[PID:TID]
▸ Summary
✓ 14 pass ! 1 warn ✗ 0 fail
Warnings:
- port 53 listener invisible without sudo (lsof can't see root processes); re-run with sudo to verifyFixing log issues
I'm looking at some recent daemon logs, and it turns out they only show the header due to cleanliness issues with the output. The user didn’t specifically ask about this, but I can see there’s a problem with the output tail. I could quickly fix it by filtering out lines that start with "Timestamp" using grep. I'll also check for any common fixes if needed, since there might be current warnings without fixes.
bash -n /usr/local/bin/nextdns-doctor && echo syntax-oksyntax-ok
Done.
Common fixes now only prints when FAIL > 0.
I also removed a stray Timestamp... log header from the recent logs output while validating the script.
Syntax check passes: