Bug: When calc is linked with and uses GNU readline then for any multi-line copy-and-paste, only the first line is executed #138
Comments
malfisya
changed the title
|
Hello @malfisya, Not near a system on which we can test, that might have to wait a few days. QUESTION: You indicate that calc release v2.14.0.10 does not exhibit this problem for you, while calc release v2.14.0.13 does exhibit this problem for you. What about calc release v2.14.0.12. Does that exhibit the problem you describe? Also are you compiling these versions or just installing from the binary rpms? |
|
Hello!
That's fine. Happy holidays.
I haven't tried it. Isn't this file missing some critical file? I can't build this version. I will be trying it again by adding those files manually.
I am compiling it myself from the tarball (calc-x.x.x.x.tar.bz2) via Solus build system called |
If we recall correctly, the missing file was |
|
Hello @malfisya, Instead of trying the above, and thinking "out loud from afar" (of the keyboard) ... We suggest that you first from a clone of the calc repo in some directory that does NOT have a git clone https://github.com/lcn2/calc.git
cd calc
make clobberTry calc v2.14.0.10: git checkout 769ac51f8cb40a8c06bcb370660bf1c2407c4642
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qTry calc v2.14.0.11: git checkout e213cc50723bbb1d13ca7a5c6f07300ca212ff94
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qTry calc v2.14.0.12 (a version that can be compiled): git checkout 0f6efb29bba08d269371634c4237438d8782a4a3
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qTry calc v2.14.0.13: git checkout ffd4422870cf81c83c06dd555fbbe64adbce803a
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qTry calc v2.15.0.4: git checkout 1d37930d22d867bdf9a5be4bf16a40d0bd44d7ea
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qTry the latest on the master branch (and get out of the "detached head" state): git checkout master
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qWe recommend you do those steps. Which versions exhibit the problem you describe and which work as you expect? |
|
Figured it out. it is |
Sorry (tm Canada 🇨🇦), the alias is was a habit from old SCCS and RCS days. 🤓 FYI, here the useful parts of the |
|
So here is my findings:
Sidenote:
I believe this is a typo. It should be v2.14.0.12
This too v2.14.0.13 Cheers! |
|
Sidenote:
Corrected typos (sorry (tm Canada 🇨🇦)). UPDATE 0All of our "away from a terminal" comments are being typed into a cellphone, making it harder to catch typos. It might be a few more days, before we are back to a real computer. In the meantime, if you don't mind, we have a proposed test for to to try: test the current master branch of calc without using the GNU history and GNU readline libraries, and see what the multi-line paste does. See below. |
|
We were briefly near a terminal and tested those versions mentioned in the corrected comment 1869760653 on RedHat Enterprise Linux 9, current Debian Linux, current macOS. None of them was able to be process as you referenced in your "version 2.14.0.10 - Last good version" screenshot. We did the checkout, make clobber, compile, run and paste test. We could not find a calc version nor platform that performed as the "version 2.14.0.10 - Last good version" screenshot. UPDATE 0We were only briefly near a terminal, just enough to perform the above tests. It might be a few more days, before we are back to a real computer. |
|
Just as an FYI, and not really intended as a "fix". We noticed in one of your screenshots that after pasting, as noted in your bug report: You then attempts to edit it into a 1-line compound command. As a 1-line compound command, it should be written as: Or something like that. The ;'s in that 1-liner are important. Again, this is not "fix", just an FYI. |
|
One possible explanation for what might be happening is that the readline / history libraries that calc can use are rejecting (by their design) the multiple line paste, or maybe ignoring the text beyond the first new line of the paste. This might point to the behavior in the GNU history library and GNU readline library, and not calc code itself. We offer this not as an excuse, but as a possible explanation as to that is going on. We agree that it would be nice if calc were to work as your "version 2.14.0.10 - Last good version" screen 📺 movie. At one point in calc's development history, the use of the GNU history library and GNU readline library became compiled and were linked in by default. We will try to find out the calc version for which this happened. It might be possible if you were to compile the current calc WITHOUT using GNU history library and GNU readline library, that the multi-line paste might work as you want it to. Give the current master branch code an edit to disable compiling and linking of the GNU history library and the GNU readline library. See if that works as you want. The above is not necessary intended as a "fix", but rather as a diagnostic step. |
Yes, that's what happens to me too. But building v2.14.0.10 from tarball performed as in "version 2.14.0.10 - Last good version" screenshot. Whether i build It from git or tarball, it should have the same result right? Did you try compile it from tarball not git? Another sidenote: |
Yes, it expects semicolon. Thank you |
|
We think to compile and link calc without GNU readline and without GNU history you would need: Or perhaps even without ncurses: You could add such lines you own make clobber
make all USE_READLINE="-UUSE_READLINE" READLINE_LIB= READLINE_EXTRAS= READLINE_INCLUDE=And then run the calc you just compiled: make runAgain, the above is intended as a diagnostic, not as a fix. Let us know what happeds, @malfisya .. thanks 🙏 |
Those steps solves the copy-paste bug. It behaves as the "version 2.14.0.10 - Last good version" screenrecord. Your suspicion might be right about GNU readline. Run |
Hello @malfisya , Thanks for that excellent report. So the current release of calc, when you built it without GNU readline and GNU history does not exhibit the multi-line copy-and-paste problem you reported. Correct? Perhaps the multi-line copy-and-paste problem you detected is:
UPDATE 0What we do NOT understand is how your "version 2.14.0.10 - Last good version" screen movie shows the copy-and-paste working as you expected. However when we tried that on several different platforms, we saw the multi-line copy-and-paste problem when you did not. We do not understand why this is the case. To help rule out that this issue related to how the source is obtained and compiled, please try the following: If you, in a directory that does not contain calc, do this: git clone https://github.com/lcn2/calc.git
cd calc
make clobberfollowed by this for calc version 2.14.0.10: git checkout 769ac51f8cb40a8c06bcb370660bf1c2407c4642
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qQUESTION: Does your multi-line copy-and-paste example work for you as you expect? Then if you do this for the current master branch: git checkout master
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qQUESTION: Does your multi-line copy-and-paste example work for you as you expect? Then if you do this: make clobber
make all CCWERR= USE_READLINE="-UUSE_READLINE" READLINE_LIB= READLINE_EXTRAS="-lncurses" READLINE_INCLUDE=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qQUESTION: Does your multi-line copy-and-paste example work for you as you expect? We know the above seems like a repeat (there are two minor differences that should not matter). We just want to be doubly sure. QUESTION: Under what OS and window manager are you doing the above tests? |
|
Hello @malfisya, So in most cases for recent versions, calc appears to do nothing when one does this multi-line copy-and-paste: other than calc issuing a new prompt. However we do not think calc is completely ignoring the multi-line copy-and-paste, but rather we think calc is only processing (or perhaps only being given by the GNU library) the first line of the multi-line copy-and-paste. So we have a series of new tests for you to try if you are willing. Try this from the master branch: make clobber
git checkout master
make clobber all chk CCWERR=
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -qNow just copy-and-paste this one line: We predict calc will print: QUESTION: What did calc print for you for the above test? Now copy-and-paste the following multi-line text, which is slightly different from your original example: If the copy-and-paste does NOT work as expected, then calc will just print: QUESTION: What did calc print for you for the above test? However, calc may be processing the first line of a multi-line copy-and-paste, or the GNU library may only be giving the first line of a multi-line copy-and-paste for calc to process. Now copy-and-paste this one line again: We predict calc will print: QUESTION: What did calc print for you for the above test? Now exit calc and then restart calc: Now copy-and-paste this multi-line text, which has been formatted somewhat differently: We predict calc will print: QUESTION: What did calc print for you for the above test? And again if you copy-and-paste this 1-line into calc: Then we predict calc will print: QUESTION: What did calc print for you for the above test? Finally, exit calc and restart calc one more time: and paste this multi-line text: Then we predict calc will just print: QUESTION: What did calc print for you for the above test? Thanks for you help in testing this problem! We know we have asked you to do a lot of tests for us and we appreciate you taking the time to do that and report what happens. |
Correct.
No, it doesn't work as I expected.
No, it doesn't work as I expected.
Yes, it works as I expected.
Solus 4.5 GNOME 45.2 |
Exactly that
Exactly that
Exactly that
Exactly that
Exactly that
Exactly that
Hey, no problem. Thank you for taking your time to take a look at this. |
Thank you and .. interesting! So when you compile calc v2.14.0.10 from GitHub, that version of calc does not work as you expected when given a multi-line copy-and-paste. We are puzzled, then, as you why your screenshot of "version 2.14.0.10 - Last good version" worked as your expected. Assuming your distribution has the and assuming that you still have the executable for that "version 2.14.0.10 - Last good version" ... what does the follow command, executed from the directory of that "version 2.14.0.10 - Last good version" print: ldd ./calcREQUEST: After you verify that the "version 2.14.0.10 - Last good version" of calc that works, as you expect, with the multi-line copy-and-paste, please give us the output of the above ldd command. It is our guess that the calc you ran did NOT have GNU readline and/or GNU history linked into the binary for that "version 2.14.0.10 - Last good version". We expect that the |
Thank you, and well then !!! ... It seems that when calc in compiled and linked with GNU readline and GNU history, that such a calc, when given a multi-line paste ONLY processes the up the 1st line and that anything after the first line of a multi-line copy-and-paste is either NOT given to calc by the GNU library OR calc ignores the input beyond the first line of the multi-line copy-and-paste. Hummm .. interesting. |
Version 2.14.0.10 (last good version) Version 2.15.0.4 (latest version) Spot on. |
Thanks for the confirmation! Allow us to recap: The "version 2.14.0.10 - Last good version" screenshot showed a multi-line copy-and-paste that worked because that version of calc was not linked to the GNU readline / GNU history (nor ncurses). The "version 2.14.0.13 - First time bug spotted" showed a multi-line copy-and-paste that did NOT work because calc was linked to the GNU readline / GNU history. Sometime between version 2.14.0.10 and 2.14.0.13, problems with how calc used dynamic shared libraries were corrected. Calc started being linked by default to GNU readline and GNU history. Any modern (in the last few years) calc version that compiled and linked calc using a make line of the form: prevented calc from being linked to GNU readline / GNU history (nor ncurses), and thus allowed a multi-line copy-and-paste to calc to NOT work as expected. The same goes for any calc version that was obtained from the github repo via some "git checkout something", and then compiled and run as: The multi-line copy-and-paste did NOT work as expected because those version of calc were linked with and using GNU readline / GNU history. The bugWhen calc is linked with and uses GNU readline / GNU history, then for any multi-line copy-and-paste, only the first line is executed by calc. What needs to be fixedWhen a multi-line copy-and-paste is given to a calc linked with and using GNU readline / GNU history, is the reason why the text beyond the first line is NOT executed by calc because: A) Calc is ignoring or discarding the rest of the input buffer beyond the end of the first line, OR B) GNU readline / GNU history is not delivering data beyond the end of the first line, OR C) Something else The answer will help determine where a fix to calc's multi-line copy-and-paste unexpected behavior is needed. UPDATE 0Our guess is that neither GNU history, nor ncurses is a factor: only GNU readline. We have modified the bug title accordingly. Any guesses as to what might be wrong? We also wonder if other applications that use the GNU readline library have run into a similar multi-line copy-and-paste problem. |
lcn2
changed the title
lcn2
changed the title
|
No idea. I am not usually using any TUI apps, so not much info. But, I will tell you if i find one. Cheers! |
|
We are thinking about this issue .. and reached out to someone else to ask for advice. In the mean time if anyone else has some suggestions, please feel free to comment. |
|
Greetings from the "someone else" above 😉 I'm not aware of anything special that would be required to make multi-line paste with readline work. But I can reproduce this issue with calc 2.15.0.1 and readline 8.2 on Debian Linux. Out of curiosity, I also tried an older version of calc (2.12.7.2) linked against an older version of readline (7.0) and guess what: That worked as expected. I'll try to find out what exactly is causing this. Might take a few days though, until I can dedicate enough time to this. |
|
Additional data point: Old calc 2.12.7.2 with new readline 8.2 shows the problem as well, so it's triggered by the new readline version. |
|
This seems to be caused by readline now defaulting to bracketed paste mode: https://utcc.utoronto.ca/~cks/space/blog/unix/BashBracketedPasteChange Disabling bracketed paste as described there makes multi-line paste in calc work again for me. But that workaround shouldn't be required - I'll see what needs to be done in calc to make this work out of the box again. |
Thanks @gromit1811, looking forward to what you might find. |
|
OK, found out a bit more. Even though readline's API documentation explicitly says that Now, when calc's It would be relatively easy to modify calc to handle multiple lines returned by |
Interesting and thanks for your efforts so far, @gromit1811 .. please keep us posted and thanks 🙏 |
Fix for lcn2#138 According to https://lists.gnu.org/archive/html/bug-readline/2024-01/msg00000.html it's OK for readline() to return multi-line strings and/or newlines in case of bracketed paste (enabled by default since readline 8.1) and also in other situations even though its documentation explicitly states the opposite. So we need to handle this properly in calc instead of just using the first line and dropping the rest: Split the string returned by readline() into lines and return line by line with each invocation of hist_getline(), each possbily adding a terminating newline.
|
Seems this is intentional in Discussion on readline mailing list: https://lists.gnu.org/archive/html/bug-readline/2024-01/msg00000.html |
|
Thank you @gromit1811 for your research, for overcoming the We invite people to test the top of the master branch while we begin extensive testing. |
|
I have tried the master branch today. Now, copy-paste is working as expected but behaves slightly different than "last good version.webm". In that version if I copy this: config("mode", "fraction"),
(17/19)^23
print
base(16),
(19/17)^29
print
log(79.3i)
It will paste like this : ; config("mode", "fraction"),
; (17/19)^23
; print
; base(16),
; (19/17)^29
; print
; log(79.3i)
On master branch it will paste like this : ; config("mode", "fraction"),
(17/19)^23
print
base(16),
(19/17)^29
print
log(79.3i)
Is that intended? Is that what bracketed paste mean? It behaves the same as when I paste command from anywhere to terminal shell (bash, fish). I think this is a fine change. Making it a uniform experience inside terminal/shell. On another note , I noticed that when I copy some examples from README to master branch ; config("display", 70),
epsilon(1e-70),
sin(1)
0x1381e728a561e5a0ea8df7aacb4b8cab5c411f28ba271443a2c89af07/0x172ebad6ddc73c86d67c5faa71c245689c10795024000000000000000and this : ; config("mode", "fraction"),
(17/19)^23
print
base(16),
(19/17)^29
print
log(79.3i)
19967568900859523802559065713/257829627945307727248226067259
0x9201e65bdbb801eaf403f657efcf863/0x5cd2e2a01291ffd73bee6aa7dcf7d1
0x6561fca0841af56ca43bd7c47ffb50682b178266a95ae598e0361dbed27/0x35613870446fac65821ecbc6932bc881e4aa39bec57dc801ceba56b99ce+0x1235203c206c24ae36b4a5f19cca9897111179488ef6258a159b3472005/0x1ab09c382237d632c10f65e34995e440f2551cdf62bee400e75d2b5cce7iIs there a change in default settings ? Cheers! Update 1: |
|
At first glance of comment 1880373356, @malfisya, the change seems like a good direction. We have left the 👀 marker on your comment, because we intend to give your comment a 2nd glance and perhaps even a 3rd glance. If you look at the single line "model", where the copy-and-paste is treated in a input single line, one has to treat those newlines inside the copy-and-paste buffer as it's separator tokens. So in this case the copy-and-paste buffer would be equivalent to this single line command: Such a calc line above is a "syntax error". You are correct that the current master branch treats copy-and-paste buffer newlines as if they were a ";" characters: Interactive input consists of text (w/o a newline) followed by a newline. Copy-and-paste of multiple lines is like one were you enter each line of text, one newline terminated line at a time. It is likely that we might need to document the behavior of the master branch, perhaps in the Is that ideal? Perhaps it could be argued that it is not ideal, but at least it is not the "unexpected behavior/bug" that it was before the pull request by @gromit1811, and the behavior is documentable. Well that is our initial take on the situation. Comments, of course, are welcome. |
|
Thank you @malfisya for raising this issue. Thank you @gromit1811 for your recommended fix. See commit bb3b861 and |
Describe the bug
After version 2.14.10, pasting text (like from the example in readme) to interactive shell of
calchandled differently/incorrectly.To Reproduce
calcversion after 2.14.0.10Expected behavior
The formatting get perserved and function get executed correctly
Screen shots
version 2.14.0.10 - Last good version
last good version.webm
version 2.14.0.13 - First time bug spotted
first bug spotted.webm
version 2.15.0.4 - Latest version available
latest version.webm
Execution environment (please complete the following information):
Other Comment
Happy to provide another information if needed. Cheers!
The text was updated successfully, but these errors were encountered: