I know next to nothing about terminals. My .profile says TERM=xterm.

$ echo $TERM
xterm

I really am running PuTTY on Windows and logging in to a FreeBSD system.

When I invoke ``rlwrap sbcl'', I get a little bug:

--8<-------------------------------------------------------->8---
$ rlwrap sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (f(format t "hello~%")
hello
NIL
--8<-------------------------------------------------------->8---

Of course, I typed

(format t "hello~%")

but we end up seeing

(f(format t "hello~%")

If I type

(write-string "hello")

we end up with

* (w(write-string "hello")
hello
"hello"

You get the idea. This doesn't happen with other programs. It seems to
be something specific to sbcl, though I could hardly believe that sbcl
is guilty of anything here.

Any remedies?

On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:

> $ echo $TERM
> xterm

Same here.

> I really am running PuTTY on Windows and logging in to a FreeBSD system.

I am running KDE Konsole on Linux to access a local shell.

> Of course, I typed
>
> (format t "hello~%")
>
> but we end up seeing
>
> (f(format t "hello~%")

My terminal window shows:

* (format t "hello~%")
hello
NIL

> If I type
>
> (write-string "hello")
>
> we end up with
>
> * (w(write-string "hello")
> hello
> "hello"

My terminal window shows:

* (write-string "hello")
hello
"hello"

Most likely suspect: Windows is the weakest link.

On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>
>> $ echo $TERM
>> xterm
>
> Same here.
>
>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>
> I am running KDE Konsole on Linux to access a local shell.
>
>> Of course, I typed
>>
>> (format t "hello~%")
>>
>> but we end up seeing
>>
>> (f(format t "hello~%")
>
> My terminal window shows:
>
> * (format t "hello~%")
> hello
> NIL
>
>> If I type
>>
>> (write-string "hello")
>>
>> we end up with
>>
>> * (w(write-string "hello")
>> hello
>> "hello"
>
> My terminal window shows:
>
> * (write-string "hello")
> hello
> "hello"
>
> Most likely suspect: Windows is the weakest link.
>

This is the easiest thing I could wire up as a simulation
for those at home. Since I don't know a thing about LISP,
I can't very well address that part of the problem.

[Picture]

https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif

The $TERM declaration and the color capability,
don't exactly match in my copy of PuTTY. The distortion
seen by the OP does not look like wrongly emitted
color codes, which could make more of a mess.
PuTTY is not declaring "xterm-256color" as the term type.

[Picture]

https://i.postimg.cc/QMtZRXsc/putty-settings.gif

Paul

Paul <nospam@needed.invalid> writes:

> On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
>> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>>
>>> $ echo $TERM
>>> xterm
>>
>> Same here.
>>
>>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>
>> I am running KDE Konsole on Linux to access a local shell.
>>
>>> Of course, I typed
>>>
>>> (format t "hello~%")
>>>
>>> but we end up seeing
>>>
>>> (f(format t "hello~%")
>>
>> My terminal window shows:
>>
>> * (format t "hello~%")
>> hello
>> NIL
>>
>>> If I type
>>>
>>> (write-string "hello")
>>>
>>> we end up with
>>>
>>> * (w(write-string "hello")
>>> hello
>>> "hello"
>>
>> My terminal window shows:
>>
>> * (write-string "hello")
>> hello
>> "hello"
>>
>> Most likely suspect: Windows is the weakest link.
>>
>
> This is the easiest thing I could wire up as a simulation
> for those at home. Since I don't know a thing about LISP,
> I can't very well address that part of the problem.
>
> [Picture]
>
> https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif
>
> The $TERM declaration and the color capability,
> don't exactly match in my copy of PuTTY. The distortion
> seen by the OP does not look like wrongly emitted
> color codes, which could make more of a mess.
> PuTTY is not declaring "xterm-256color" as the term type.
>
> [Picture]
>
> https://i.postimg.cc/QMtZRXsc/putty-settings.gif

I believe this is a FreeBSD thing. Using the same PuTTY and the same
Windows, but loging in on a GNU Debian system, I don't see any problems:

--8<-------------------------------------------------------->8---
%uname -a
Linux kontesti.me 6.2.9-x86_64-linode160 #1 SMP PREEMPT_DYNAMIC Wed Apr 5 15:30:32 EDT 2023 x86_64 GNU/Linux
%sbcl --version

SBCL 1.2.4.debian
%echo $TERM
xterm

%rlwrap sbcl
This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "hello~%")
hello
NIL
--8<-------------------------------------------------------->8---

On Thu, 12/12/2024 11:00 AM, Salvador Mirzo wrote:
> Paul <nospam@needed.invalid> writes:
>
>> On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
>>> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>>>
>>>> $ echo $TERM
>>>> xterm
>>>
>>> Same here.
>>>
>>>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>>
>>> I am running KDE Konsole on Linux to access a local shell.
>>>
>>>> Of course, I typed
>>>>
>>>> (format t "hello~%")
>>>>
>>>> but we end up seeing
>>>>
>>>> (f(format t "hello~%")
>>>
>>> My terminal window shows:
>>>
>>> * (format t "hello~%")
>>> hello
>>> NIL
>>>
>>>> If I type
>>>>
>>>> (write-string "hello")
>>>>
>>>> we end up with
>>>>
>>>> * (w(write-string "hello")
>>>> hello
>>>> "hello"
>>>
>>> My terminal window shows:
>>>
>>> * (write-string "hello")
>>> hello
>>> "hello"
>>>
>>> Most likely suspect: Windows is the weakest link.
>>>
>>
>> This is the easiest thing I could wire up as a simulation
>> for those at home. Since I don't know a thing about LISP,
>> I can't very well address that part of the problem.
>>
>> [Picture]
>>
>> https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif
>>
>> The $TERM declaration and the color capability,
>> don't exactly match in my copy of PuTTY. The distortion
>> seen by the OP does not look like wrongly emitted
>> color codes, which could make more of a mess.
>> PuTTY is not declaring "xterm-256color" as the term type.
>>
>> [Picture]
>>
>> https://i.postimg.cc/QMtZRXsc/putty-settings.gif
>
> I believe this is a FreeBSD thing. Using the same PuTTY and the same
> Windows, but loging in on a GNU Debian system, I don't see any problems:
>
> --8<-------------------------------------------------------->8---
> %uname -a
> Linux kontesti.me 6.2.9-x86_64-linode160 #1 SMP PREEMPT_DYNAMIC Wed Apr 5 15:30:32 EDT 2023 x86_64 GNU/Linux
> %sbcl --version
>
> SBCL 1.2.4.debian
> %echo $TERM
> xterm
>
> %rlwrap sbcl
> This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (format t "hello~%")
> hello
> NIL
> --8<-------------------------------------------------------->8---
>

I set up a FreeBSD 14.2 VM and at least in terms of termcap,
and $TERM ("xterm"), the results so far look the same as with
my attempt on Linux Mint VM.

The contents of the prompt definition on the freebsd account are the default:

$TERM "xterm"
$PS1 \u@\h:\w \$

And I doubt a locale definition could make that sort of pattern.
It sorta looks like a terminal "echo" problem but why does it only
happen for the first few characters of a line ?

Paul

Paul

Salvador Mirzo <smirzo@example.com> wrote:
> I know next to nothing about terminals. My .profile says TERM=xterm.
>
> $ echo $TERM
> xterm
>
> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>
> When I invoke ``rlwrap sbcl'', I get a little bug:
>
> --8<-------------------------------------------------------->8---
> $ rlwrap sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (f(format t "hello~%")
> hello
> NIL
> --8<-------------------------------------------------------->8---
>
> Of course, I typed
>
> (format t "hello~%")
>
> but we end up seeing
>
> (f(format t "hello~%")
>
> If I type
>
> (write-string "hello")
>
> we end up with
>
> * (w(write-string "hello")
> hello
> "hello"
>
> You get the idea. This doesn't happen with other programs. It seems to
> be something specific to sbcl, though I could hardly believe that sbcl
> is guilty of anything here.
>
> Any remedies?
>

What terminal emulations does Putty support? Try vt100.

On 12/12/24 17:57, Paul wrote:
> why does it only happen for the first few characters of a line ?

It might not only be the first few characters of the line.

I've run into something like this in the past where the line was
effectively printed twice, over itself, with the second time shifted by
some number of characters to the right. So it looks like the first few
(?) characters are duplicated when in fact the entire line is repeated,
just offset and overwriting most of the line.

You can usually tell if something like this is happening by redirecting
STDOUT to a file or a utility like xxd and looking at the output.

I don't remember what the cause of this was, but once I found out what
was happening, I think it was fairly obvious where the problem was in
that instance.

--
Grant. . . .

In comp.unix.questions, Salvador Mirzo <smirzo@example.com> wrote:
> I know next to nothing about terminals. My .profile says TERM=xterm.
>
> $ echo $TERM
> xterm
>
> I really am running PuTTY on Windows and logging in to a FreeBSD system.

It sounds to me like the terminal definition (terminfo or termcap as
appropriate to FreeBSD) disagrees with the terminal implementation
(Putty here). This is a not uncommon thing to happen.

I would first see if there are Putty preferences that fix this.

Second see if it could be fixed with an intermediary that grabs terminal
output from the shell programs and rewrites before it gets to Putty.
Tools like tmux or screen will do that.

Third I'd try to fix the terminal definition. Using script to capture
the output of the terminal programs with all terminal escape codes
intact, I'd examine that output to look for cause of the bad formatting
and then search the terminal definition (terminfo or termcap) for the
terminal "capability" that causes the issue and fix or remove it.

Most capabilities are "nice to haves" instead of "required" so just
removing them doesn't break things. But editing those definitions is
not for the faint of heart. That's why the intermediary programs
rewriting things "works".

Elijah
------
got into customizing termcaps with the Televideo 925 (TERM=tvi-925)

On Fri, 12/13/2024 2:03 AM, Oregonian Haruspex wrote:
> Salvador Mirzo <smirzo@example.com> wrote:
>> I know next to nothing about terminals. My .profile says TERM=xterm.
>>
>> $ echo $TERM
>> xterm
>>
>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>
>> When I invoke ``rlwrap sbcl'', I get a little bug:
>>
>> --8<-------------------------------------------------------->8---
>> $ rlwrap sbcl
>> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (f(format t "hello~%")
>> hello
>> NIL
>> --8<-------------------------------------------------------->8---
>>
>> Of course, I typed
>>
>> (format t "hello~%")
>>
>> but we end up seeing
>>
>> (f(format t "hello~%")
>>
>> If I type
>>
>> (write-string "hello")
>>
>> we end up with
>>
>> * (w(write-string "hello")
>> hello
>> "hello"
>>
>> You get the idea. This doesn't happen with other programs. It seems to
>> be something specific to sbcl, though I could hardly believe that sbcl
>> is guilty of anything here.
>>
>> Any remedies?
>>
>
> What terminal emulations does Putty support? Try vt100.
>

OK, I found a dialog to change it from "xterm".

[Picture]

https://i.postimg.cc/Pqm5L2LS/Putty-Set-Terminal.gif

Since the connection is SSH over Ethernet, the "baud-rate"
would be mostly irrelevant.

Paul

Paul <nospam@needed.invalid> writes:

> On Thu, 12/12/2024 11:00 AM, Salvador Mirzo wrote:
>> Paul <nospam@needed.invalid> writes:
>>
>>> On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
>>>> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>>>>
>>>>> $ echo $TERM
>>>>> xterm
>>>>
>>>> Same here.
>>>>
>>>>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>>>
>>>> I am running KDE Konsole on Linux to access a local shell.
>>>>
>>>>> Of course, I typed
>>>>>
>>>>> (format t "hello~%")
>>>>>
>>>>> but we end up seeing
>>>>>
>>>>> (f(format t "hello~%")
>>>>
>>>> My terminal window shows:
>>>>
>>>> * (format t "hello~%")
>>>> hello
>>>> NIL
>>>>
>>>>> If I type
>>>>>
>>>>> (write-string "hello")
>>>>>
>>>>> we end up with
>>>>>
>>>>> * (w(write-string "hello")
>>>>> hello
>>>>> "hello"
>>>>
>>>> My terminal window shows:
>>>>
>>>> * (write-string "hello")
>>>> hello
>>>> "hello"
>>>>
>>>> Most likely suspect: Windows is the weakest link.
>>>>
>>>
>>> This is the easiest thing I could wire up as a simulation
>>> for those at home. Since I don't know a thing about LISP,
>>> I can't very well address that part of the problem.
>>>
>>> [Picture]
>>>
>>> https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif
>>>
>>> The $TERM declaration and the color capability,
>>> don't exactly match in my copy of PuTTY. The distortion
>>> seen by the OP does not look like wrongly emitted
>>> color codes, which could make more of a mess.
>>> PuTTY is not declaring "xterm-256color" as the term type.
>>>
>>> [Picture]
>>>
>>> https://i.postimg.cc/QMtZRXsc/putty-settings.gif
>>
>> I believe this is a FreeBSD thing. Using the same PuTTY and the same
>> Windows, but loging in on a GNU Debian system, I don't see any problems:
>>
>> --8<-------------------------------------------------------->8---
>> %uname -a
>> Linux kontesti.me 6.2.9-x86_64-linode160 #1 SMP PREEMPT_DYNAMIC Wed
>> Apr 5 15:30:32 EDT 2023 x86_64 GNU/Linux
>> %sbcl --version
>>
>> SBCL 1.2.4.debian
>> %echo $TERM
>> xterm
>>
>> %rlwrap sbcl
>> This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (format t "hello~%")
>> hello
>> NIL
>> --8<-------------------------------------------------------->8---
>>
>
> I set up a FreeBSD 14.2 VM and at least in terms of termcap,
> and $TERM ("xterm"), the results so far look the same as with
> my attempt on Linux Mint VM.
>
> The contents of the prompt definition on the freebsd account are the default:
>
> $TERM "xterm"
> $PS1 \u@\h:\w \$
>
> And I doubt a locale definition could make that sort of pattern.
> It sorta looks like a terminal "echo" problem but why does it only
> happen for the first few characters of a line ?

Hey, I also have a FreeBSD 14.2, but I also have a FreeBSD 14.1. It
turns out the problem does not happen on the FreeBSD 14.2:

$ echo $TERM
xterm

$ uname -a
FreeBSD b 14.2-RC1 FreeBSD 14.2-RC1 releng/14.2-n269505-5395ddd7aa13 GENERIC amd64

$ sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "hello~%")
hello
NIL
*

But, as you know already, here's what happens on FreeBSD 14.1:

$ echo $TERM
xterm

$ uname -a
FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64

$ sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "hello~%")
hello
NIL
*

What? It stopped doing it. What in the world is going on? This was
not a on-and-off thing; it was always doing it. I did not even set
anything new on my PuTTY configuration or anything. I'm very puzzled
now.

Salvador Mirzo <smirzo@example.com> writes:

> Paul <nospam@needed.invalid> writes:
>
>> On Thu, 12/12/2024 11:00 AM, Salvador Mirzo wrote:
>>> Paul <nospam@needed.invalid> writes:
>>>
>>>> On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
>>>>> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>>>>>
>>>>>> $ echo $TERM
>>>>>> xterm
>>>>>
>>>>> Same here.
>>>>>
>>>>>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>>>>
>>>>> I am running KDE Konsole on Linux to access a local shell.
>>>>>
>>>>>> Of course, I typed
>>>>>>
>>>>>> (format t "hello~%")
>>>>>>
>>>>>> but we end up seeing
>>>>>>
>>>>>> (f(format t "hello~%")
>>>>>
>>>>> My terminal window shows:
>>>>>
>>>>> * (format t "hello~%")
>>>>> hello
>>>>> NIL
>>>>>
>>>>>> If I type
>>>>>>
>>>>>> (write-string "hello")
>>>>>>
>>>>>> we end up with
>>>>>>
>>>>>> * (w(write-string "hello")
>>>>>> hello
>>>>>> "hello"
>>>>>
>>>>> My terminal window shows:
>>>>>
>>>>> * (write-string "hello")
>>>>> hello
>>>>> "hello"
>>>>>
>>>>> Most likely suspect: Windows is the weakest link.
>>>>>
>>>>
>>>> This is the easiest thing I could wire up as a simulation
>>>> for those at home. Since I don't know a thing about LISP,
>>>> I can't very well address that part of the problem.
>>>>
>>>> [Picture]
>>>>
>>>> https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif
>>>>
>>>> The $TERM declaration and the color capability,
>>>> don't exactly match in my copy of PuTTY. The distortion
>>>> seen by the OP does not look like wrongly emitted
>>>> color codes, which could make more of a mess.
>>>> PuTTY is not declaring "xterm-256color" as the term type.
>>>>
>>>> [Picture]
>>>>
>>>> https://i.postimg.cc/QMtZRXsc/putty-settings.gif
>>>
>>> I believe this is a FreeBSD thing. Using the same PuTTY and the same
>>> Windows, but loging in on a GNU Debian system, I don't see any problems:
>>>
>>> --8<-------------------------------------------------------->8---
>>> %uname -a
>>> Linux kontesti.me 6.2.9-x86_64-linode160 #1 SMP PREEMPT_DYNAMIC Wed
>>> Apr 5 15:30:32 EDT 2023 x86_64 GNU/Linux
>>> %sbcl --version
>>>
>>> SBCL 1.2.4.debian
>>> %echo $TERM
>>> xterm
>>>
>>> %rlwrap sbcl
>>> This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
>>> More information about SBCL is available at <http://www.sbcl.org/>.
>>>
>>> SBCL is free software, provided as is, with absolutely no warranty.
>>> It is mostly in the public domain; some portions are provided under
>>> BSD-style licenses. See the CREDITS and COPYING files in the
>>> distribution for more information.
>>> * (format t "hello~%")
>>> hello
>>> NIL
>>> --8<-------------------------------------------------------->8---
>>>
>>
>> I set up a FreeBSD 14.2 VM and at least in terms of termcap,
>> and $TERM ("xterm"), the results so far look the same as with
>> my attempt on Linux Mint VM.
>>
>> The contents of the prompt definition on the freebsd account are the default:
>>
>> $TERM "xterm"
>> $PS1 \u@\h:\w \$
>>
>> And I doubt a locale definition could make that sort of pattern.
>> It sorta looks like a terminal "echo" problem but why does it only
>> happen for the first few characters of a line ?
>
> Hey, I also have a FreeBSD 14.2, but I also have a FreeBSD 14.1. It
> turns out the problem does not happen on the FreeBSD 14.2:
>
> $ echo $TERM
> xterm
>
> $ uname -a
> FreeBSD b 14.2-RC1 FreeBSD 14.2-RC1 releng/14.2-n269505-5395ddd7aa13
> GENERIC amd64
>
> $ sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (format t "hello~%")
> hello
> NIL
> *
>
> But, as you know already, here's what happens on FreeBSD 14.1:
>
> $ echo $TERM
> xterm
>
> $ uname -a
> FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
>
> $ sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (format t "hello~%")
> hello
> NIL
> *
>
> What? It stopped doing it. What in the world is going on? This was
> not a on-and-off thing; it was always doing it. I did not even set
> anything new on my PuTTY configuration or anything. I'm very puzzled
> now.

Sorry! I forgot I have to use rlwrap. So the problem is related to the
rlwrap then. That was not clear to me yet. So, with rlwrap I see the
behavior on both FreeBSD 14.1 and 14.2:

$ uname -a
FreeBSD b 14.2-RC1 FreeBSD 14.2-RC1 releng/14.2-n269505-5395ddd7aa13 GENERIC amd64

$ rlwrap sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (f(format t "hello~%")
hello
NIL
*

Same thing on FreeBSD 14.1. (So, make sure you're using rlwrap.)

Someone (maybe you) suggested I should change my PuTTY terminal-type
string to vt100. I did. Same result:

$ uname -a
FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64

$ echo $TERM
vt100

$ rlwrap sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (f(format t "hello~%")
hello
NIL

Eli the Bearded <*@eli.users.panix.com> writes:

> In comp.unix.questions, Salvador Mirzo <smirzo@example.com> wrote:
>> I know next to nothing about terminals. My .profile says TERM=xterm.
>>
>> $ echo $TERM
>> xterm
>>
>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>
> It sounds to me like the terminal definition (terminfo or termcap as
> appropriate to FreeBSD) disagrees with the terminal implementation
> (Putty here). This is a not uncommon thing to happen.
>
> I would first see if there are Putty preferences that fix this.

My trial-and-error was to set local echo to ``force off'' and local line
editing to ``force off'':

https://prnt.sc/e6SedO_IiHTX

No difference. (I also set the terminal-type string to vt100.)

I just installed the terminal Alacritty. I see the same behavior on it:

$ echo $TERM
xterm-256color

$ uname -a
FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64

$ rlwrap sbcl
This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (f(format t "hello~%")
hello
NIL
*

> Second see if it could be fixed with an intermediary that grabs terminal
> output from the shell programs and rewrites before it gets to Putty.
> Tools like tmux or screen will do that.
>
> Third I'd try to fix the terminal definition. Using script to capture
> the output of the terminal programs with all terminal escape codes
> intact, I'd examine that output to look for cause of the bad formatting
> and then search the terminal definition (terminfo or termcap) for the
> terminal "capability" that causes the issue and fix or remove it.
>
> Most capabilities are "nice to haves" instead of "required" so just
> removing them doesn't break things. But editing those definitions is
> not for the faint of heart. That's why the intermediary programs
> rewriting things "works".

That's more technical than I could do right now on my own. If you have
the energy describe what it is that I must do in more details---what
software to use et cetera---I will do it. Thanks!

On Fri, 12/13/2024 6:49 PM, Salvador Mirzo wrote:
> Salvador Mirzo <smirzo@example.com> writes:
>
>> Paul <nospam@needed.invalid> writes:
>>
>>> On Thu, 12/12/2024 11:00 AM, Salvador Mirzo wrote:
>>>> Paul <nospam@needed.invalid> writes:
>>>>
>>>>> On Thu, 12/12/2024 1:05 AM, Lawrence D'Oliveiro wrote:
>>>>>> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>>>>>>
>>>>>>> $ echo $TERM
>>>>>>> xterm
>>>>>>
>>>>>> Same here.
>>>>>>
>>>>>>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>>>>>
>>>>>> I am running KDE Konsole on Linux to access a local shell.
>>>>>>
>>>>>>> Of course, I typed
>>>>>>>
>>>>>>> (format t "hello~%")
>>>>>>>
>>>>>>> but we end up seeing
>>>>>>>
>>>>>>> (f(format t "hello~%")
>>>>>>
>>>>>> My terminal window shows:
>>>>>>
>>>>>> * (format t "hello~%")
>>>>>> hello
>>>>>> NIL
>>>>>>
>>>>>>> If I type
>>>>>>>
>>>>>>> (write-string "hello")
>>>>>>>
>>>>>>> we end up with
>>>>>>>
>>>>>>> * (w(write-string "hello")
>>>>>>> hello
>>>>>>> "hello"
>>>>>>
>>>>>> My terminal window shows:
>>>>>>
>>>>>> * (write-string "hello")
>>>>>> hello
>>>>>> "hello"
>>>>>>
>>>>>> Most likely suspect: Windows is the weakest link.
>>>>>>
>>>>>
>>>>> This is the easiest thing I could wire up as a simulation
>>>>> for those at home. Since I don't know a thing about LISP,
>>>>> I can't very well address that part of the problem.
>>>>>
>>>>> [Picture]
>>>>>
>>>>> https://i.postimg.cc/9FVtm0S5/putty-ssh-session-overview.gif
>>>>>
>>>>> The $TERM declaration and the color capability,
>>>>> don't exactly match in my copy of PuTTY. The distortion
>>>>> seen by the OP does not look like wrongly emitted
>>>>> color codes, which could make more of a mess.
>>>>> PuTTY is not declaring "xterm-256color" as the term type.
>>>>>
>>>>> [Picture]
>>>>>
>>>>> https://i.postimg.cc/QMtZRXsc/putty-settings.gif
>>>>
>>>> I believe this is a FreeBSD thing. Using the same PuTTY and the same
>>>> Windows, but loging in on a GNU Debian system, I don't see any problems:
>>>>
>>>> --8<-------------------------------------------------------->8---
>>>> %uname -a
>>>> Linux kontesti.me 6.2.9-x86_64-linode160 #1 SMP PREEMPT_DYNAMIC Wed
>>>> Apr 5 15:30:32 EDT 2023 x86_64 GNU/Linux
>>>> %sbcl --version
>>>>
>>>> SBCL 1.2.4.debian
>>>> %echo $TERM
>>>> xterm
>>>>
>>>> %rlwrap sbcl
>>>> This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
>>>> More information about SBCL is available at <http://www.sbcl.org/>.
>>>>
>>>> SBCL is free software, provided as is, with absolutely no warranty.
>>>> It is mostly in the public domain; some portions are provided under
>>>> BSD-style licenses. See the CREDITS and COPYING files in the
>>>> distribution for more information.
>>>> * (format t "hello~%")
>>>> hello
>>>> NIL
>>>> --8<-------------------------------------------------------->8---
>>>>
>>>
>>> I set up a FreeBSD 14.2 VM and at least in terms of termcap,
>>> and $TERM ("xterm"), the results so far look the same as with
>>> my attempt on Linux Mint VM.
>>>
>>> The contents of the prompt definition on the freebsd account are the default:
>>>
>>> $TERM "xterm"
>>> $PS1 \u@\h:\w \$
>>>
>>> And I doubt a locale definition could make that sort of pattern.
>>> It sorta looks like a terminal "echo" problem but why does it only
>>> happen for the first few characters of a line ?
>>
>> Hey, I also have a FreeBSD 14.2, but I also have a FreeBSD 14.1. It
>> turns out the problem does not happen on the FreeBSD 14.2:
>>
>> $ echo $TERM
>> xterm
>>
>> $ uname -a
>> FreeBSD b 14.2-RC1 FreeBSD 14.2-RC1 releng/14.2-n269505-5395ddd7aa13
>> GENERIC amd64
>>
>> $ sbcl
>> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (format t "hello~%")
>> hello
>> NIL
>> *
>>
>> But, as you know already, here's what happens on FreeBSD 14.1:
>>
>> $ echo $TERM
>> xterm
>>
>> $ uname -a
>> FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
>>
>> $ sbcl
>> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (format t "hello~%")
>> hello
>> NIL
>> *
>>
>> What? It stopped doing it. What in the world is going on? This was
>> not a on-and-off thing; it was always doing it. I did not even set
>> anything new on my PuTTY configuration or anything. I'm very puzzled
>> now.
>
> Sorry! I forgot I have to use rlwrap. So the problem is related to the
> rlwrap then. That was not clear to me yet. So, with rlwrap I see the
> behavior on both FreeBSD 14.1 and 14.2:
>
> $ uname -a
> FreeBSD b 14.2-RC1 FreeBSD 14.2-RC1 releng/14.2-n269505-5395ddd7aa13 GENERIC amd64
>
> $ rlwrap sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (f(format t "hello~%")
> hello
> NIL
> *
>
> Same thing on FreeBSD 14.1. (So, make sure you're using rlwrap.)
>
> Someone (maybe you) suggested I should change my PuTTY terminal-type
> string to vt100. I did. Same result:
>
> $ uname -a
> FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
>
> $ echo $TERM
> vt100
>
> $ rlwrap sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (f(format t "hello~%")
> hello
> NIL
>

The pattern is not suggestive of a $TERM problem, but it was
worth trying a change anyway.

Perhaps the rlwrap developer recognizes the pattern ?

Paul

Paul <nospam@needed.invalid> writes:

> On Fri, 12/13/2024 6:49 PM, Salvador Mirzo wrote:

[...]

>> Someone (maybe you) suggested I should change my PuTTY terminal-type
>> string to vt100. I did. Same result:
>>
>> $ uname -a
>> FreeBSD my.domain 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
>>
>> $ echo $TERM
>> vt100
>>
>> $ rlwrap sbcl
>> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (f(format t "hello~%")
>> hello
>> NIL
>>
>
> The pattern is not suggestive of a $TERM problem, but it was
> worth trying a change anyway.
>
> Perhaps the rlwrap developer recognizes the pattern ?

Good idea. I asked them at

https://github.com/hanslub42/rlwrap/issues/194

Thanks for your attention, Paul!

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 11 Dec 2024 22:22:28 -0300, Salvador Mirzo wrote:
>
>> $ echo $TERM
>> xterm
>
> Same here.
>
>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>
> I am running KDE Konsole on Linux to access a local shell.
>
>> Of course, I typed
>>
>> (format t "hello~%")
>>
>> but we end up seeing
>>
>> (f(format t "hello~%")
>
> My terminal window shows:
>
> * (format t "hello~%")
> hello
> NIL
>
>> If I type
>>
>> (write-string "hello")
>>
>> we end up with
>>
>> * (w(write-string "hello")
>> hello
>> "hello"
>
> My terminal window shows:
>
> * (write-string "hello")
> hello
> "hello"
>
> Most likely suspect: Windows is the weakest link.

I can reproduce the problem on an xterm running Xorg in the latest
version of FreeBSD. A picture: https://0x0.st/8rkK.png.

On 2024-12-12, Salvador Mirzo <smirzo@example.com> wrote:
> I know next to nothing about terminals. My .profile says TERM=xterm.
>
> $ echo $TERM
> xterm
>
> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>
> When I invoke ``rlwrap sbcl'', I get a little bug:
>
> --8<-------------------------------------------------------->8---
> $ rlwrap sbcl
> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (f(format t "hello~%")
> hello
> NIL
> --8<-------------------------------------------------------->8---
>
> Of course, I typed
>
> (format t "hello~%")
>
> but we end up seeing
>
> (f(format t "hello~%")
>
> If I type
>
> (write-string "hello")
>
> we end up with
>
> * (w(write-string "hello")
> hello
> "hello"
>
> You get the idea. This doesn't happen with other programs. It seems to
> be something specific to sbcl, though I could hardly believe that sbcl
> is guilty of anything here.
>
> Any remedies?

You can try using vim+slimv, it's much better than a simple REPL

Bozo User <anthk@disroot.org> writes:

> On 2024-12-12, Salvador Mirzo <smirzo@example.com> wrote:
>> I know next to nothing about terminals. My .profile says TERM=xterm.
>>
>> $ echo $TERM
>> xterm
>>
>> I really am running PuTTY on Windows and logging in to a FreeBSD system.
>>
>> When I invoke ``rlwrap sbcl'', I get a little bug:
>>
>> --8<-------------------------------------------------------->8---
>> $ rlwrap sbcl
>> This is SBCL 2.4.9, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses. See the CREDITS and COPYING files in the
>> distribution for more information.
>> * (f(format t "hello~%")
>> hello
>> NIL
>> --8<-------------------------------------------------------->8---
>>
>> Of course, I typed
>>
>> (format t "hello~%")
>>
>> but we end up seeing
>>
>> (f(format t "hello~%")
>>
>> If I type
>>
>> (write-string "hello")
>>
>> we end up with
>>
>> * (w(write-string "hello")
>> hello
>> "hello"
>>
>> You get the idea. This doesn't happen with other programs. It seems to
>> be something specific to sbcl, though I could hardly believe that sbcl
>> is guilty of anything here.
>>
>> Any remedies?
>
> You can try using vim+slimv, it's much better than a simple REPL

Thanks! It turns out I replaced FreeBSD with OpenBSD and I cannot
reproduce the problem on the OpenBSD system. So, to me, personally, the
problem is eliminated---but there's something going on in FreeBSD, which
should be looked at. I have no intuition on the problem.

$ rlwrap sbcl
This is SBCL 2.4.8.openbsd.sbcl-2.4.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "hello~%")
hello
NIL
*

$ uname -a
OpenBSD b.local 7.6 GENERIC.MP#338 amd64

$ rlwrap --version
rlwrap 0.46.1