Preserve empty lines in generated shell scripts

[usa-]

Problem

Currently, general/scripts/strip-shell-comments.awk removes empty lines from shell scripts when building the nightly firmware.

This makes the generated scripts harder to read and understand, especially for someone who needs to inspect the script and understand its structure or behaviour. Preserving empty lines would make the scripts more readable for humans while, based on the measurements in [Issue #2386](#2386), having little or no practical impact on the firmware image size.

This was originally discussed in [Issue #2386](#2386). Based on my initial estimate, preserving empty lines should have only a negligible effect on firmware size.

The change in this PR is intentionally limited to preserving blank lines while continuing to strip comments.

Hardware tested on

None.

I have not tested this change on a camera, and I do not have enough experience with the firmware build and validation process to perform the relevant hardware and image-size checks myself.

Evidence

The measurements and validation below were performed by @widgetii and are documented in [Issue #2386](#2386).

Preserving blank lines added 514 bytes across 45 shipped shell scripts.

For hi3518ev300_lite, rebuilding the root filesystem both ways produced:

as shipped (blank lines stripped): 5,226,496 B
blank lines preserved:             5,226,496 B
delta:                                     0 B

@widgetii also ran all 151 shipped scripts through the modified stripper under BusyBox ash -n with 0 parse failures.

The two boards closest to their image-size limits, hi3519v101_lite and hi3518ev300_lite, had not both been measured both ways at the time of that comment, so I cannot provide independent before/after measurements for them.

Implementation

The change is a single-line modification to general/scripts/strip-shell-comments.awk:

-	if (/^[ \t]*$/) next
+	if (/^[ \t]*$/) { print; next }

It is important to explicitly print the empty line. Simply removing the original check would not work because the later if (code ~ /^[ \t]*$/) next also catches blank lines (code_of("") returns "").

Scope

I have not independently completed the repository validation checklist below. I am relying on the testing and measurements documented by @widgetii in Issue #2386.

• No kernel patches under general/package/all-patches/linux/ (those go to https://github.com/OpenIPC/linux)
• No files specific to a single retail camera model (those go to https://github.com/OpenIPC/builder)
• No probing or bring-up tooling (that goes to https://github.com/OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

I would really appreciate your help with testing this PR. I don't have the experience or hardware needed to perform the relevant build and firmware validation myself, so please help verify that preserving empty lines does not cause any issues and that the resulting firmware images remain within their size limits.

[openipc-ai]

The size question is answered: this fits every board, with margin. I measured it rather than extrapolating from the issue.

Per image

Per image the change adds +895 B uncompressed on hi3516ev300_lite (76 shipped scripts) and +932 B on gk7205v200_lite (82). The 514 B / 45 scripts figure in the body undercounts — it leaves out the majestic-webui cgi-bin/j/*.cgi and sbin/* scripts, which ship and are comment-stripped too. I attributed all 76/82 files to a source: three come from buildroot's own tree, and four needed replaying git history until the old stripper's output matched the built file byte for byte.

Re-squashing both trees with buildroot's own mksquashfs -noappend -b 128K -comp xz gives +420 B and +216 B compressed.

On flash

Because the image is padded to 4096 B, each board moves by 0 or exactly 4 KB. Both outcomes occur: on my hi3516ev300_lite repack the control had 3854 B of pad slack and the image did not move; on gk7205v200_lite it had 182 B and the image went 5044 KB -> 5048 KB. So the zero result in #2386 is real, but it is not general.

It can be predicted per board without rebuilding anything, by reading bytes_used out of the shipped squashfs superblock (unsigned 64-bit LE at offset 40) — spare pad bytes are (-bytes_used) mod 4096. From the 2026-09-19 nightly images:

board	headroom	pad slack	effect
hi3516cv6xx_lite	32 KB	1784 B	+0
hi3516ev300_neo	36 KB	3658 B	+0
hi3516ev300_lite	44 KB	2606 B	+0
gk7205v200_lite	52 KB	3250 B	+0
gk7205v300_lite	52 KB	3158 B	+0
gk7605v100_lite	56 KB	438 B	0 or +4 KB
hi3518ev300_lite	56 KB	1030 B	+0
gm8135_lite	60 KB	714 B	+0
gm8136_lite	60 KB	682 B	+0

Every one of those absorbs the growth except gk7605v100_lite, which is marginal and has 56 KB free either way.

That also closes the open question left in #2386. hi3519v101_lite, sitting at exactly 5120 KB of its 5120 KB cap in that nightly, had 1094 B of pad slack — it would not have tipped. It is at 188 KB free now, after #2459 moved five hisilicon boards back down (ev100 -> 128 KB, dv200 -> 336 KB, hi3518ev100 -> 208 KB, ev200_lite -> 68 KB).

The tightest board today is hi3516cv6xx_lite at 32 KB, so the worst case anywhere leaves 28 KB. NAND is safe by a wider margin: the minimum UBI headroom is 384 KB (hi3516ev300_ultimate, 16000/16384 KB), three whole 128 KB PEBs.

Checks

STRICT=1 .github/scripts/test_strip_shell_comments.sh passes with the patch — 146 shipped scripts parse identically under busybox ash, and the saving goes from 210383 B to 207922 B, so 2461 B is given back across the whole tree. test_sysupgrade.sh and test_check_mac.sh also pass against the newly stripped forms.

Before merge

Two small things, inline. After those, please mark this ready for review — a draft builds nothing, and this path widens the matrix to all 100 boards, which is exactly the evidence the issue asked for.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Preserve blank lines in generated shell scripts

✨ Enhancement 🧪 Tests 🕐 Less than 10 minutes

AI Description

• Preserve blank lines while stripping whole-line comments during firmware builds.
• Add regression coverage ensuring generated scripts retain paragraph breaks.

Diagram

graph TD
  A["Rootfs build"] --> B["AWK stripper"] --> C{"Blank line?"}
  C -- "No" --> E{"Comment only?"} -- "No" --> D["Generated script"]
  C -- "Yes" --> D
  E -- "Yes" --> F["Dropped line"]
  G["Regression test"] --> B

Loading

High-Level Assessment

The explicit early print-and-next branch is the narrowest correct approach. Merely removing the existing blank-line check would fail because the later comment-only filter also matches an empty result; handling blanks first preserves readability without changing comment, heredoc, quote, or continuation behavior.

Files changed (2) +11 / -2

Enhancement (1) +3 / -2

strip-shell-comments.awkPreserve blank lines during comment stripping +3/-2

Preserve blank lines during comment stripping

• Prints empty and whitespace-only records before applying comment-only filtering, preserving script paragraph breaks. Header documentation now clarifies that only whole-line comments are removed.

general/scripts/strip-shell-comments.awk

Tests (1) +8 / -0

test_strip_shell_comments.shAdd blank-line preservation regression coverage +8/-0

Add blank-line preservation regression coverage

• Adds a fixture containing a paragraph-separating blank line and verifies the stripped output retains all four lines. This prevents future changes from silently removing blank lines again.

.github/scripts/test_strip_shell_comments.sh

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Firmware changes lack camera validation evidence 📘 Rule violation ☼ Reliability

Description

The updated comment stripper changes the contents of shell scripts shipped in firmware, but the PR
reports no hardware testing and leaves its validation checklist unchecked. Because the change
reaches generated camera scripts, the missing affected-board output and boot or runtime evidence
applies to every firmware image using this build path.

Code

general/scripts/strip-shell-comments.awk[R107-108]

-	if (/^[ \t]*$/) next
+	if (/^[ \t]*$/) { print; next }

Evidence

The changed AWK rule preserves blank lines in generated shell scripts, which alters files shipped in
firmware. The hardware-evidence rule requires affected-board evidence for changes that can alter
camera behavior and treats an explicit statement of no hardware testing or unchecked verification as
a failure.

Rule 3: Hardware evidence is present and honest
general/scripts/strip-shell-comments.awk[107-108]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The comment stripper changes files included in camera firmware, but the PR provides no real-camera validation and leaves the relevant verification items unchecked.
## Fix Focus Areas
- general/scripts/strip-shell-comments.awk[107-108]
## Recommended Fix
Run the applicable firmware validation on affected boards, including before-and-after image-size measurements and a boot or runtime check, then document the board names, observed symptoms, and command output in the PR. If hardware access remains unavailable, provide the strongest permitted non-hardware evidence while explicitly retaining the limitation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[openipc-ai]

Both findings addressed, and the evidence is in.

The header now says what the pass actually does, and the new fixture is a real guard rather than a restatement — it fails against the previous stripper (FAIL a blank line was dropped), so the behaviour cannot be reverted silently.

The full 100-board matrix is green on this head, which settles the size question the issue opened with: every image this path reaches built under its cap, including hi3516cv6xx_lite (32 KB headroom, the tightest board in the tree), hi3516ev300_neo (36 KB), and gk7605v100_lite, the one board whose spare pad was small enough for the change to plausibly cost it a 4 KB block. That also closes the open question left on #2386: hi3519v101_lite and hi3518ev300_lite both build clean.

Thanks for picking this up and for turning the review round so quickly.