|
From: | Assaf Gordon |
Subject: | Re: Why isn't "sed -n p" identical to "cat"? |
Date: | Sat, 19 Jan 2019 14:34:11 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 2019-01-09 3:40 p.m., Assaf Gordon wrote: [...]
If this is deemed a bug, it is easily fixed with this patch: diff --git a/sed/execute.c b/sed/execute.c index 76bba4f..a97a9d1 100644 --- a/sed/execute.c +++ b/sed/execute.c@@ -1653,6 +1653,7 @@ process_files (struct vector *the_program, char **argv)line_init (&line, NULL, INITIAL_BUFFER_SIZE); line_init (&hold, NULL, 0); + hold.chomped = false; line_init (&buffer, NULL, 0); input.reset_at_next_file = true; With a note: "pattern.chomped" should start as TRUE, as some test depends on it - so i'm not changing the default in 'line_init'.
Prompted by https://bugs.gnu.org/34133 , I noticed that the above change does affect existing behavior: $ printf "%s\n" b | sed-4.7 'G;H' | od -tc 0000000 b \n \n 0000003 $ printf "%s\n" b | ./sed/sed-with-hold-chomped 'G;H' | od -tc 0000000 b \n 0000002 All other implementations output two "\n\n" (like GNU sed currently does), so this is another reason to keep the code as-is. regards, - assaf
[Prev in Thread] | Current Thread | [Next in Thread] |