Re: Prefer non-gender specific pronouns
On Sun, Jun 06, 2021 at 05:12:21PM +0300, Oğuz wrote: > If that really is a problem that has to be addressed and not > bike-shedding, let's compromise and say "his/her" instead of "his" or > "their". Possible, but it detracts from the clarity of the sentence that it is in. > Though I don't think women who read the manual and burst into tears out of > oppression when they see "his" actually exist. The important thing is that there is no intention to oppress/denigrate/... women by the use of 'his'. What word(s) are used in translations of the manual into languages other than English ? Do similar problems exist. -- 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: Prefer non-gender specific pronouns
On Mon, Jun 07, 2021 at 12:52:08PM +0200, Dima Pasechnik wrote: > I know a number of French female academics, who would just laugh at the > latter claim. > To start with, they, married, but retained their maiden surnames, say, X, > cannot even manage to get > them addressed by official instances and businesses as Mme X, > and not "housewife of the house of Y" (which is what one French way > to addrress a married woman roughly means, IMHO). > One of them tells a "nice" story about her attempts to rent a flat in > Marsielle, > where she has a job (while her spouse was based in CERN, Geneve, so she had > to commute for years). > Of course a married woman trying to rent a flat in her name is a huge no-no > in 21st century France... What has renting a flat in France got to do with the bash manual page ? No one disputes that the sexes are treated differently but tying completely unrelated things together is not the way to address matters and change things. Ms Gris wrote she "take no offense when a documentation ...". I accept that some others might take offence. However it does not seem to be a major issue, if you want to make a change address things like renting flats in France. Also: please stop promoting the meme that it is always women who are disadvantaged. That is not true: have some kids, get divorced and look to see where the kids go. The kids see dad if mother wants to. If mother does not obey court orders they are not enforced (in many countries, eg UK). -- 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: [PATCH] Prefer non-gender specific pronouns
On Mon, Jun 07, 2021 at 06:12:07PM +0200, Léa Gris wrote: > This is what is happening here. Now they just ask for mundane changes and > will probably accept the patch. They will come again and ask for inclusive > grammar, then come again and ask for removal of anything that is even > remotely related to slavery (Example: master-slave database replication), > racial discrimination (please remove blacklist and replace by > exclusion-list), sexual assault or anything even remotely related. They will > not give-up until everything is expunged of every trace of anything until > total destruction or what's left is a bland ghostwith nothing left of > history and everyone has fought each-other. Then in 20 years time, when a different set of words will be deemed unacceptable, repeat the whole exercise. Maybe demand changes sooner as some words are deemed bad in other languages/cultures/... > Then they will vanish and destroy other community, other history. -- 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: Prefer non-gender specific pronouns
On Mon, Jun 07, 2021 at 08:37:53PM +0200, Dima Pasechnik wrote: > Where have you been taught to address a CS lecturer at Oxford University, > a PhD, who, age-wise, could have been your father, I suppose, with f-word? > In which well-respected madrasah did it happen, so that we know? Please lads: just cool it. We do not want a punch up on this list. 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 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
On Thu, Dec 29, 2022 at 09:09:25PM +0100, Emanuele Torre wrote: > On Thu, Dec 29, 2022 at 05:35:48PM +0000, 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
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 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
failure to login on serial console
The problem that I have seems much the same as from Feb 2019:
https://www.mail-archive.com/bug-bash@gnu.org/msg22665.html
Try to login on a serial console, see the message:
bash: initialize_job_control: no job control in background: Bad file descriptor
This is what is running:
# ps -ft tty2
UIDPID PPID C STIME TTY TIME CMD
root 18963 1 0 13:45 tty2 00:00:00 /bin/login -p --
addw 19149 18963 0 13:48 tty2 00:00:00 bash --login
When I press any key I get logged out. This is what happens when I press the
key:
# strace -p 19149
strace: Process 19149 attached
pselect6(1, [0], NULL, NULL, NULL, {[], 8}) = 1 (in [0])
read(0, 0x7ffc8237730f, 1) = -1 EIO (Input/output error)
In my .bash_profile I have the following, something that has been there for
years and caused no problem on my old desktop (CentOS 6, bash version 4.1.2(2))
I am now using bash 5.0.3(1)-release on a Debian-10 x86_64 machine.
[[ -n $SHELL && -z $SSH_AGENT_PID && -z $DISPLAY ]] &&
exec -l ssh-agent $SHELL -c "bash --login"
If I remove the above 2 lines the problem goes away but means that I do not
have a ssh-agent.
The 2 lines run, as expected, when I ssh localhost
--
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: failure to login on serial console
On Wed, Feb 03, 2021 at 12:07:38PM -0500, Chet Ramey wrote: > So your shell is not running in the same process group as the terminal, > and has no access to read from its controlling terminal. Thanks ... you gave me a clue to fix this. Not ideal, but it works. if [[ -n $SHELL && -z $SSH_AGENT_PID && -z $DISPLAY ]] then[[ $( tty ) != /dev/tty* ]] && exec -l ssh-agent bash --login ssh-agent bash --login exit fi -- 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
