Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.questions > #547 > unrolled thread
| Started by | Salvador Mirzo <smirzo@example.com> |
|---|---|
| First post | 2024-12-11 22:22 -0300 |
| Last post | 2025-01-12 22:06 -0300 |
| Articles | 17 — 7 participants |
Back to article view | Back to comp.unix.questions
xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-11 22:22 -0300
Re: xterm rlwrap sbcl Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 06:05 +0000
Re: xterm rlwrap sbcl Paul <nospam@needed.invalid> - 2024-12-12 07:20 -0500
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-12 13:00 -0300
Re: xterm rlwrap sbcl Paul <nospam@needed.invalid> - 2024-12-12 18:57 -0500
Re: xterm rlwrap sbcl Grant Taylor <gtaylor@tnetconsulting.net> - 2024-12-12 20:40 -0600
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-13 20:40 -0300
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-13 20:49 -0300
Re: xterm rlwrap sbcl Paul <nospam@needed.invalid> - 2024-12-13 19:55 -0500
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-14 18:51 -0300
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-25 22:01 -0300
Re: xterm rlwrap sbcl Eli the Bearded <*@eli.users.panix.com> - 2024-12-13 03:06 +0000
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2024-12-13 20:59 -0300
Re: xterm rlwrap sbcl Oregonian Haruspex <no_email@invalid.invalid> - 2024-12-13 07:03 +0000
Re: xterm rlwrap sbcl Paul <nospam@needed.invalid> - 2024-12-13 03:22 -0500
Re: xterm rlwrap sbcl Bozo User <anthk@disroot.org> - 2025-01-12 23:01 +0000
Re: xterm rlwrap sbcl Salvador Mirzo <smirzo@example.com> - 2025-01-12 22:06 -0300
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-11 22:22 -0300 |
| Subject | xterm rlwrap sbcl |
| Message-ID | <87frmtofu3.fsf@example.com> |
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?
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-12-12 06:05 +0000 |
| Message-ID | <vjdufn$20g9u$1@dont-email.me> |
| In reply to | #547 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2024-12-12 07:20 -0500 |
| Message-ID | <vjeke1$24hao$1@dont-email.me> |
| In reply to | #548 |
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
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-12 13:00 -0300 |
| Message-ID | <874j383n8h.fsf@example.com> |
| In reply to | #549 |
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---
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2024-12-12 18:57 -0500 |
| Message-ID | <vjft9r$30pgt$1@dont-email.me> |
| In reply to | #550 |
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
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2024-12-12 20:40 -0600 |
| Message-ID | <vjg6rg$djr$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #551 |
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. . . .
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-13 20:40 -0300 |
| Message-ID | <87a5czgni9.fsf@example.com> |
| In reply to | #551 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-13 20:49 -0300 |
| Message-ID | <87y10jf8jx.fsf@example.com> |
| In reply to | #556 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2024-12-13 19:55 -0500 |
| Message-ID | <vjil2v$3mbam$1@dont-email.me> |
| In reply to | #557 |
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
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-14 18:51 -0300 |
| Message-ID | <87cyhuexvv.fsf@example.com> |
| In reply to | #559 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-25 22:01 -0300 |
| Message-ID | <868qs3i7fg.fsf@example.com> |
| In reply to | #548 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Eli the Bearded <*@eli.users.panix.com> |
|---|---|
| Date | 2024-12-13 03:06 +0000 |
| Message-ID | <eli$2412122205@qaz.wtf> |
| In reply to | #547 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2024-12-13 20:59 -0300 |
| Message-ID | <87o71ff82q.fsf@example.com> |
| In reply to | #553 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Oregonian Haruspex <no_email@invalid.invalid> |
|---|---|
| Date | 2024-12-13 07:03 +0000 |
| Message-ID | <vjgm8c$3999k$1@dont-email.me> |
| In reply to | #547 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2024-12-13 03:22 -0500 |
| Message-ID | <vjgqs7$3a8q8$1@dont-email.me> |
| In reply to | #554 |
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
[toc] | [prev] | [next] | [standalone]
| From | Bozo User <anthk@disroot.org> |
|---|---|
| Date | 2025-01-12 23:01 +0000 |
| Message-ID | <vm1hk4$1etjc$4@dont-email.me> |
| In reply to | #547 |
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
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2025-01-12 22:06 -0300 |
| Message-ID | <875xmj4j4r.fsf@example.com> |
| In reply to | #563 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | comp.unix.questions
csiph-web