Re: Should the readline *-meta flags reset when $LANG changes?
2022年8月12日(金) 4:22 Chet Ramey : > >> Often enough to make a difference? > > > > My `bind -x' functions use `LC_ALL=' and `LC_CTYPE=C' for every > > keystroke, for example, in combination with `builtin read'. They also > > use `LC_ALL=' for other purposes for mostly every keystroke. Some vi > > binding also uses `LC_CTYPE=C'. My completion functions also change > > `LC_ALL` and `LC_CTYPE`. For example, `LC_CTYPE=C' is used in > > calculating a PJW hash code of a given string. I haven't carefully > > checked, but there are probably other cases of changing `LC_CTYPE'. > > Also, `LC_ALL=' is used everywhere. > > So you're using `read -e'? No. > Otherwise, these suggest that solution 4 is most appropriate. > > >> Across multiple calls to readline? > > > > I think I am missing the point. What does ``multiple calls to > > readline'' mean? Is the situation different from a single call to > > readline? > > It informs the solution. If I choose option 4, for instance, none of these > matter. Ah! Now I understand it. I was misunderstanding option 4. Option 4 works for me. > Where I think we're converging is to use option 4, and -- as long as > LC_ALL/LC_CTYPE/LANG don't change -- not modifying these variables when > readline() is called. I can document that these variables are dependent on > the current locale, and if the locale changes, those variables will need > to be adjusted. If the locale doesn't change between calls to readline(), > you don't need to do anything. I agree with option 4. Thank you for all your explanations. -- Can we also change the behavior of TERM in a similar way with option 4? Currently, a temporal change of TERM clears keybindings of some keys (home, end, right, left, etc.) even when the temporal change does not survive across multiple calls of readline: $ bash-dev --norc $ echo "$TERM" screen.xterm-256color $ bind '"\e[1~": bell' $ bind -q beginning-of-line beginning-of-line can be invoked via "\C-a", "\eOH", "\e[H". $ TERM=dumb infocmp >dumb.ti $ bind -q beginning-of-line beginning-of-line can be invoked via "\C-a", "\eOH", "\e[1~", "\e[H". There are only a few places where TERM can be changed in my configuration (unlike LANG/LC_* which are changed in many places), so I can work around them by saving and restoring the keybindings, yet I think it is more reasonable that automatic rebinding on TERM changes only happens when the change survives to the next call of readline (as option 4 for the locale variables). -- Koichi
Re: Should the readline *-meta flags reset when $LANG changes?
On 8/10/22 10:59 PM, Koichi Murase wrote:
2022年8月10日(水) 23:21 Chet Ramey :
Does it mean custom values of these readline variables will be lost
every time LANG or LC_{CTYPE,ALL} is changed even if a user or program
intentionally sets them up?
It means those settings will now mirror the locale.
We often temporarily change LANG or LC_* to perform some binary
operations [such as counting the number of bytes of data and safely
removing trailing x from the result of $(command;printf x)].
Do you often do this in interactive shells?
Yes, but I don't mean I directly type the above kinds of commands in
the command line and run them, but I use them in the functions called
through `bind -x'. Also, the above cases (counting bytes and removing
trailing x) are just examples; I set locale variables for various
purposes in the actual codes. For example, I often type and run
commands of the form
LANG=C some-commands-or-functions
to get the default error messages that are not locale-specific (though
I could use LC_MESSAGES=C instead, yet LANG=C is easier to type for
me). I normally use the locale LANG=ja_JP.UTF-8 by default, so the
commands output error messages in Japanese by default. This is not
useful when I would like to search for the solution on the internet
because there is almost no information on the Japanese error message.
So let's talk through these, since it doesn't seem like these things will
be affected by the realistic available solutions.
Often enough to make a difference?
My `bind -x' functions use `LC_ALL=' and `LC_CTYPE=C' for every
keystroke, for example, in combination with `builtin read'. They also
use `LC_ALL=' for other purposes for mostly every keystroke. Some vi
binding also uses `LC_CTYPE=C'. My completion functions also change
`LC_ALL` and `LC_CTYPE`. For example, `LC_CTYPE=C' is used in
calculating a PJW hash code of a given string. I haven't carefully
checked, but there are probably other cases of changing `LC_CTYPE'.
Also, `LC_ALL=' is used everywhere.
So you're using `read -e'? Otherwise, these suggest that solution 4 is
most appropriate.
Across multiple calls to readline?
I think I am missing the point. What does ``multiple calls to
readline'' mean? Is the situation different from a single call to
readline?
It informs the solution. If I choose option 4, for instance, none of these
matter. They will all happen as part of a single call to readline, and the
normal shell execution will ensure that the modified locale variables are
temporary.
Hmm, I think I first need to make it clear that the behavior of my
code, which is supposed to be sourced in an interactive session by
users, is unaffected by these readline settings.
OK.
I just do not want
to break or change the existing user settings inside the functions
that I provide. The behavior of my functions is unaffected (except
for « bind -x '"\M-x":' » which is affected by `convert-meta',
for which I already implemented a workaround) because it doesn't try
to communicate with readline inside a single call of `bind -x'. The
problem is that, with the new automatic adjustment of these readline
variables, the settings by users can be lost after using `LC_ALL=' or
`LC_CTYPE=C' inside my functions.
Only if those functions recursively call readline() (which is a bad idea
anyway) somehow, or leave the modified settings in the user's environment
for the next call to readline(). This is the point of my question.
I believe this is a general problem for writers of Bash
configurations. `bash_completion' also uses `LC_CTYPE=C' and
`LC_ALL=C'. The behavior of such configurations itself will be
unaffected by the change of readline settings, but they need to
implement special treatment to preserve the user settings if the user
settings will be lost by changing locales.
This scenario is not relevant with option 4, unless bash-completion leaves
its modified LC_CTYPE and LC_ALL settings in the user's environment after
the call to readline() completes. If it did, I imagine people would have
complained by now.
And, if the change is intended to be temporary, why would you not
want the relevant readline variables to reflect the locale when you
were finished?
Because I would not like to break the users' settings. In general, a
third-party Bash configuration should not overwrite the users'
settings as far as the configuration does not need the setting.
So that argues against option 3, and in favor of option 4.
Also, if these readline variables would be cleared every time, it
seems to me that these readline variables would be effectively
unconfigurable and would lose the point of their existence, or we
could not touch LANG or LC_* at all after the initial setup.
The one caveat we would have to add is to tell users they have to
restore custom values of these readline variables if they change LC_ALL,
LC_CTYPE, or LANG from one call to readline to the next. They're already
auto-set when readline
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Robert Elz wrote in <16667.1660234...@jacaranda.noi.kre.to>: |Date:Thu, 11 Aug 2022 16:22:12 +0200 |From:Steffen Nurpmeso |Message-ID: <20220811142212.jhlpj%stef...@sdaoden.eu> | | |||> Hm. Well i agree that precedence rules which loose a construct |||> completely (in that =5 is lost in I=5?I:J) is weird, but other | |I seem to have lost/missed whatever message that was originally in, but |nothing is lost there | | I=5?I:J |is | I = ( 5 > I : J ) | |and since 5 is true, that amounts to | | I = I | |There's nothing weird about that at all, no more than | | 3+2 * 7 | |giving 17, rather than 35 is weird. Precedence matters. Yes. Confusion. Nothing but confusion. And not waiting for settlement. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Chet Ramey wrote in : |On 8/11/22 10:00 AM, Steffen Nurpmeso wrote: |. |> Can you also explain this: |> |>$ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1*=1?I1:I3 ))>";echo \ |>"<$I1><$I2><$I3>"' |><100> |><100><10> | |I1 *= 1?I1:I3 |I1 *= I1 |I1 = I1 * I1 |I1 = (I2=10) * (I2=10) |I1 = 10 * 10 |I1 = 100 | |Along the way, I2 is set to 10. Twice. | |>$ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1=1?I1:I3 ))>";echo \ |>"<$I1><$I2><$I3>"' | |I1 = 1?I1:I3 |I1 = I1 |I1 = (I2 = 10) |I1 = 10 | |Ditto about I2, but once. Yes, thank you. I had a fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" enlightenment in the meantime (it was a simple precedence bug, a single line fix, i should have sat down and let it rest for a while, for weeks i was looking at myriads of Dijkstra stack pop debug messages, maybe that explains a bit). And it was all my fault. bash is absolutely on the correct side -- luckily there was a fully fledged parser i could use to test against! Thank you. Sorry for all the noise. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Steffen Nurpmeso wrote in
<20220811140049.avjlp%stef...@sdaoden.eu>:
|Koichi Murase wrote in
| :
||2022年8月11日(木) 9:01 Steffen Nurpmeso :
...
||I think both your version and recent versions of busybox sh are broken.
It was a one line fix.
- while(lprec > a_SHEXP_ARITH_PREC_PAREN_LEFT &&
-lprec != a_SHEXP_ARITH_PREC_COND){
+ while(lprec > a_SHEXP_ARITH_PREC_COND){
Again thank you very much for your analysis, Murase-San.
Warm greetings from Germany.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Date:Thu, 11 Aug 2022 16:22:12 +0200 From:Steffen Nurpmeso Message-ID: <20220811142212.jhlpj%stef...@sdaoden.eu> | |> Hm. Well i agree that precedence rules which loose a construct | |> completely (in that =5 is lost in I=5?I:J) is weird, but other I seem to have lost/missed whatever message that was originally in, but nothing is lost there I=5?I:J is I = ( 5 > I : J ) and since 5 is true, that amounts to I = I There's nothing weird about that at all, no more than 3+2 * 7 giving 17, rather than 35 is weird. Precedence matters. kre
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
On 8/11/22 10:00 AM, Steffen Nurpmeso wrote: . Can you also explain this: $ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1*=1?I1:I3 ))>";echo "<$I1><$I2><$I3>"' <100> <100><10> I1 *= 1?I1:I3 I1 *= I1 I1 = I1 * I1 I1 = (I2=10) * (I2=10) I1 = 10 * 10 I1 = 100 Along the way, I2 is set to 10. Twice. $ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1=1?I1:I3 ))>";echo "<$I1><$I2><$I3>"' I1 = 1?I1:I3 I1 = I1 I1 = (I2 = 10) I1 = 10 Ditto about I2, but once. -- ``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: cut loadable outputs extra newlines
On 8/10/22 4:50 PM, Geir Hauge wrote: Bash Version: 5.2 Patch Level: 0 Release Status: rc3 Description: examples/loadables/cut.c uses zgetline, which includes the newline delimiter in the line it reads, but the rest of the code expects the line to not contain the newline. Thanks for the report. -- ``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: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Greg Wooledge wrote in : |On Thu, Aug 11, 2022 at 04:04:57PM +0200, Steffen Nurpmeso wrote: |> Hm. Well i agree that precedence rules which loose a construct |> completely (in that =5 is lost in I=5?I:J) is weird, but other | |What's that even supposed to *be*? You're assigning I=5 and then |checking whether the assignment actually worked? | |If you intended it to be i==5 ? i : j then you really ought to |put some parentheses in it, so people like me who haven't memorized |the C precedence rules for decades won't have to dig up a manual to |figure out whether it's (i==5) ? i : j or i == (5 ? i : j). It is part of a test script, and the thing tested is actually recursive expansion. Aka, that it does not happen when an assignment is performed. More precisely, an expansion that modifies settings that affect further expansions. I am not subscribed to this list btw. Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
On Thu, Aug 11, 2022 at 04:04:57PM +0200, Steffen Nurpmeso wrote: > Hm. Well i agree that precedence rules which loose a construct > completely (in that =5 is lost in I=5?I:J) is weird, but other What's that even supposed to *be*? You're assigning I=5 and then checking whether the assignment actually worked? If you intended it to be i==5 ? i : j then you really ought to put some parentheses in it, so people like me who haven't memorized the C precedence rules for decades won't have to dig up a manual to figure out whether it's (i==5) ? i : j or i == (5 ? i : j).
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Robert Elz wrote in <26517.1660182...@jacaranda.noi.kre.to>: |I would agree that the values bash is producing don't make a lot |sense, but I don't think you can say that either is correct - one |may be more desirable than the other, but that's it. Hm. Well i agree that precedence rules which loose a construct completely (in that =5 is lost in I=5?I:J) is weird, but other than that there is a logical path to correctness. And my code still fails (unfortunately, and also just like others'). |Var expansion (not $I but just I) is defined for $(( )) only when |I contains a integer constant (optionally signed) - anything else |supported is an extension, and can be defined to work however the |implementor wants it to work. Well here i disagree. Of course plain integer is the only thing that is defined, but if you support recursive expansion, then that should work correctly, then. I still have your mail in my queue, it's been five weeks of which i spent more than two with that Dijkstra thing, but now i have NetBSD 9.3 to be installed, any maybe i can come back with a report also to you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Arithmetic expression: recursive VAR evaluation suppresses desired VAR assignment
Koichi Murase wrote in : |2022年8月11日(木) 9:01 Steffen Nurpmeso : |> #?0|kent:tmp$ /x/src/busybox.git/busybox sh xxx.sh |> <6><0><6> |> <1><1><5> | |It seems your busybox interprets« I1=0?I1:I3 » as « (I1=0)?I1:I3 », |but this violates POSIX XCU 2.6.4 and XCU 1.1.2. Also, the above Hm. Sigh. Yes, you are of course right. Thanks for the clarification. |behavior doesn't seem to be reproduced by recent versions of busybox. Yes, that could eventually be a contribution of mine. Because.. ... |The behavior of recent versions of busybox is still broken. The third ... |> I think the busybox variant is correct. | |I think both your version and recent versions of busybox sh are broken. Yes. The Dijkstra algorithm requires quite some contortions to work with anything beyond binary. I thought i had it now, but obviously i need a third iteration round. Thanks again. Can you also explain this: $ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1*=1?I1:I3 ))>";echo "<$I1><$I2><$I3>"' <100> <100><10> $ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1=1?I1:I3 ))>";echo "<$I1><$I2><$I3>"' <10> <10><10> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
