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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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---

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)