Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
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/
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
On Tue, Dec 8, 2020 at 6:33 PM Lawrence Velázquez wrote: > > On Dec 8, 2020, at 3:52 PM, Testing Purposes < > raspberry.teststr...@gmail.com> wrote: > > > > --- > > bash --readline-version > > This instance of GNU Bash is using the GNU Readline library, version 8.1 > > --- > > > > That would certainly be a more intuitive and human-friendly method. > > 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. > > vq Subconsciously, I must have regarded Bash's version output as almost sacred — so I honestly didn't even think of that. But yes, I agree! That would be the most elegant solution by far! (And, I assume, fairly easy to implement.)
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 2020/12/08 06:28, Greg Wooledge wrote: The end result is that it's basically impossible to preserve the original whitespace of your source material across a terminal copy/paste operation. So don't count on that. If you use a random terminal to copy/paste, sure, but if you use a specific product that maintains fidelity, then it's not true. Especially nice are term-progs that automatically reflow text *as you resize* the terminal. Like if you see 100 characters written to an 80-column terminal, that line wraps the text, when you expand the width, you retain the original white space. That's why programs that don't preserve what you wrote are annoying. And note -- you see the reflow in real-time as you change dimensions -- not just at the end. Imagine working on a terminal that only displayed upper case even if the differentiation was saved when stored. You can't really see the text as "it is" when you enter it or re-edit it. With it putting in something different on display than what is really there, you get things like (tab chars between each letter): echo "a b c d e f g h i j k l m n o p q r s t a b c d e f g h i j k l m n o p q r s t" a b c d e f g h i j k l m n o p q r s t a b c d e f g h i j k l m n o p q r s t If you re-edit a line with tabs in it that displays like it does in the bottom line, above (tabs ever 2 spaces), the re-edited "line" takes up 4 lines.
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
> On Dec 8, 2020, at 3:52 PM, Testing Purposes > wrote: > > FINAL THOUGHT — BASH FEATURE SUGGESTION: > > At the moment, this external command line reveals the version of Readline > that Bash is using: > > gdb bash -batch -ex 'printf "%04x\n", (int) rl_readline_version' > > Given how utterly fundamental Readline is to the functioning of Bash, > perhaps it should become a built-in option of Bash itself — like this: > > --- > bash --readline-version > This instance of GNU Bash is using the GNU Readline library, version 8.1 > --- > > That would certainly be a more intuitive and human-friendly method. 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. vq
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
FINAL THOUGHT — BASH FEATURE SUGGESTION: At the moment, this external command line reveals the version of Readline that Bash is using: gdb bash -batch -ex 'printf "%04x\n", (int) rl_readline_version' Given how utterly fundamental Readline is to the functioning of Bash, perhaps it should become a built-in option of Bash itself — like this: --- bash --readline-version This instance of GNU Bash is using the GNU Readline library, version 8.1 --- That would certainly be a more intuitive and human-friendly method.
Re: Bash-5.1 release available
Op 08-12-2020 om 15:12 schreef Chet Ramey: > On 12/8/20 6:18 AM, Benno Schulenberg wrote: >> Yes, but for translators that is too far back -- too much time passes >> before the actual release happens. > > That doesn't make any sense. If there are any changed strings, the > translators should have as much time to update as possible. No. Translators should have limited time: it works better, psychologically. > It's not > as if the translations will change dramatically before the release, > if at all. But *if* any string would change, the translators would like to update their translation. So it's better to announce closer before the release. Benno
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Tue, Dec 08, 2020 at 09:07:33AM -0500, 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. In addition to what I said earlier, there is a distinction between things that you *typed* in bash/readline, and then tried to copy with the mouse, and text that was generated by a command (e.g. cat yourscript), which you then tried to copy. And if you're actually typing in a text editor, rather than in bash, then obviously the behavior of the editor is what matters. The end result is that it's basically impossible to preserve the original whitespace of your source material across a terminal copy/paste operation. So don't count on that. There's a *reason* bash introduced the $'\t' quoting. Use it, rather than using literal tab characters.
Re: Bash-5.1 release available
On 12/8/20 6:18 AM, Benno Schulenberg wrote: Op 07-12-2020 om 20:39 schreef Chet Ramey: On 12/7/20 1:47 PM, Benno Schulenberg wrote: It would be nice if the Translation Project would get a CC for the rc1 or rc2 release of bash, not for the final release. I copied coordina...@translationproject.org for bash-5.1-alpha 17 June 2020 Yes, but for translators that is too far back -- too much time passes before the actual release happens. That doesn't make any sense. If there are any changed strings, the translators should have as much time to update as possible. It's not as if the translations will change dramatically before the release, if at all. -- ``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/
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
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. 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. -- ``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/
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Tue, Dec 08, 2020 at 08:07:18PM +0700, pepa65 wrote: > On 08/12/2020 19.55, Greg Wooledge wrote: > > Some terminals, when fed a tab character, will preserve that knowledge > > in memory; then, when you copy text from that part of the terminal > > window using your mouse, the terminal will put a tab byte into the > > selection/clipboard. > > Interesting! Which terminal does that?? It seem that ``gnome-terminal'' and ``mate-terminal'' do so. while ``xterm'', ``rxvt'' and ``konsole'' does'nt. -- Félix Hauri -- http://www.f-hauri.ch
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 08/12/2020 19.55, Greg Wooledge wrote: > Some terminals, when fed a tab character, will preserve that knowledge > in memory; then, when you copy text from that part of the terminal > window using your mouse, the terminal will put a tab byte into the > selection/clipboard. Interesting! Which terminal does that?? (Slightly OT?) Peter
Re: [EXT] Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
On Dez 08 2020, 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.
This is all about C, so mathematics don't come into play.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Mon, Dec 07, 2020 at 05:02:35PM -0800, L A Walsh wrote: > If I type in ( + are keypresses) > > if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi > > bash displays: > > if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi > ok Bash doesn't "display" things. Your terminal displays that. > if I now copy the 'if' line and paste it > > if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi > notok Some terminals, when fed a tab character, will preserve that knowledge in memory; then, when you copy text from that part of the terminal window using your mouse, the terminal will put a tab byte into the selection/clipboard. Other terminals, when fed a tab character, will just dump out a bunch of spaces, and will not remember that there was originally a tab character as part of their input. Then, if you copy that part of the text, you'll just get a bunch of spaces instead of the original tab character.
Re: [EXT] Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
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.
Re: Bash-5.1 release available
Op 07-12-2020 om 20:39 schreef Chet Ramey: > On 12/7/20 1:47 PM, Benno Schulenberg wrote: >> It would be nice if the Translation Project would get a CC for >> the rc1 or rc2 release of bash, not for the final release. > > I copied coordina...@translationproject.org for > > bash-5.1-alpha 17 June 2020 Yes, but for translators that is too far back -- too much time passes before the actual release happens. > and assumed that would start the update process. The translatable > strings change very little, if at all, after an alpha release. That's the point: if some string *does* change, the TP would like to be notified of the changed POT file. So it's better not to bother with announcing the alpha and the beta to the TP, but just the rc1. > I can add you for release candidates as well if you'd like. Please CC me for just the rc1. Not for alpha or beta. Benno
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
Just use history or fc -l to display the line as is. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 08/12/2020 01:02 am, L A Walsh wrote: If I type in ( + are keypresses) if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi bash displays: if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi ok if I now copy the 'if' line and paste it if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi notok if I take the same line from an editor like gvim, it works. If the test line is in a file, and I use 'cat file' and copy/past the resulting line, it works. It is only when bash is displaying the line that it doesn't work. The problem is that bash isn't displaying a 'tab' character where one was typed. 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. Can this be fixed -- maybe with an option in 'shopt', for those who might be using a non-expanding terminal, but anyone using an xterm/linux compatible terminal should get the expansions from their terminal. Where this can be even more annoying is if your terminal's response to a tab is different than that used on old-hardware terminals. Thanks, -l Try Ctrl-V before hitting . -- Chris Elvidge England
Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)
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. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
