On 2026-03-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:
Anyone know of a port?
It only supports FreeBSD, Linux, Mac (old style capitalization) and
Windows out of the box:
How far do you get when trying to build from source ?
Any luck trying to make the build process think VMS is some form of Unix ?
On 3/24/2026 2:15 PM, Simon Clubley wrote:
On 2026-03-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:
Anyone know of a port?
It only supports FreeBSD, Linux, Mac (old style capitalization) and
Windows out of the box:
How far do you get when trying to build from source ?
Any luck trying to make the build process think VMS is some form of
Unix ?
I started by asking. If someone had already done the work,
then no need for me.
The code is not big.
https://github.com/jline/jline3/tree/master/native/src/main/native
I guess it will end up in how *nix compatible VMS is.
It is obvious from the code that the Windows version was a lot
of work.
On 3/24/26 1:29 PM, Arne Vajh|+j wrote:
The code is not big.
https://github.com/jline/jline3/tree/master/native/src/main/native
I guess it will end up in how *nix compatible VMS is.
It is obvious from the code that the Windows version was a lot
of work.
$ help crtl tcsetattr
doesn't find anything.-a Some of the terminal stuff (isatty, ttynam) is available but probably not everything you need.
On 3/24/2026 2:15 PM, Simon Clubley wrote:
On 2026-03-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:
Anyone know of a port?
It only supports FreeBSD, Linux, Mac (old style capitalization) and
Windows out of the box:
How far do you get when trying to build from source ?
Any luck trying to make the build process think VMS is some form of Unix ?
I started by asking. If someone had already done the work,
then no need for me.
The code is not big.
https://github.com/jline/jline3/tree/master/native/src/main/native
I guess it will end up in how *nix compatible VMS is.
It is obvious from the code that the Windows version was a lot
of work.
In article <69c2d812$0$677$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/24/2026 2:15 PM, Simon Clubley wrote:
On 2026-03-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:I started by asking. If someone had already done the work,
Anyone know of a port?
It only supports FreeBSD, Linux, Mac (old style capitalization) and
Windows out of the box:
How far do you get when trying to build from source ?
Any luck trying to make the build process think VMS is some form of Unix ? >>
then no need for me.
The code is not big.
https://github.com/jline/jline3/tree/master/native/src/main/native
I guess it will end up in how *nix compatible VMS is.
It is obvious from the code that the Windows version was a lot
of work.
It looks like that's pretty deeply intertwined with the POSIX
termios interfaces.
What, exactly, are you trying to do?
It would be nice to be able to run them on VMS.
On 3/24/2026 9:46 PM, Dan Cross wrote:
In article <69c2d812$0$677$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/24/2026 2:15 PM, Simon Clubley wrote:
On 2026-03-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:I started by asking. If someone had already done the work,
Anyone know of a port?
It only supports FreeBSD, Linux, Mac (old style capitalization) and
Windows out of the box:
How far do you get when trying to build from source ?
Any luck trying to make the build process think VMS is some form of Unix ? >>>
then no need for me.
The code is not big.
https://github.com/jline/jline3/tree/master/native/src/main/native
I guess it will end up in how *nix compatible VMS is.
It is obvious from the code that the Windows version was a lot
of work.
It looks like that's pretty deeply intertwined with the POSIX
termios interfaces.
What, exactly, are you trying to do?
There are several Java applications that use JLine.
It would be nice to be able to run them on VMS.
Not all of those applications need JLine for
basic functionality, but still nice to have.
This is all JLine 3.x - if I remember correctly then
JLine 2.x tries to run external stty utility, which does
not work on VMS either.
On Tue, 24 Mar 2026 22:07:46 -0400, Arne Vajh|+j wrote:
It would be nice to be able to run them on VMS.
It would be nice to have lots of things. But the code doesnrCOt write
itself.
In article <10pvg1j$1g49c$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/24/2026 9:46 PM, Dan Cross wrote:
It looks like that's pretty deeply intertwined with the POSIX
termios interfaces.
What, exactly, are you trying to do?
There are several Java applications that use JLine.
It would be nice to be able to run them on VMS.
Not all of those applications need JLine for
basic functionality, but still nice to have.
Looking at the documentation, this seems to be a mashup of what
curses and GNU Readline provide on Unix-like systems. Curses
works on VMS, but JLine seems to want to reach into the
pseudo-terminal system and do everything itself. Reading
between the lines, it probably creates PTY master/slave pairs
behind the scenes, using JNI.
...$
...
CTRL/Z
So if you'd like this to work on OpenVMS, you'll have to provide
either some sort of compatibility shim that looks like POSIX
termios, or reimplement those bits using native OpenVMS
primtives.
What I'd probably do is dig into the curses (or perhaps ncurses)
port and see what they do to bridge that gap, and then modify
JLine's JNI components similarly.
On 3/25/2026 6:54 AM, Dan Cross wrote:
In article <10pvg1j$1g49c$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/24/2026 9:46 PM, Dan Cross wrote:
It looks like that's pretty deeply intertwined with the POSIX
termios interfaces.
What, exactly, are you trying to do?
There are several Java applications that use JLine.
It would be nice to be able to run them on VMS.
Not all of those applications need JLine for
basic functionality, but still nice to have.
Looking at the documentation, this seems to be a mashup of what
curses and GNU Readline provide on Unix-like systems. Curses
works on VMS, but JLine seems to want to reach into the
pseudo-terminal system and do everything itself. Reading
between the lines, it probably creates PTY master/slave pairs
behind the scenes, using JNI.
It is commonly used in cases where a tool needs to work
in 3 ways:
$ foobar whatever.db
$
and:
$ foobar -c "..."
$
and:
$ foobar
...$
...
CTRL/Z
and the last needs some enhanced capabilities.
So if you'd like this to work on OpenVMS, you'll have to provide
either some sort of compatibility shim that looks like POSIX
termios, or reimplement those bits using native OpenVMS
primtives.
What I'd probably do is dig into the curses (or perhaps ncurses)
port and see what they do to bridge that gap, and then modify
JLine's JNI components similarly.
Maybe.
But my order of preference if I were to start on this would be:
1) SYS$QIOW (QIO is not bad for terminal IO)
2) SMG$ (haven't used it for 30 years but it is pretty solid)
3) curses/ncurses (back in the days the VMS curses had a very bad
reputation, but maybe the Bill P ncurses is OK)
There are several Java applications that use JLine.
It would be nice to be able to run them on VMS.
Not all of those applications need JLine for
basic functionality, but still nice to have.
On 3/24/2026 10:07 PM, Arne Vajh|+j wrote:
There are several Java applications that use JLine.
It would be nice to be able to run them on VMS.
Not all of those applications need JLine for
basic functionality, but still nice to have.
Note that:
$ java -Dorg.jline.terminal.type=dumb -
Dorg.jline.terminal.provider=jansi ...
allows JLine to run on VMS.
Which can be practical in case of something useful
having a dependency on JLine.
JLine is of course totally superfluous with that
as it makes a JLine LineReader work just like a
standard BufferedReader.
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
aa
bb
cc
history1: a
Exit$ type x3.hst
history1: a
!1a
!2b
!3c
!41: a
Exit$ type x3.hst
On 3/25/2026 8:40 PM, Arne Vajhoj wrote:
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
And it is really working.
In a sort of 1970ish way.
On 2026-03-27, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/25/2026 8:40 PM, Arne Vajh|+j wrote:
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
And it is really working.
In a sort of 1970ish way.
What happens when you enter a line longer than the terminal width and
then try editing it ?
I would expect you to be able to edit the line until you move left to
the line boundary.
On 3/27/2026 2:18 PM, Simon Clubley wrote:
On 2026-03-27, Arne Vajhoj <arne@vajhoej.dk> wrote:
On 3/25/2026 8:40 PM, Arne Vajhoj wrote:
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
And it is really working.
In a sort of 1970ish way.
What happens when you enter a line longer than the terminal width and
then try editing it ?
I would expect you to be able to edit the line until you move left to
the line boundary.
That does not work well.
But isn't that as expected??
On 2026-03-27, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/27/2026 2:18 PM, Simon Clubley wrote:
On 2026-03-27, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/25/2026 8:40 PM, Arne Vajh|+j wrote:
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
And it is really working.
In a sort of 1970ish way.
What happens when you enter a line longer than the terminal width and
then try editing it ?
I would expect you to be able to edit the line until you move left to
the line boundary.
That does not work well.
But isn't that as expected??
Yes. I have not looked at the code, so I was wondering if JLine had done something clever, but when you say direct terminal interface, it looks
like you really do mean direct terminal interface. :-)
On 3/27/2026 2:54 PM, Simon Clubley wrote:
On 2026-03-27, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/27/2026 2:18 PM, Simon Clubley wrote:
On 2026-03-27, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 3/25/2026 8:40 PM, Arne Vajh|+j wrote:
One arrow up recall provided by terminal driver
instead of the many (docs say default is 500,
but I have not tested) provided by JLine
with the right terminal interface.
And it is really working.
In a sort of 1970ish way.
What happens when you enter a line longer than the terminal width and
then try editing it ?
I would expect you to be able to edit the line until you move left to
the line boundary.
That does not work well.
But isn't that as expected??
Yes. I have not looked at the code, so I was wondering if JLine had done
something clever, but when you say direct terminal interface, it looks
like you really do mean direct terminal interface. :-)
With -Dorg.jline.terminal.type=dumb -Dorg.jline.terminal.provider=jansi
it seems like JLine end up calling standard Java IO, which end up
calling SYS$GET, which we know have some limitations.
I would expect full edit capability if JLine got the native
pieces for VMS. I tested on Windows and no problem editing
a wrapped line.
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is code implementing such a history file for any existing program which uses the
:-)
It is just that with !n instead of up arrow it is not
particular useful.
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is code implementing such a history file for any existing program which uses the
:-)
It is just that with !n instead of up arrow it is not
particular useful.
SMG recall buffer (Debugger, SDA, CMS, ...).
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
On 3/28/26 22:33, Arne Vajh|+j wrote:
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
Yes and no: the recall buffer size is unchanged.
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
cont := true;
while cont do begin
On 3/28/2026 6:25 PM, hb0815 wrote:The size is unchanged. It is set by the application. If the application
On 3/28/26 22:33, Arne Vajh|+j wrote:
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
Yes and no: the recall buffer size is unchanged.
The default 20 is probably good enough.
On 3/28/2026 5:33 PM, Arne Vajh|+j wrote:
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
Could not resist the opportunity to write a demo in Pascal.
...
On 3/29/26 03:27, Arne Vajh|+j wrote:
On 3/28/2026 5:33 PM, Arne Vajh|+j wrote:
On 3/28/2026 4:39 PM, hb0815 wrote:
On 3/27/26 20:14, Arne Vajh|+j wrote:
But history file works fine on VMS as demoed.When finding the latest voit kit you probably noticed that there is
:-)
It is just that with !n instead of up arrow it is not
particular useful.
code implementing such a history file for any existing program which
uses the SMG recall buffer (Debugger, SDA, CMS, ...).
SMG$REPLACE_INPUT_LINE with SMG$M_KEEP_CONTENTS to load
and SMG$RETURN_INPUT_LINE to save?
And setting recall buffer size in SMG$CREATE_VIRTUAL_KEYBOARD?
Could not resist the opportunity to write a demo in Pascal.
...
OK, a demo of how to use SMG to write to and read from a history file
within a program. It does not help with all the existing programs that
have not implemented it. In other words, can your code enable history
files for the Debugger, SDA, CMS, ...?
On Sat, 28 Mar 2026 21:27:59 -0400, Arne Vajh|+j wrote:
cont := true;
while cont do begin
I hate that.
On 3/28/2026 11:19 PM, Lawrence DrCOOliveiro wrote:
On Sat, 28 Mar 2026 21:27:59 -0400, Arne Vajh|+j wrote:
cont := true;
while cont do begin
I hate that.
It is a common pattern or at least was a common pattern.
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
On 3/28/2026 11:19 PM, Lawrence DrCOOliveiro wrote:
On Sat, 28 Mar 2026 21:27:59 -0400, Arne Vajh|+j wrote:
cont := true;
while cont do begin
I hate that.
It is a common pattern or at least was a common pattern.
In languages that don't have repeat loops. Do the test at the end instead
of the beginning.
And most prefer while over repeat until, because
using while instead of repeat until is safe
but using repeat until instead of while is
not safe.
https://www.linkedin.com/posts/sdalbera_geekhumor-becauseitsfriday- activity-7438097776862986241-Tmj0/
The modern way is worse in my opinion because it actively
misleads the reader:
while true // continue forever
...
if ... then
break // ha - I fooled you - we are not continuing forever
end if
...
end while
The best way is a construct that signals exit in the middle
(as in Modula-2 and TPU):
loop // continue until done
In other words, can your code enable history files for the Debugger,
SDA, CMS, ...?
On 3/29/2026 3:51 PM, Arne Vajh|+j wrote:
And most prefer while over repeat until, because
using while instead of repeat until is safe
but using repeat until instead of while is
not safe.
https://www.linkedin.com/posts/sdalbera_geekhumor-becauseitsfriday-
activity-7438097776862986241-Tmj0/
Once upon a time it was said that a bottom test was
faster than a top test.
Supposedly the reason that many Fortran 66 implementations
had minimum of one iteration for DO loops.
DO 100 I=START,END
...
100 CONTINUE
START=1 and END=1:
Fortran 66 => 1 iteration
Fortran 77 => 1 iteration
START=1 and END=0:
Fortran 66 => 0 or 1 iteration
Fortran 77 => 0 iteration
And I guess it was true.
movl #1,r1
100$: cmpl r1,#N
bgtr 200$:
...
incl r1
brb 100$
200$:
vs:
movl #1,r1
100$: ...
incl r1
cmpl r1,#N
bleq 100$
But doesn't matter any more today.
...
I thought you were talking about the ability to change the source code
to use a history file.
You are talking about a clever hack to change the EXE to use a history
file?
But if you can add it to DCL, then I think Simon is interested. It
was one of the DCL enhancements he requested a few months ago.
Repeat until (do while in more modern languages) is not better
when the test needs to be in the middle.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 03:53:13 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
727 files (7,886M bytes) |
| Messages: | 264,528 |