On Wed, 23 Mar 2016, Ralf Friedl wrote: > > On the other hand, I don't know why busybox sed needs exactly one space > between command and filename. GNU sed works with zero or more spaces.
Good points, everyone. Thanks. Still... # Note, the input file /tmp/bar lacks the <newline> on the last line # simplified GNU sed ignores open failure on not specified/not existing file: $ strace sed 'r' /tmp/bar open("/tmp/bar", O_RDONLY|O_LARGEFILE) = 3 read(3, "foo\nbar\nbaz", 4096) = 11 write(1, "foo\n", 4foo ) = 4 open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(1, "bar\n", 4bar ) = 4 open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) read(3, "", 4096) = 0 write(1, "baz\n", 4baz ) = 4 open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) read(3, "", 4096) = 0 close(3) = 0 busybox sed reports an error: $ strace busybox sed 'r' /tmp/bar write(2, "sed: empty filename\n", 20sed: empty filename ) = 20 Arguably, this may look like a bug in GNU sed, or intentional behaviour? # Let's do a more reasonable test. $ sed -n '1,$p' /tmp/bar | cat -E foo$ bar$ baz ^ Note the missing <newline> char on the last line. $ busybox sed -n '1,$p' /tmp/bar | cat -E foo$ bar$ baz$ ^ There's a <newline> char on the last line. Which is at fault here? I would say both (with reservations). But obviously, non-determinism. $ f=/tmp/bar && cat $f && [ -z "$(tail -c1 $f)" ] || echo and: $ f=/tmp/bar && cat $f && tail -c1 $f | read __ || echo work, but they look more convoluted to me. Cheers, -- Cristian _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox