Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.questions > #547 > unrolled thread

xterm rlwrap sbcl

Started bySalvador Mirzo <smirzo@example.com>
First post2024-12-11 22:22 -0300
Last post2025-01-12 22:06 -0300
Articles 17 — 7 participants

Back to article view | Back to comp.unix.questions


Contents

  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

#547 — xterm rlwrap sbcl

FromSalvador Mirzo <smirzo@example.com>
Date2024-12-11 22:22 -0300
Subjectxterm 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]


#548

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2024-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]


#549

FromPaul <nospam@needed.invalid>
Date2024-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]


#550

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#551

FromPaul <nospam@needed.invalid>
Date2024-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]


#552

FromGrant Taylor <gtaylor@tnetconsulting.net>
Date2024-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]


#556

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#557

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#559

FromPaul <nospam@needed.invalid>
Date2024-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]


#560

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#562

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#553

FromEli the Bearded <*@eli.users.panix.com>
Date2024-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]


#558

FromSalvador Mirzo <smirzo@example.com>
Date2024-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]


#554

FromOregonian Haruspex <no_email@invalid.invalid>
Date2024-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]


#555

FromPaul <nospam@needed.invalid>
Date2024-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]


#563

FromBozo User <anthk@disroot.org>
Date2025-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]


#564

FromSalvador Mirzo <smirzo@example.com>
Date2025-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