Re: bash passes changed termios to backgrounded process(es) groups?

Chet Ramey wrote in : |On 8/29/24 2:17 PM, Robert Elz wrote: |> Date:Thu, 29 Aug 2024 10:40:25 -0400 |> From:Chet Ramey |> Message-ID: |> |>| It's not a big problem. You're in the background if your process \ |>| group is |>| not equal to the terminal's p

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/29/24 4:59 PM, Martin D Kealey wrote: On Fri, 30 Aug 2024 at 04:17, Robert Elz > wrote: SIGTTOU is also sent, unconditionally, by any attempt to change any of the terminal's attributes, and the process (group) (by default) stops. (I don't recall off

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/29/24 2:17 PM, Robert Elz wrote: Date:Thu, 29 Aug 2024 10:40:25 -0400 From:Chet Ramey Message-ID: | It's not a big problem. You're in the background if your process group is | not equal to the terminal's process group. That's more or less sufficient

Re: bash passes changed termios to backgrounded process(es) groups?

Robert Elz wrote in <23591.1724975...@jacaranda.noi.kre.to>: |Date:Fri, 30 Aug 2024 00:39:40 +0200 |From:Steffen Nurpmeso |Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu> | || On Linux it seems not even to cause TTOU if you set || attributes which are e

Re: bash passes changed termios to backgrounded process(es) groups?

Date:Fri, 30 Aug 2024 00:39:40 +0200 From:Steffen Nurpmeso Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu> | On Linux it seems not even to cause TTOU if you set | attributes which are effectively identical to what is already | active Yes, my wording wa

Re: bash passes changed termios to backgrounded process(es) groups?

Martin D Kealey wrote in : |On Fri, 30 Aug 2024 at 04:17, Robert Elz wrote: |> SIGTTOU is also sent, unconditionally, by any attempt to change any of |> the terminal's attributes, and the process (group) (by default) stops. |> (I don't recall off hand whether simply fetching the attributes is

Re: bash passes changed termios to backgrounded process(es) groups?

Chet Ramey wrote in : |On 8/28/24 4:12 PM, Steffen Nurpmeso wrote: |> Chet Ramey wrote in |> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: |>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: |>|> I got a bug report for my mailer which stated |>|> |>|> $ ( echo blah | Mail root ) & |>|>

Re: bash passes changed termios to backgrounded process(es) groups?

Robert Elz wrote in <25564.1724955...@jacaranda.noi.kre.to>: |Date:Thu, 29 Aug 2024 10:40:25 -0400 |From:Chet Ramey |Message-ID: | || It's not a big problem. You're in the background if your process group is || not equal to the terminal's process group. | |Th

Re: bash passes changed termios to backgrounded process(es) groups?

On Fri, 30 Aug 2024 at 04:17, Robert Elz wrote: > SIGTTOU is also sent, unconditionally, by any attempt to change any of > the terminal's attributes, and the process (group) (by default) stops. > (I don't recall off hand whether simply fetching the attributes is > enough to generate SIGTTOU.) J

Re: bash passes changed termios to backgrounded process(es) groups?

Date:Thu, 29 Aug 2024 10:40:25 -0400 From:Chet Ramey Message-ID: | It's not a big problem. You're in the background if your process group is | not equal to the terminal's process group. That's more or less sufficient to determine if the process is in a backgroun

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/28/24 4:12 PM, Steffen Nurpmeso wrote: Chet Ramey wrote in <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: |On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: |> Hello. |> |> I got a bug report for my mailer which stated |> |> $ ( echo blah | Mail root ) & |>[1] 2754649 |

Re: bash passes changed termios to backgrounded process(es) groups?

Martin D Kealey wrote in : |On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso wrote: |> Chet Ramey wrote in |> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: |>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: |>|> ..and it seems that if bash starts a normal process then ICRNL is |>|> set, but i

Re: bash passes changed termios to backgrounded process(es) groups?

On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso wrote: > Chet Ramey wrote in > <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: > |On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: > |> ..and it seems that if bash starts a normal process then ICRNL is > |> set, but if it starts a (process)& or only

Re: bash passes changed termios to backgrounded process(es) groups?

