On Mon, Jan 20, 2025 at 02:27:15PM +0000, Celeste wrote: > With this patch, i encountered issues building LVM2 manpages. > > Specifically, the regex from line 201 of > https://gitlab.com/lvmteam/lvm2/-/blob/v2_03_30/man/Makefile.in#L201 > (`s+[\][[]\(<\{0,1\}\)\\\-+\\\[\1-+g`) causes "sed: unmatched '+'". > > I tried that with GNU sed, and it did not give me this error. >
Thanks for the report! It's because if we found the square doesn't mean a special sequence in state BRACKET_IN_BRACKET_EXPR, we should process the next character as normal (reset state to IN_BRACKET_EXPR and have another try) instead of skipping it, or the second right square bracket in your case, which marks end of the bracket expression, will be omitted. I've finished v3 with this issue fixed and will post here when it has been tested well. Thanks, Yao Zi > On Thursday, 14 Nov 2024 at 11:10, Yao Zi <ziyao at disroot.org> wrote: > > > As specified in POSIX standard[1], delimiters in bracket expression > > should not terminate the regex and always have their original meaning, > > hus 's/[\/]//' matches either '\' or '/' and 's/[[:alpha:]/]//' matches > > any alphabet or '/'. But with busybox sed, > > > > $ echo a | sed 's/[[:alpha:]/]/b/' > > sed: bad option in substitution expression > > $ echo '\/' | sed 's/[\/]//' > > \ > > > > This commit implements a state machine to determine whether a character > > is in a bracket expression, in order to parse escape sequence and > > command delimiters correctly, following the specification and other > > implementation's behavior (GNU and NetBSD). Corresponding test is added > > as well. > _______________________________________________ > busybox mailing list > [email protected] > https://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
