Re: [EXT] Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
On 2020/12/08 04:40, Greg Wooledge wrote:
On Tue, Dec 08, 2020 at 09:47:05AM +0100, Andreas Schwab wrote:
On Dez 07 2020, Testing Purposes wrote:
From an integer standpoint, I know that 08 (with one leading zero) is the
same as 8.
Nope, it is a syntax error.
In a bash math context or in C, 08 is indeed a syntax error, as it is
an octal integer constant with an invalid digit ("8").
In mathematics, 08 is just 8.
But the subject says 0x08(01), not 08.
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 2020/12/08 06:07, Chet Ramey wrote: On 12/7/20 8:02 PM, L A Walsh wrote: The problem is that bash isn't displaying a 'tab' character where one was typed. It's readline and redisplay. Readline expands tabs to spaces using an internal tab stop of 8. This allows it to be sure of the physical cursor location, especially when you're doing things like wrapping lines, and insulates it from varying terminal behavior. *snark* That's nice, why not just display 'X' instead of spaces? Wouldn't that also insulate readline from varying terminal behavior? *not really, but...* I'm not sure it is the place of a an in-line-editor to override terminal features. However, as readline is an editor and most editors allow setting the tabs (as well as whether or not to use hard-tabs or expand them). If readline has to "insulate", just like vi/vim -- have the tabstop and whether to expand be in a startup file like .inputrc. Right now, .inputrc has the facility to define how characters are to be interpreted. Why not put the option to expand w/spaces in there, as well as what a tab character expands (or maps to). Bash also overrides existing standards with regards to tabs wrapping. It seems that many or most terminals (xterm compat, linux console-compat, etc) don't wrap to the next line when a tab is pressed. The reasoning for that was that tab was supposed to skip to the next field in the same line. Wrapping is beyond the scope of function for tabbing. With many (most?) terminal windows these days, especially Unicode-enabled ones, the terminal has to read what is on the screen to be able to read the binary code of whatever is displayed on the screen, Otherwise, it wouldn't be able to read typed unicode. This is not relevant to the issue. It was meant to illustrate that terminals are using the binary representation of the characters typed -- and that arbitrarily changing the binary representation (like tabs->spaces) will mess up / corrupt the user's output stream.
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
On Tue, Dec 8, 2020 at 8:49 PM Chet Ramey wrote: > On 12/8/20 6:32 PM, Lawrence Velázquez wrote: > > > Such information could just be added to the output of bash --version > > (or perhaps as a shell variable à la BASH_VERSION). There is no > > need for a separate command-line option. > > Why, though? What is valuable about knowing which version of readline is > linked with a particular bash binary? (Or, more accurately, knowing > whether or not that bash binary is linked with an external version of > readline, knowing that specific bash versions are always shipped with > specific readline versions.) > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ -- BACKGROUND: -- In Appendix A of the official Bash manual, it says that "suggestions and ‘philosophical’ bug reports" are requested — so please bear with me while I get a bit philosophical about the experience that led to this thread. I'll begin with a bit of demographic perspective: If we divide the entire Bash user base into three categories — beginner, intermediate and advanced — I would arbitrarily guess that only 2% are truly "advanced". This elite demographic would certainly *NOT* include me — but it would include many of the people on the bug-bash mailing list. They live and breathe this stuff — they have a deep understanding of Bash and its configuration. They also have a mastery of the C language and are therefore able to properly interpret the implications of the Bash source code. The overwhelming majority of Bash users, however, do not fit this description. - MY EXPERIENCE: - When Bash 5.1 came out two days ago, I was excited to build it and try it! However, since I knew the latest version of Bash was dependent on the latest version of Readline in order to work properly, it was reasonable for a non-expert like me to assume that Readline also needed to be built. This is especially true since I could find no step-by-step building instructions or clear-cut requirements in either the online or offline documentation. Nonetheless, as an experiment, I went ahead and built Bash 5.1 anyway — without first building its core dependency, Readline 8.1. I was surprised to discover that everything worked perfectly! And, when I pasted a script into LXTerminal, all the pasted text was selected / highlighted by default — a brand-new behavior. That was my tip-off that my build of Bash 5.1 was somehow using Readline 8.1 — even though I had not consciously done anything to build or install it. So, on my Debian Buster-based Raspberry Pi OS system, I ran this command line to search for all Readline-related packages: sudo apt list --installed | grep readline And this was the output: libreadline-dev/stable,now 7.0-5 arm64 [installed] libreadline7/stable,now 7.0-5 arm64 [installed] readline-common/stable,stable,now 7.0-5 all [installed] And indeed, 7.0 is the Readline version that currently comes with Debian: https://packages.debian.org/source/buster/readline Yet I also know that 5.0 is the Bash version that currently comes with Debian — so I was a bit surprised that Debian's version of Bash wasn't accompanied by its "sister" package — Readline 8.0: https://packages.debian.org/buster/bash -- CONCLUSION: -- It was at this point that I realized the latest version of Readline must have been included with the Bash source code — and that I didn't need to do anything more. Nonetheless, like any good "amateur scientist" that wasn't sure about his theory, it was only natural to see if I could confirm my hypothesis. Bash is a critical piece of software to me — so I wanted to make sure that everything was proper. I assumed it would be a simple task. But I was surprised to discover that there was no easy way to determine what version of Readline my copy of Bash was using — even though Bash is intimately dependent on having the proper version of Readline. Instead, on a third-party website, after a full hour of searching, I finally discovered an obscure external method to confirm that my copy of Bash was using the right version of Readline. A further layer of complication, as this thread clearly illustrates, is that the output of that external method is not intuitive to the 98% of non-experts. And there it is — the full story of the multi-hour rabbit hole I fell into in my seemingly simple quest — to determine what version of Readline that Bash is using! I'm obviously biased by my personal experience — and how involved it turned out to be. Nonetheless, I think it would be very helpful if that fundamental information could eventually be added to the output of: bash --version
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
On 12/9/20 3:55 PM, Testing Purposes wrote:
In Appendix A of the official Bash manual, it says that "suggestions and
‘philosophical’ bug reports" are requested — so please bear with me while I
get a bit philosophical about the experience that led to this thread.
Sure.
-
MY EXPERIENCE:
-
When Bash 5.1 came out two days ago, I was excited to build it and try it!
However, since I knew the latest version of Bash was dependent on the
latest version of Readline in order to work properly, it was reasonable for
a non-expert like me to assume that Readline also needed to be built. This
is especially true since I could find no step-by-step building instructions
or clear-cut requirements in either the online or offline documentation.
That's an interesting perspective, since the INSTALL file covers this, and
the steps ("configure" ; "make") are contained in it.
Nonetheless, as an experiment, I went ahead and built Bash 5.1 anyway —
without first building its core dependency, Readline 8.1.
`configure' takes care of this for you. Since you didn't specify that you
wanted to use a separate version of readline (INSTALL tells you how to do
this), it made sure to use the appropriate included version. If you had
needed to build and install some dependency, or specified the wrong
version, configure would have told you.
I was surprised to discover that everything worked perfectly!
I hope it wasn't that big a surprise.
And, when I pasted a script into LXTerminal, all the pasted text was
selected / highlighted by default — a brand-new behavior. That was my
tip-off that my build of Bash 5.1 was somehow using Readline 8.1 — even
though I had not consciously done anything to build or install it.
That's the idea -- you don't have to.
So, on my Debian Buster-based Raspberry Pi OS system, I ran this command
line to search for all Readline-related packages:
sudo apt list --installed | grep readline
And this was the output:
libreadline-dev/stable,now 7.0-5 arm64 [installed]
libreadline7/stable,now 7.0-5 arm64 [installed]
readline-common/stable,stable,now 7.0-5 all [installed]
And indeed, 7.0 is the Readline version that currently comes with Debian:
https://packages.debian.org/source/buster/readline
Yet I also know that 5.0 is the Bash version that currently comes with
Debian — so I was a bit surprised that Debian's version of Bash wasn't
accompanied by its "sister" package — Readline 8.0:
https://packages.debian.org/buster/bash
Since you are savvy enough to check that far, you could have looked at the
bash binary that you had just built and checked whether or not it used any
external libraries, using `ldd'.
It was at this point that I realized the latest version of Readline must
have been included with the Bash source code — and that I didn't need to do
anything more.
Nonetheless, like any good "amateur scientist" that wasn't sure about his
theory, it was only natural to see if I could confirm my hypothesis.
Absolutely. I think reading INSTALL would have cleared that up for you,
especially the description of the `--with-installed-readline' configure
option.
Bash is a critical piece of software to me — so I wanted to make sure that
everything was proper. I assumed it would be a simple task.
But I was surprised to discover that there was no easy way to determine
what version of Readline my copy of Bash was using — even though Bash is
intimately dependent on having the proper version of Readline.
The thing is, configure takes care of that for you so you don't have to
figure it out yourself.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
