On 2015-05-09 18:38, [email protected] wrote:
> Invoking "ed -s file.txt", where file does not contain a newline at the
> end, sends to stderr in spite of -s flag: "newline appended". Is this
> normal behaviour?
Definitely normal behaviour. If it is *correct* behaviour is another,
philosophical, matter. :-)
Looking at the source code, the flag suppresses various messages going
to both stdout and stderr, and I can't make out any particular idea
behind which are affected and which are not. Maybe a look at the Posix
definition would shed some light, but I doubt it.
Note that -s also suppresses a few error checks, like for example if the
operator tries to edit a new file while having unsaved changes in the
current edit buffer.
Out of curiosity I logged on to a 27 year old computer that I have
access to which is still running(!), in production(!!), in its original
incarnation(!!!). It is a System V.3 compatible system with part vendor
specific code (kernel, some utilities), part original AT&T SVR3 code
(most of the toolkit).
This is what a blast from the past looks like:
----8<--------8<--------8<--------8<--------8<---- (cut)
diabas$ ed -?
ed: illegal option -- ?
usage: ed [- | -s] [-p string] [-x] [-C] [file]
diabas$ ls -l /bin/ed
-r-xr-xr-x 2 bin bin 43760 Apr 10 1992 /bin/ed
diabas$ file /bin/ed
/bin/ed: mc68k object (3.x) pure executable
diabas$ echo "test\c" >/tmp/tst.txt
diabas$ cat /tmp/tst.txt
testdiabas$
diabas$ ed -s /tmp/tst.txt
'\n' appended
q
diabas$ ed /tmp/tst.txt
'\n' appended
5
q
diabas$
----8<--------8<--------8<--------8<--------8<---- (cut)
Note the subtle difference between the two invokations: the file size
output is suppressed when using '-s'. I'm not sure I'd call that a
"diagnostic" (which is what the man page says '-s' suppresses) any more
than the "'\n' appended" message, but /bin/ed in various variants has
definitely exhibited the same behaviour for 20+ years.
I generally redirect stdout to /dev/null when I use /bin/ed in scripts,
that just seems prudent anyway.
> Does ed/sed spoil files with non ascii bytes (for example unicode characters)?
> By experience seems to me that they, as also lex, do not spoil the files,
> that one can edit them, but I do not know to what extent, if there is a risk.
If by "non ascii bytes" you mean 8-bit characters, OpenBSD's /bin/ed is
(supposed to be) 8-bit safe. But is not unicode aware, so whether you
can successfully edit a unicode file (interactively) probably depends
primarily on your terminal emulator. You will run into uncharted
territory though, as for example character counts will be wrong.
8-bit files in general works fine; I routinely use /bin/ed to edit ISO
8859-1 encoded files with no problems. Whether it can deal meaningfully
with control characters in the 0-31 or 128-159 range I don't know.
And I believe the above goes for sed as well.
Regards,
/Benny
--
internetlabbet.se / work: +46 8 551 124 80 / "Words must
Benny Lofgren / mobile: +46 70 718 11 90 / be weighed,
/ fax: +46 8 551 124 89 / not counted."
/ email: benny -at- internetlabbet.se
