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
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,
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
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
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 identified
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 comment
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) code
ff --git sh.h sh.h
index 93beef31d46..652a1f6dd06 100644
--- 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, /* bracke
output 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
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 exam
ename 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]:
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.
evaluated 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ö
13 matches
Mail list logo
