incorrectly.
These additional compatibility issues are unrelated to the issue fixed
by the proposed patch. Is there a general interest in improving the
POSIX compatibility of OpenBSD ed? If so, what would need to be done in
order to get the proposed patch committed?
Greetings,
Sören
Sören Tempel
PING.
I think this is a fairly obvious POSIX compliance issue with an easy fix.
Sören Tempel wrote:
> Hello,
>
> Currently, the OpenBSD ed implementation incorrectly writes information
> to standard error that should be written to standard out (as per POSIX).
>
> For
Hello,
Currently, the OpenBSD ed implementation incorrectly writes information
to standard error that should be written to standard out (as per POSIX).
For the read and write command the POSIX standard states the following:
If the command is successful, the number of bytes written shall
the
`recur` variable to `sawseparator` or something along those lines.
Greetings,
Sören
Sören Tempel wrote:
> Hello,
>
> The POSIX specification of ed(1) includes a table in the rationale
> section which (among others) mandates the following address handling
> rules [1]:
>
Hello,
The POSIX specification of ed(1) includes a table in the rationale
section which (among others) mandates the following address handling
rules [1]:
Address Addr1 Addr2
,, $ $
;; $ $
Unfortunately, OpenBSD does not correctly handle these two
t streams
before executing the command using system(3). Alternatively, it may also
be sufficient to only flush stdout and (maybe) stderr.
This issue was originally discovered in GNU ed where it has been fixed
since. See: https://lists.gnu.org/archive/html/bug-ed/2021-12/msg0.html
Greetings,
Sör
44
--- sh.h
+++ sh.h
@@ -134,6 +134,9 @@ extern const struct option sh_options[];
enum sh_flag {
FEXPORT = 0,/* -a: export all */
FBRACEEXPAND, /* enable {} globbing */
+#ifdef EMACS
+ FBBRACKETPASTE, /* bracketed paste mode */
+#endif
FBGNICE,/* bgnice */
Ingo Schwarze wrote:
> It would, and in principle, that would be an improvement.
> But i think editline(3) code quality is insufficent for use in a
> shell. It's all quite messy and hastily and sloppily written.
> I tried to polish some of it in the past, but got distracted,
> so editline(3)
Ingo Schwarze wrote:
> Hi,
Hello,
> Which problem needs fixing:
> Of the four-byte UTF-8 sequences, only a subset is identified by the
> existing code. The other four-byte UTF-8 sequences still get chopped
> up resulting in individual bytes being passed on.
>
>
> I'm also adding a few
Ping.
Sören Tempel wrote:
> Hello,
>
> Currently, ksh does not correctly calculate the length of 4 byte UTF-8
> sequences in emacs input mode. For demonstration purposes try inputting
> an emoji (e.g. U+1F421) at your shell prompt. These 4 byte sequences can
> be iden
Hello,
Currently, ksh does not correctly calculate the length of 4 byte UTF-8
sequences in emacs input mode. For demonstration purposes try inputting
an emoji (e.g. U+1F421) at your shell prompt. These 4 byte sequences can
be identified by checking if the first four bits are set and the fifth
bit
Hello,
The diff below adds support for bracketed paste mode to ksh. Bracketed
paste mode is a set of special escape sequences, which are employed by
many terminal emulators to allow programs run inside of them to
distinguish pasted text from typed-in text [0]. This is useful for
preventing pasted
Hi all,
I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh,
rshd, rwho, rwhod, etc have been removed (at least according to the
Changelog). However, the upgrade instructions fail to mention that files
like /etc/rc.d/rwhod or /usr/bin/rwho should be removed.
Sören.
13 matches
Mail list logo