Chet Ramey wrote in <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: |On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: |> Hello. |> |> I got a bug report for my mailer which stated |> |> $ ( echo blah | Mail root ) & |>[1] 2754649 |> $ ^M^M^M^M^C^C |> |>[1]+ Stopped

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: Hello. I got a bug report for my mailer which stated $ ( echo blah | Mail root ) & [1] 2754649 $ ^M^M^M^M^C^C [1]+ Stopped ( echo blah | Mail root ) $ fg ( echo blah | Mail root ) $ I turns out i answered hi

Re: bash passes changed termios to backgrounded process(es) groups?

Steffen Nurpmeso wrote in <20240827234659.1xfh6CZb@steffen%sdaoden.eu>: ... |..and it seems that if bash starts a normal process then ICRNL is |set, but if it starts a (process)& or only process&, then not! Yeah, and it seems to me it should not, since programs have to fetch the terminal defau

bash passes changed termios to backgrounded process(es) groups?

Hello. I got a bug report for my mailer which stated $ ( echo blah | Mail root ) & [1] 2754649 $ ^M^M^M^M^C^C [1]+ Stopped ( echo blah | Mail root ) $ fg ( echo blah | Mail root ) $ I turns out i answered him now The thing is that if i apply the patch (this

Re: Inner Command Groups fail in Bash 5.2

On Fri, 1 Sep 2023 10:29:29 -0400 Chet Ramey wrote: > On 9/1/23 10:27 AM, Kerin Millar wrote: > > > Would you mind supplying a diff for 5.2.15? For that version, I get: > > > > ./parse.y: In function ‘time_command_acceptable’: > > ./parse.y:3139:14: error: ‘DOLBRACE’ undeclared (first use in th

Re: Inner Command Groups fail in Bash 5.2

On 9/1/23 10:27 AM, Kerin Millar wrote: Would you mind supplying a diff for 5.2.15? For that version, I get: ./parse.y: In function ‘time_command_acceptable’: ./parse.y:3139:14: error: ‘DOLBRACE’ undeclared (first use in this function); did you mean ‘Q_DOLBRACE’ Remove `DOLBRACE'. It's for n

Re: Inner Command Groups fail in Bash 5.2

On Fri, 1 Sep 2023 09:52:17 -0400 Chet Ramey wrote: > On 8/31/23 1:21 PM, Dima Korobskiy wrote: > > > Bash Version: 5.2 > > Patch Level: 15 > > Release Status: release > > > > Description: > >     One of my Bash scripts started to fail all of a sudden and I was > > able to narrow down thi

Re: Inner Command Groups fail in Bash 5.2

On 8/31/23 1:21 PM, Dima Korobskiy wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description:     One of my Bash scripts started to fail all of a sudden and I was able to narrow down this problem to Bash upgrade itself (via Homebrew on a Mac): from 5.1.16 to 5.2.15. I

Inner Command Groups fail in Bash 5.2

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin20.6.0 Compiler: clang Compilation CFLAGS: -DSSH_SOURCE_BASHRC uname output: Darwin San-Francisco-iMac.local 20.6.0 Darwin Kernel Version 20.6.0: Thu Jul  6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.1

Re: GROUPS

Robert Elz writes: > | What seems to be the case with sh-style shells and Posix is that > | all-caps variable names are subject to implementation-specific use, and > | so users should not use them except when using them in the way that is > | specific to the implementation the script is to

Re: GROUPS

Date:Mon, 16 Aug 2021 22:16:29 -0400 From:"Dale R. Worley" Message-ID: <878s10yfwi@hobgoblin.ariadne.com> | What seems to be the case with sh-style shells and Posix is that | all-caps variable names are subject to implementation-specific use, and | so users

Re: GROUPS

It seems to me that people are avoiding both the core issue and its solution. A standard is what allows people to write software that can be ported without having to reassess every detail of the program. To take C as an example, the standard defines what identifiers look like, which identifiers a

Re: GROUPS

On Fri, 2021-08-13 at 10:10 -0400, Chet Ramey wrote: > As long as you stick to things POSIX standardizes. Relevant here, the > standard even includes a list of variables you should avoid using because > various shells and applications use them. GROUPS is not on this list that I can

Re: GROUPS

On 8/13/21 10:32 AM, Greg Wooledge wrote: On Fri, Aug 13, 2021 at 10:10:42AM -0400, Chet Ramey wrote: As long as you stick to things POSIX standardizes. Relevant here, the standard even includes a list of variables you should avoid using because various shells and applications use them. Just o

Re: GROUPS

On Fri, Aug 13, 2021 at 10:10:42AM -0400, Chet Ramey wrote: > As long as you stick to things POSIX standardizes. Relevant here, the > standard even includes a list of variables you should avoid using because > various shells and applications use them. Just out of curiosity, where is that? It's no

Re: GROUPS

purpose of a reference. As an aside: I believe in thorough testing in as many environments as feasible! Even then (using either solution), what does a script do if it wants to be invoked as: GROUPS='abelian ...' script [options] ? That case works, see abo

Re: GROUPS

ht it might be now I know of the way these things work when in the environment - though because of that (and because with it, it is trivially possible to subvert scripts which use any of these vars simply by loading the environ with lots of junk) it gets a bit more important to provide a way for a sc

Re: GROUPS

On Wed, 2021-08-11 at 20:36 -0400, Greg Wooledge wrote: > On Wed, Aug 11, 2021 at 08:00:12PM -0400, Franklin, Jason wrote: > > This doesn't work unless it was recently fixed. A variation does... > > > > bash-5.0$ echo $BASH_VERSION > > 5.0.17(1)-release > &

Re: GROUPS

On Wed, Aug 11, 2021 at 08:00:12PM -0400, Franklin, Jason wrote: > This doesn't work unless it was recently fixed. A variation does... > > bash-5.0$ echo $BASH_VERSION > 5.0.17(1)-release > bash-5.0$ GROUPS=FOO bash -c 'echo $GROUPS' > 1000 > bash-5.0$ GROU

Re: GROUPS

elieve in thorough testing in as many environments as feasible! > Even then (using either solution), what does a script do if it wants to > be invoked as: > > GROUPS='abelian ...' script [options] > > ? > > That case works, see above. May

Re: GROUPS

er shells, even other shells that Debian includes. The other problem is the OP assuming that posix mode would change it, when posix mode means something else. Even then (using either solution), what does a script do if it wants to be invoked as: GROUPS='abelian ...' script [

Re: GROUPS

. Even then (using either solution), what does a script do if it wants to be invoked as: GROUPS='abelian ...' script [options] ? That works with most shells (the script just accesses ${GROUPS} or perhaps first includes ": ${GROUPS=a b c}" to set the default value in ca

Re: GROUPS

On 8/10/21 8:56 PM, Franklin, Jason wrote: What surprised me was that Bash-specific "magic" variables did not lose their "magic" qualities when Bash was invoked in a POSIX-compliant mode of execution. That's not what bash posix mode is for. POSIX does not prohibit extensions. -- ``The lyf

Re: GROUPS

On 8/10/21 12:39 PM, Robert Elz wrote: | In this case, you are using features outside what POSIX specifies. Using a variable name that's outside what POSIX specifies is hardly using a feature that's outside POSIX - if it were then there would be no safe non-trivial scripts, since any variabl

Re: GROUPS

On Aug 11 2021, Štěpán Němec wrote: > Quoting POSIX.1-2017 on environment variables [1]: Note that GROUPS is not an environment variable in bash, it is not exported. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 &

Re: GROUPS

On Tue, 10 Aug 2021 23:39:47 +0700 Robert Elz wrote: > Date:Tue, 10 Aug 2021 10:22:29 -0400 > From:Chet Ramey > Message-ID: <731876fc-39c0-4388-0c9e-bf560921b...@case.edu> > > | In this case, you are using features outside what POSIX specifies. > > Using a variable

Re: GROUPS

On Tue, Aug 10, 2021 at 8:57 PM Franklin, Jason wrote: > What surprised me was that Bash-specific "magic" variables did not lose > their "magic" qualities when Bash was invoked in a POSIX-compliant mode > of execution. Posix mode does not mean that bash-specific variables (or anything else bash-s

Re: GROUPS

Hey, Robert: Thanks for the input! Quoting you here with some of my thoughts... > Using a variable name that's outside what POSIX specifies is hardly > using a feature that's outside POSIX - if it were then there would be > no safe non-trivial scripts, since any variable name might be made magic

Re: GROUPS

uot;cd" will set PWD and OLDPWD, so you'd want to avoid that if using PWD or OLDPWD for some other purpose, and "pwd" is undefined if PWD has been altered, so you'd need to avoid that as well - similar restrictions for the others.) I found this when I attempted to make HOSTNA

Re: GROUPS

ls. Perhaps this assessment is naive. If the script uses only features specified by POSIX, it's a reasonable expectation. If it uses features that POSIX doesn't mention -- and every shell has them -- it's not. In this case, you are using features outside what POSIX specifies. Since GROU

Re: GROUPS

On 8/9/21 5:35 PM, Franklin, Jason wrote: > Greetings: > > I discovered today that the GROUPS variable is special in Bash. It is. For everyone else: GROUPS An array variable containing the list of groups of which the current user is a member. Assignments to GROUPS have

Re: GROUPS

On Mon, Aug 09, 2021 at 10:00:25PM -0400, Franklin, Jason wrote: > I did not write the scripts in question. These were actually Debian > package maintainer scripts that started failing. > > Perhaps I'll get a test added to "checkbashisms" that looks for this. A bug report against that Debian pac

Re: GROUPS

quot;--posix" or as "sh", omit the special > > treatment of variables such as GROUPS? > > I would say no. Using all-caps variable names is a bad idea for > precisely this reason -- you never know when it'll be something > special, in your shell or in your o

Re: GROUPS

On Mon, Aug 09, 2021 at 05:35:56PM -0400, Franklin, Jason wrote: > Should bash, invoked with "--posix" or as "sh", omit the special > treatment of variables such as GROUPS? I would say no. Using all-caps variable names is a bad idea for precisely this reason -- yo

GROUPS

Greetings: I discovered today that the GROUPS variable is special in Bash. I moved some scripts to a new box, and they stopped working. On this box, /bin/sh linked to /bin/bash instead instead of /bin/dash. Scripts of of this form... #!/bin/sh GROUPS='foo bar' # do some

Re: Conditions with logical operators and nested groups execute "if" and "else"

Ilkka Virta wrote: If the 1st expression is false, it would skip directly to the '||' and would execute the 3rd clause. If the 1st expresion is true then it does the 2nd clause. If that is false, the '||' clause is done, but if true, the '||' clause would not be done. In other words, ||

Re: Conditions with logical operators and nested groups execute "if" and "else"

On 05/31/2018 01:54 PM, Robert Elz wrote: > I am not sure what predence rule you see working as > expected, but in sh (bash, or any other Bourne syntax > or POSIX shell) there is no precedence for && and || > they (in the absense of grouping) are simply executed > left to right as written. Here is

Re: Conditions with logical operators and nested groups execute "if" and "else"

On 31.5. 02:20, L A Walsh wrote: Ilkka Virta wrote: On 22.5. 00:17, Uriel wrote: As you know, a conditional is of the type: if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi Or with logical operators and groups: [[ EXPRESSION ]] && { TRUE CONDITION; } || { ALT

Re: Conditions with logical operators and nested groups execute "if" and "else"

On Wed, May 30, 2018 at 05:02:58PM -0700, L A Walsh wrote: > Greg Wooledge wrote: > > On Mon, May 21, 2018 at 04:17:18PM -0500, Uriel wrote: > > > [[ EXPRESSION ]]; && { TRUE CONDITION; } || { ALTERNATIVE RESULT; } > > https://mywiki.wooledge.org/BashPitfalls#pf22 > pf22 is wrong. It's not wrong.

Re: Conditions with logical operators and nested groups execute "if" and "else"

Date:Wed, 30 May 2018 17:02:58 -0700 From:L A Walsh Message-ID: <5b0f3bb2.1000...@tlinx.org> | I.e. precedence rules seem to work as expected. I am not sure what predence rule you see working as expected, but in sh (bash, or any other Bourne syntax or POSIX shell)

Re: Conditions with logical operators and nested groups execute "if" and "else"

uriel: You didn't say what you expected the behavior to be in your bottom conditional, but remember, you start with -e-e-e--debug; you lop off the 1st -e (did you mean to use ## instead of #?) so last statement of 1st indent was ! "-e-e--debug =~ ^- so the regex matches (true) and then you say '

Re: Conditions with logical operators and nested groups execute "if" and "else"

Ilkka Virta wrote: On 22.5. 00:17, Uriel wrote: As you know, a conditional is of the type: if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi Or with logical operators and groups: [[ EXPRESSION ]] && { TRUE CONDITION; } || { ALTERNATIVE RESULT; } No, t

Re: Conditions with logical operators and nested groups execute "if" and "else"

On Mon, May 21, 2018 at 04:17:18PM -0500, Uriel wrote: > [[ EXPRESSION ]]; && { TRUE CONDITION; } || { ALTERNATIVE RESULT; } https://mywiki.wooledge.org/BashPitfalls#pf22

Re: Conditions with logical operators and nested groups execute "if" and "else"

On 22.5. 00:17, Uriel wrote: As you know, a conditional is of the type: if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi Or with logical operators and groups: [[ EXPRESSION ]] && { TRUE CONDITION; } || { ALTERNATIVE RESULT; } No, those are not the same. In the lat

Re: Conditions with logical operators and nested groups execute "if" and "else"

el: 19 > Release Status: release > > Description: > As you know, a conditional is of the type: > if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi > > Or with logical operators and groups: > > [[ EXPRESSION ]]; && { TRUE CONDITION; } ||

Conditions with logical operators and nested groups execute "if" and "else"

e output: Linux HPgS 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: As you know, a conditional is of the type: if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERN

Re: Assigment to GROUPS doesn't return an error code

On 8/11/15 5:07 AM, Grzegorz Bajson wrote: > Bash Version: 4.3.30 > Patch Level: 2 > Release Status: release > > Description: > Hi, > According to man page assigment to GROUPS should return error status, > this is not a case: > > "GROUPS An array

Assigment to GROUPS doesn't return an error code

pv uname output: Linux oc5414668263.ibm.com 2.6.32-504.23.4.el6.x86_64 #1 SMP Fri May 29 10:16:43 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.3.30 Patch Level: 2 Release Status: release Description: Hi, According to man page assigment to

Assigment to GROUPS doesn't return an error code

c -fwrapv uname output: Linux oc5414668263.ibm.com 2.6.32-504.23.4.el6.x86_64 #1 SMP Fri May 29 10:16:43 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.3.30 Patch Level: 2 Release Status: release Description: Hi, According to man pa

Re: SIGSEGV on "local -a GROUPS=(...)" in function

On 2/14/13 7:57 PM, Richard Tollerton wrote: > This is probably not a good thing to be doing in the first place (I ran > into this before realizing that GROUPS was a special variable): Not only is GROUPS a special variable, assignments to it are disallowed. Still, the shell shouldn'

SIGSEGV on "local -a GROUPS=(...)" in function

This is probably not a good thing to be doing in the first place (I ran into this before realizing that GROUPS was a special variable): #!/bin/bash crashy () { local -a GROUPS=(a b); } crashy But it probably shouldn't be doing this (tested in bash 4.2.42 on archlinux x86_64, and bash 4.2.

Re: using the variable name, GROUPS, in a read list

Greg Wooledge wrote: > Jim Meyering wrote: > > Is there a moral here, other than to avoid using special variable names? > > Probably to prefer lower-case variable names. > > You've nailed it. Or more precisely, avoid all-upper-case variable names, > because they tend to collide with environment v

Re: using the variable name, GROUPS, in a read list

On 03/07/2012 04:54 PM, Jim Meyering wrote: FYI, if I attempt to read into the built-in array variable, GROUPS, this doesn't work: $ bash -c 'while read GROUPS; do echo $GROUPS; done< /etc/passwd'|wc -l 0 Comparing with dash, I see what the author expected, i.e., t

Re: using the variable name, GROUPS, in a read list

On Wed, Mar 07, 2012 at 04:54:14PM +0100, Jim Meyering wrote: > Is there a moral here, other than to avoid using special variable names? > Probably to prefer lower-case variable names. You've nailed it. Or more precisely, avoid all-upper-case variable names, because they tend to collide with envi

using the variable name, GROUPS, in a read list

FYI, if I attempt to read into the built-in array variable, GROUPS, this doesn't work: $ bash -c 'while read GROUPS; do echo $GROUPS; done < /etc/passwd'|wc -l 0 Comparing with dash, I see what the author expected, i.e., that the while loop iterates once per line in /etc/pa

[IGNORE THIS] Just testing if I can post to the list from Google Groups

See this message? Fine. :)

Re: Assignment to GROUPS in logical or expression

> Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: > Assignment to GROUPS in logical or expression not testable. Assignment to GROUPS is as if an assignment were attempted to a readonly variable -- the current command is immediately termina

Assignment to GROUPS in logical or expression

6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Assignment to GROUPS in logical or expression not testable. Repeat-By: GROUPS="hello&