Re: Read Prompt Width Miscalculation (Non-Printing Characters)
... or you can write your prompt string as you would write PS1 and use the
${word@P} expansion when you pass it as an argument to `read' (preferred).
This is new to me. Thank you.
Should I write a patch for the man page?
Re: Read Prompt Width Miscalculation (Non-Printing Characters)
On 12/29/22 5:37 AM, The Administrator wrote:
... or you can write your prompt string as you would write PS1 and use
the ${word@P} expansion when you pass it as an argument to `read'
(preferred).
This is new to me. Thank you.
Should I write a patch for the man page?
The parameter transformations are already documented.
--
``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/
Arithmetic expression: evaluation order bug
Hello.
Name: bash
Path: /usr/ports/core
Version: 5.2.15
Release: 1
$ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j
60
60,50
$ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j
50
50,40
$ cat t.c
#include
int main(void){
int i, j;
i = 10, j = 20;
i += j += i += j;
printf("%d,%d\n", i, j);
i = 10, j = 20;
i += j += i += i;
printf("%d,%d\n", i, j);
return 0;
}
$ tcc -run t.c
80,50
60,40
--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: evaluation order bug
On Thu, Dec 29, 2022 at 06:23:09PM +0100, Steffen Nurpmeso wrote:
> Hello.
>
> Name: bash
> Path: /usr/ports/core
> Version: 5.2.15
> Release: 1
>
> $ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j
> 60
> 60,50
> $ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j
> 50
> 50,40
You are modifying something that is used elsewhere in an expression. I am not
surprised that you do not get what you expect; others might expect something
different.
At most there should be a note in the documentation that this sort of thing
leads to undefined behaviour -- that is what happens in other languages.
This is very much not a bug in bash.
C does it differently. I would not be surprised to see different C compilers
produce different results or different results with different levels of
optimisation.
> $ cat t.c
> #include
> int main(void){
>
> int i, j;
>
> i = 10, j = 20;
> i += j += i += j;
> printf("%d,%d\n", i, j);
>
> i = 10, j = 20;
> i += j += i += i;
> printf("%d,%d\n", i, j);
>
> return 0;
> }
> $ tcc -run t.c
> 80,50
> 60,40
>
> --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)
>
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include
Re: Arithmetic expression: evaluation order bug
Alain D D Williams wrote in <20221229173548.gw16...@phcomp.co.uk>: |On Thu, Dec 29, 2022 at 06:23:09PM +0100, Steffen Nurpmeso wrote: |> Hello. |> |> Name: bash |> Path: /usr/ports/core |> Version: 5.2.15 |> Release: 1 |> |> $ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j |> 60 |> 60,50 |> $ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j |> 50 |> 50,40 | |You are modifying something that is used elsewhere in an expression. \ |I am not |surprised that you do not get what you expect; others might expect \ |something |different. | |At most there should be a note in the documentation that this sort of thing |leads to undefined behaviour -- that is what happens in other languages. | |This is very much not a bug in bash. I very much disagree. My mailer's $(()) evaluator also does this right. (And busybox's one, if it gets accepted.) |C does it differently. I would not be surprised to see different C \ |compilers |produce different results or different results with different levels of |optimisation. Come on. Be a brave man. --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: evaluation order bug
On Thu, Dec 29, 2022 at 05:35:48PM +, Alain D D Williams wrote: > On Thu, Dec 29, 2022 at 06:23:09PM +0100, Steffen Nurpmeso wrote: > > Hello. > > > > Name: bash > > Path: /usr/ports/core > > Version: 5.2.15 > > Release: 1 > > > > $ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j > > 60 > > 60,50 > > $ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j > > 50 > > 50,40 > > You are modifying something that is used elsewhere in an expression. I am not > surprised that you do not get what you expect; others might expect something > different. I don't think that is correct. Unlike a++ - --a which is unspecified in C because the order of evaluation of the lhs and rhs of the - operator is unspecified, the order of evaluation of i += j += i += i or i += (j += (i += i)) is well defined and in no way ambiguous. emanuele6
Re: Arithmetic expression: evaluation order bug
On Thu, Dec 29, 2022 at 09:09:25PM +0100, Emanuele Torre wrote: > On Thu, Dec 29, 2022 at 05:35:48PM +, Alain D D Williams wrote: > > On Thu, Dec 29, 2022 at 06:23:09PM +0100, Steffen Nurpmeso wrote: > > > Hello. > > > > > > Name: bash > > > Path: /usr/ports/core > > > Version: 5.2.15 > > > Release: 1 > > > > > > $ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j > > > 60 > > > 60,50 > > > $ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j > > > 50 > > > 50,40 > > > > You are modifying something that is used elsewhere in an expression. I am > > not > > surprised that you do not get what you expect; others might expect something > > different. > > I don't think that is correct. > > Unlike a++ - --a which is unspecified in C because the order of > evaluation of the lhs and rhs of the - operator is unspecified, the > order of evaluation of i += j += i += i or i += (j += (i += i)) is > well defined and in no way ambiguous. No. i += j += i += i does not contain a sequence point so there is no guarantee that anything is completed (eg storing a value in variable i) before another part (getting a value from variable i) is evaluated. https://stackoverflow.com/questions/3575350/sequence-points-in-c https://c-faq.com/expr/seqpoints.html -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Arithmetic expression: evaluation order bug
Alain D D Williams wrote in <20221229204511.gc16...@phcomp.co.uk>: ... |No. i += j += i += i does not contain a sequence point so there is \ |no guarantee |that anything is completed (eg storing a value in variable i) before \ |another |part (getting a value from variable i) is evaluated. But then shell "operators and their precedence, associativity, and values are the same as in the C language". There are no sequence points. += is right associative, and then unwound. (For C, they do it all right, only clang warns on sequencing when tested. But yes, i do "hate" ISO/IEC JTC1/SC22/WG14, N925, "A formal model of sequence points and related issues", Clive Feather, from Y2K (my version), and if only for such cases like the above. Or the x=++x shown in the committee document (for exactly that reason i presume: an "easy" formal formula to make it work, even if human logic gives you the green light).) --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: evaluation order bug
On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: > But then shell "operators and their precedence, associativity, > and values are the same as in the C language". There are no > sequence points. Order of evaluation is not the same as precedence/associativity. > += is right associative, and then unwound. > (For C, they do it all right, There is not a 'right' since the expression is undefined as it breaks sequencing rules. You have a notion of 'right' that might well be what happens (with compilers that you have tested) but you are not allowed to make that assumption. > only clang warns on sequencing when tested. Ah: so only clang gives the warning that the others should probably give. > But yes, i do "hate" ISO/IEC JTC1/SC22/WG14, N925, "A formal model of > sequence points and related issues", Clive Feather, from Y2K (my version), > and if only for such cases like the above. Standards are not written to be "liked". They describe how a compiler should work which includes things where the compiler writer can do as they please if they think that they can generate faster/smaller/... machine code. > Or the x=++x shown in the committee document (for exactly that reason i > presume: an "easy" formal formula to make it work, even if human logic gives > you the green light).) What does "human logic" mean ? Anyway: back to what the shell should be doing. You cannot put a ';' into (( )) as a sequence point, but the manual does say: "Sub-expressions in parentheses are evaluated first and may override the precedence rules above" So use sub-expressions to 'evaluate first' so you should prolly rewrite: (( i += j += i += i )) as: (( i += (j += (i += i)) )) Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Arithmetic expression: evaluation order bug
On Dez 29 2022, Alain D D Williams wrote: > On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: > >> only clang warns on sequencing when tested. > > Ah: so only clang gives the warning that the others should probably give. $ gcc -Wall t.c t.c: In function ‘main’: t.c:7:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] i += j += i += j; ^~ t.c:11:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] i += j += i += i; ^~ -- 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: Arithmetic expression: evaluation order bug
Alain D D Williams wrote in <20221229215700.gd16...@phcomp.co.uk>: |On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: |> But then shell "operators and their precedence, associativity, |> and values are the same as in the C language". There are no |> sequence points. | |Order of evaluation is not the same as precedence/associativity. | |> += is right associative, and then unwound. | |> (For C, they do it all right, | |There is not a 'right' since the expression is undefined as it breaks |sequencing rules. You have a notion of 'right' that might well be what \ |happens |(with compilers that you have tested) but you are not allowed to make that |assumption. | |> only clang warns on sequencing when tested. | |Ah: so only clang gives the warning that the others should probably give. By default. |> But yes, i do "hate" ISO/IEC JTC1/SC22/WG14, N925, "A formal model of |> sequence points and related issues", Clive Feather, from Y2K (my \ |> version), |> and if only for such cases like the above. | |Standards are not written to be "liked". They describe how a compiler \ |should |work which includes things where the compiler writer can do as they \ |please if |they think that they can generate faster/smaller/... machine code. | |> Or the x=++x shown in the committee document (for exactly that reason i |> presume: an "easy" formal formula to make it work, even if human \ |> logic gives |> you the green light).) | |What does "human logic" mean ? | |Anyway: back to what the shell should be doing. You cannot put a ';' \ |into (( )) |as a sequence point, but the manual does say: | |"Sub-expressions in parentheses are evaluated first and may override the |precedence rules above" | |So use sub-expressions to 'evaluate first' so you should prolly rewrite: | |(( i += j += i += i )) | |as: | |(( i += (j += (i += i)) )) | |Regards Not me!! Bash does it right for x=++x, where is your sequence point? dash for example evaluates the construct also in the way one would expect (which i would glue to "human logic"). Also, i would argue, you cannot put your finger on ISO C sequence points and then keep the way bash evaluates integers, this is comme ci comme ça. But regardless, i still think it is a bug, that i hereby have reported, army troopers aside. I _will_ keep my evaluator the way it is, maybe someone should report a dash bug if she or he thinks otherwise. I have not looked at other shells (i would hope those which support the operator keep human logic (!) happy). --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: evaluation order bug
Andreas Schwab wrote in <87358xambe@igel.home>: |On Dez 29 2022, Alain D D Williams wrote: |> On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: |> |>> only clang warns on sequencing when tested. |> |> Ah: so only clang gives the warning that the others should probably give. | |$ gcc -Wall t.c Sorry, that (-Wall) not. |t.c: In function ‘main’: |t.c:7:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] | i += j += i += j; | ^~ |t.c:11:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] | i += j += i += i; | ^~ Luckily it is not in real life. --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: evaluation order bug
Ah, wait.. Alain D D Williams wrote in <20221229215700.gd16...@phcomp.co.uk>: ... |Anyway: back to what the shell should be doing. You cannot put a ';' \ |into (( )) |as a sequence point, but the manual does say: | |"Sub-expressions in parentheses are evaluated first and may override the |precedence rules above" | |So use sub-expressions to 'evaluate first' so you should prolly rewrite: | |(( i += j += i += i )) | |as: | |(( i += (j += (i += i)) )) I had tried that with clang (and now with gcc -Wall). --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: evaluation order bug
And, lastly (from my side).. Steffen Nurpmeso wrote in <20221229231538.pz4j9%stef...@sdaoden.eu>: ... |Alain D D Williams wrote in | <20221229215700.gd16...@phcomp.co.uk>: | ... ||Anyway: back to what the shell should be doing. You cannot put a ';' \ ||into (( )) ||as a sequence point, but the manual does say: || ||"Sub-expressions in parentheses are evaluated first and may override the ||precedence rules above" || ||So use sub-expressions to 'evaluate first' so you should prolly rewrite: ... ||(( i += (j += (i += i)) )) | |I had tried that with clang (and now with gcc -Wall). ..i want to reiterate the relation to what "human logic" expects. Now, the entire scene is often on the brainfuck (programming language) side, nonetheless i, and the way all tested ISO C compilers, and dash, and my evaluator do it, would hope in the sense of "what comes natural"ly, that my point of view counts as what "human logic" would expect. Ciao, --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: evaluation order bug
On Dez 30 2022, Steffen Nurpmeso wrote: > Andreas Schwab wrote in > <87358xambe@igel.home>: > |On Dez 29 2022, Alain D D Williams wrote: > |> On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: > |> > |>> only clang warns on sequencing when tested. > |> > |> Ah: so only clang gives the warning that the others should probably give. > | > |$ gcc -Wall t.c > > Sorry, that (-Wall) not. > > |t.c: In function ‘main’: > |t.c:7:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] > | i += j += i += j; > | ^~ > |t.c:11:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] > | i += j += i += i; > | ^~ > > Luckily it is not in real life. Luckily you are mistaken. -- 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: Arithmetic expression: evaluation order bug
On Dez 30 2022, Steffen Nurpmeso wrote: > Not me!! Bash does it right for x=++x, There is no right answer. -- 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: Arithmetic expression: evaluation order bug
Andreas Schwab wrote in <87pmc194i6@igel.home>: |On Dez 30 2022, Steffen Nurpmeso wrote: ... |There is no right answer. But, do you know what? What you advocate contradicts thousands of years of human culture, religion and philosophie (to the best of my understanding), including your native one. I know we have forgotten (or, actually, to remain in that culture, .. we currently reiterate the "last days" again, only maybe the last time, heh, but so your statement makes some sense (i am no christian .. but would not need to be ashamed). But that is of course totally off-topic. P.S.: i have not read the hitchhickers guide, btw. Nor watched the film. --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: evaluation order bug
On Fri, Dec 30, 2022 at 12:21:52AM +0100, Steffen Nurpmeso wrote: > ..i want to reiterate the relation to what "human logic" expects. I'm a human, so I feel qualified to address this point. What I expect from a command like (( i += j += i += j )) is to get unpredictable results that have no relationship to anything useful, because that code is complete rubbish. I can't even guess what the *intent* of the code is. I'm not optimistic enough to expect an error message, or even better, an immediate termination of the shell. That would be *far* too useful (because it would force the script's author to rewrite that code).
Re: Arithmetic expression: evaluation order bug
On Fri, Dec 30, 2022 at 12:15:38AM +0100, Steffen Nurpmeso wrote: > Ah, wait.. > > Alain D D Williams wrote in > <20221229215700.gd16...@phcomp.co.uk>: > ... > |Anyway: back to what the shell should be doing. You cannot put a ';' \ > |into (( )) > |as a sequence point, but the manual does say: > | > |"Sub-expressions in parentheses are evaluated first and may override the > |precedence rules above" > | > |So use sub-expressions to 'evaluate first' so you should prolly rewrite: > | > |(( i += j += i += i )) > | > |as: > | > |(( i += (j += (i += i)) )) > > I had tried that with clang (and now with gcc -Wall). My quote from "the manual" is the bash manual (version 5.0.3 on Debian 10 (Buster)) so the 'evaluate first' applies to bash not the C language. Please understand that different languages might do things differently. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include
