| Summary: | Bug in sed addressing (<addr>,+N) | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | vit.lapka |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.30.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
Patch that seems to fix the issue
Busybox config file |
||
Created attachment 8041 [details]
Busybox config file
Fixed in git, thanks! |
Created attachment 8036 [details] Patch that seems to fix the issue Hello, it seems I have found a bug in busybox implementation of sed utility (version 1.29.3, also in 1.30.1). When using row addressing in sed command in format <addr1>,+N (i.e. apply to N rows following the match of <addr1>), it seems that following rows are processed only for the first match. For following matches, only the first row (matching <addr1>) is processed. Example: - test file: AAA BBB1 CCC CCC AAA BBB2 AAA BBB3 - command: sed -n '/AAA/,+1 p' file - expected result (GNU sed): AAA BBB1 AAA BBB2 AAA BBB3 - busybox sed: AAA BBB1 AAA AAA I have just quickly inspected the code and it seems that index of the last line for multiline match is overwritten with computed value relative to the first match and not reset/recomputed for further matches. I created a patch that seems to fix the issue, however I am not entirely confident it is a correct and clean solution. With regards, Vit Lapka