Pardon if this is off topic as it might have something to do with
the shell rather than with Reduce.
With my new Desktop machine at work, I can't navigate with the arrow keys
when running Reduce in the command line, i.e. I get the ESC crtl letter sequence (like ^[A ).
I don't get that in the bash, it's just with Reduce.
It does work flawlessly at home, though, where I'm using the same distribution.
Any ideas as to what's causing it?
I couldn't find a similar topic here, hence I posted.
Thanks for any hints.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is supported by the gnu readline library. Do you have it installed? Did the configure script find it? You can look az the config log and look for 'readline'.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is supported by the gnu readline library. Do you have it
installed? Did the configure script find it? You can look az the config
log and look for 'readline'.
Regards
Reduce does not use readline (because the licensing terms there are such
that readline is incompatible with use in a BSD-licensed piece of
software and retaining BSD status). It used libedit which is more
liberally licensed and it uses a copy where a copy of the libedit source
is kept within the Reduce source so that there can be certainty about its
availability.
bash will be using readline since it subscribed to the GNU set of rules.
I think that the interesting point in the original report is that Reduce
is bahaving differently on home and work machines despite both running the
same OS. Which version of Linux is that please?
There are three things I would do to try to investigate...
(a) Check "vi" and any other cursor-based things that spring to mind to
see if the keys behave properly for them.
(b) Check what value TERM has and in particular whether its settings at
home and work match.
(c) [less plausible I think] wonder if keyboard nationality and options
are set up similarly. It is a different issue I know but when I set up a
new Linux system then "reasonably often" the @ and " keys [and some more]
get mixed up because keyboard layout has not been get correct.
If the new machine is at work is there a support person there who can
investigate a bit (was it thhem who set the system up for you?)
Tracking this down from a distance is tough because sort of obviously I
can not reproduce and so investigate. But it sort of related to terminal
raw and cooked modes. Hmm I might ssh to the work machine and see if
things were still messed up when using the keyboard on some other physical
machine? The fact that the work machine is new makes me suggest there may
be something slightly odd in its setup?
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, it should've shipped with Ubuntu.
Anyway, it did the trick by extracting the compressed file and running the rfcsl (rfpsl) instead of redcsl (redpsl). Hope nothing scary comes out of this
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Arthur, I appreciate the feedback.
I'm running both machines on Ubuntu 20.04.1 LTS.
a) The cursor moves normally with arrow keys in both machines for vi, ipython, etc
b) Not sure that's what you meant, but echoing $TERM gives the same result: term-256color
c) Indeed, I have an american keyboard at home and a german one at work. But accessing my work machine from home doesn't change the outcome when trying to move the cursor.
As I said, running the rf instead of red does the trick, it's just a bit annoying not having a clue as of what's going on. Thanks for the feedback, anyways
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you have a work-around and I also do not have a clue and can sort of
obviouslt not recreate that here. I would like to be able to get to the
bottom of this so if you would be willing to help then send me private
email rather than a posting to everybody and I will look for ways to make
sense of this. The fact that the issus is reproduced when you link in from
home may mean that this does not have to disrupt work-time too much?
Odd.
Arthur
On Fri, 15 Jan 2021, LGC wrote:
Thanks Arthur, I appreciate the feedback.
I'm running both machines on Ubuntu 20.04.1 LTS.
a) The cursor moves normally with arrow keys in both machines for vi,
ipython, etc
b) Not sure that's what you meant, but echoing $TERM gives the same
result: term-256color
c) Indeed, I have an american keyboard at home and a german one at
work. But accessing my work machine from home doesn't change the outcome
when trying to move the cursor.
As I said, running the rf instead of red does the trick, it's just a
bit annoying not having a clue as of what's going on. Thanks for the
feedback, anyways
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using the deb package downloaded from sourceforge on ubuntu, previously on 18.04, now on 20.04, and also see control characters instead of cursor movement. If I remember correctly, it was the same on 18.04. Just for information, running ldd on /usr/share/reduce/cslbuild/csl/reduce does not list libedit as a shared library loaded by reduce.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using the deb package downloaded from sourceforge on ubuntu,
previously on 18.04, now on 20.04, and also see control characters
instead of cursor movement. If I remember correctly, it was the same on
18.04. Just for information, running ldd on
/usr/share/reduce/cslbuild/csl/reduce does not list libedit as a shared
library loaded by reduce.
Reduce links its own copy of libedit in so that it does not rely on there
having to be a version of that installed by the system.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK (well sort of). I fetched that .deb package and installed and observe
what you report. However both a build on the same machine from up to date
sources and the same up to date build created on that machine via the full
process that creates a .deb file lead to versions without the problem. So
either there was what must have been a transient issue present when that
snapshot was built (that is why it is called a "snapshot" not a
"release"!) or somehow the snapshot build process misbehaved. We expect to
put up a new snapshot fairly soon. Apologies. A report sent in as soon as
anybody first spotted this would have got looked into sooner!
Right now I do not know excatly what the issue was. The fact that I see
the problem on a Linux that has all the libraries I ever used installed
means it is not a matter of a missing system library. Right now I am
ensuring I have a copy of revision 5424 (to match that snapshot) so I can
build from that and see what I see... Hmmm a version I just built from
that looks OK.
General request: if things seem bad raise a (polite please!) query on this
list fairly promptly so we can check and respond - if you do not let any
of us know then things will remain unfixed. well some things will be too
hard to fix anyway, but you know that and this ia a volunteer not a
paid-for project.
Arthur
On Fri, 15 Jan 2021, arpi wrote:
I am using the deb package downloaded from sourceforge on ubuntu,
previously on 18.04, now on 20.04, and also see control characters
instead of cursor movement. If I remember correctly, it was the same on
18.04.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry. I did not know that the behaviour was not intentional. I did know about the license of libreadline, the fact that redfront has line editing, and just assumed that reduce does not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry. I did not know that the behaviour was not intentional. I did
know about the license of libreadline, the fact that redfront has line
editing, and just assumed that reduce does not.
No problem at all, so not worry. And it was good to have a second report
confirming the behaviour.
The PSL version of Reduce needs redfront and redfront has a more fully
developed set of magic-key options than the embedded CSL local
editing/hisory system, so some people prefer it. If you just use "up" and
"down" keys to scroll through history there may be little difference. And
the two schemes save their history in different places so if you used
redfront first and build up a history and then try just "redcsl -w" (or
vice versa) your history is not shared.
Apologies again that that snapshot was somehow in an odd state.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pardon if this is off topic as it might have something to do with
the shell rather than with Reduce.
With my new Desktop machine at work, I can't navigate with the arrow keys
when running Reduce in the command line, i.e. I get the ESC crtl letter sequence (like ^[A ).
I don't get that in the bash, it's just with Reduce.
It does work flawlessly at home, though, where I'm using the same distribution.
Any ideas as to what's causing it?
I couldn't find a similar topic here, hence I posted.
Thanks for any hints.
This is supported by the gnu readline library. Do you have it installed? Did the configure script find it? You can look az the config log and look for 'readline'.
Regards
On Thu, 14 Jan 2021, Peter Bajan wrote:
Reduce does not use readline (because the licensing terms there are such
that readline is incompatible with use in a BSD-licensed piece of
software and retaining BSD status). It used libedit which is more
liberally licensed and it uses a copy where a copy of the libedit source
is kept within the Reduce source so that there can be certainty about its
availability.
bash will be using readline since it subscribed to the GNU set of rules.
I think that the interesting point in the original report is that Reduce
is bahaving differently on home and work machines despite both running the
same OS. Which version of Linux is that please?
There are three things I would do to try to investigate...
(a) Check "vi" and any other cursor-based things that spring to mind to
see if the keys behave properly for them.
(b) Check what value TERM has and in particular whether its settings at
home and work match.
(c) [less plausible I think] wonder if keyboard nationality and options
are set up similarly. It is a different issue I know but when I set up a
new Linux system then "reasonably often" the @ and " keys [and some more]
get mixed up because keyboard layout has not been get correct.
If the new machine is at work is there a support person there who can
investigate a bit (was it thhem who set the system up for you?)
Tracking this down from a distance is tough because sort of obviously I
can not reproduce and so investigate. But it sort of related to terminal
raw and cooked modes. Hmm I might ssh to the work machine and see if
things were still messed up when using the keyboard on some other physical
machine? The fact that the work machine is new makes me suggest there may
be something slightly odd in its setup?
Arthur
Thanks, it should've shipped with Ubuntu.
Anyway, it did the trick by extracting the compressed file and running the rfcsl (rfpsl) instead of redcsl (redpsl). Hope nothing scary comes out of this
Thanks Arthur, I appreciate the feedback.
I'm running both machines on Ubuntu 20.04.1 LTS.
a) The cursor moves normally with arrow keys in both machines for vi, ipython, etc
b) Not sure that's what you meant, but echoing $TERM gives the same result: term-256color
c) Indeed, I have an american keyboard at home and a german one at work. But accessing my work machine from home doesn't change the outcome when trying to move the cursor.
As I said, running the rf instead of red does the trick, it's just a bit annoying not having a clue as of what's going on. Thanks for the feedback, anyways
Glad you have a work-around and I also do not have a clue and can sort of
obviouslt not recreate that here. I would like to be able to get to the
bottom of this so if you would be willing to help then send me private
email rather than a posting to everybody and I will look for ways to make
sense of this. The fact that the issus is reproduced when you link in from
home may mean that this does not have to disrupt work-time too much?
Odd.
Arthur
On Fri, 15 Jan 2021, LGC wrote:
I am using the deb package downloaded from sourceforge on ubuntu, previously on 18.04, now on 20.04, and also see control characters instead of cursor movement. If I remember correctly, it was the same on 18.04. Just for information, running ldd on /usr/share/reduce/cslbuild/csl/reduce does not list libedit as a shared library loaded by reduce.
On Fri, 15 Jan 2021, arpi wrote:
OK (well sort of). I fetched that .deb package and installed and observe
what you report. However both a build on the same machine from up to date
sources and the same up to date build created on that machine via the full
process that creates a .deb file lead to versions without the problem. So
either there was what must have been a transient issue present when that
snapshot was built (that is why it is called a "snapshot" not a
"release"!) or somehow the snapshot build process misbehaved. We expect to
put up a new snapshot fairly soon. Apologies. A report sent in as soon as
anybody first spotted this would have got looked into sooner!
Right now I do not know excatly what the issue was. The fact that I see
the problem on a Linux that has all the libraries I ever used installed
means it is not a matter of a missing system library. Right now I am
ensuring I have a copy of revision 5424 (to match that snapshot) so I can
build from that and see what I see... Hmmm a version I just built from
that looks OK.
General request: if things seem bad raise a (polite please!) query on this
list fairly promptly so we can check and respond - if you do not let any
of us know then things will remain unfixed. well some things will be too
hard to fix anyway, but you know that and this ia a volunteer not a
paid-for project.
ArthurOn Fri, 15 Jan 2021, arpi wrote:
Sorry. I did not know that the behaviour was not intentional. I did know about the license of libreadline, the fact that redfront has line editing, and just assumed that reduce does not.
On Sun, 17 Jan 2021, arpi wrote: