Bash monitor mode remains enabled if disabled in .bashrc

[Michel LaBarre]

Playing with set -m/+m and shopt -s lastpipe, in an interactive bash shell,
I came across a situation
which is minor unless it has broader implications for others that I do not
know about.

Specifically if "set +m" is present in .bashrc, it looks like job control
(monitor mode) is off
in an interactive shell (as per "echo $-") but it is actually on.

I ran into this with "shopt -s lastpipe" behaviour with and without job
control.
I can also reproduce it with "sleep 25&" then "fg" will fail with "no job
control".

If I "set +m" within the interactive shell rather than, or in addition to,
.bashrc, both the
flags ($-) and behaviour (lastpipe and fg) reflect job control being off.

I include only an example with lastpipe.

FYI - from bash reference for shopt:
lastpipe If set, and job control is not active, the shell runs the last
command
of a pipeline not executed in the background in the current shell
environment.

My .bashrc includes "shopt -s lastpipe" and "set +m".
My objective was to produce the same conditions as within a script for
debugging a messy statement at a command line
and I had no need for job control while doing this and I would sometimes
forget to disable monitor mode after a new bash.
If somebody trying to debug some bash statements and is unaware that a
second "set +m" is required, they
might be confused for a bit. (An option to make an interactive shell behave
the same as a non-interactive shell
might facilitate such debugging.)

C:\mybin>bash
$ echo "$-" # no "m" meaning monitor mode is off i.e.
no job control...
hiBHs
$ echo abc | read zot # zot is therefore in a sub-process hence value
not available in this process
$ echo $zot

$ set +m
$ echo "$-" # still no m but behaviour is
different...
hiBHs
$ echo abc | read zot # read zot now running in this process so value is
available
$ echo $zot
abc
$ bash --version
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)

By the way, the "s" set option ($- above) is not defined in the bash
reference manual that I have and is not accepted
by the "set" built into bash so I don't know how it gets set. (i.e."set -s
s" or "set +s s" both fail with "invalid option".)

Michel LaBarre





--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

[cyg Simple]

Post by Michel LaBarre
Playing with set -m/+m and shopt -s lastpipe, in an interactive bash shell,
I came across a situation
which is minor unless it has broader implications for others that I do not
know about.
Specifically if "set +m" is present in .bashrc, it looks like job control
(monitor mode) is off
in an interactive shell (as per "echo $-") but it is actually on.
I ran into this with "shopt -s lastpipe" behaviour with and without job
control.
I can also reproduce it with "sleep 25&" then "fg" will fail with "no job
control".
If I "set +m" within the interactive shell rather than, or in addition to,
.bashrc, both the
flags ($-) and behaviour (lastpipe and fg) reflect job control being off.

Are you sure that .bashrc is being sourced? The initial start of an
interactive shell doesn't read .bashrc by default. It reads
.bash_profile when starting interactive mode. Now most likely your
.bash_profile contains lines to check the existence of .bashrc and
source it but you need to check.

[cyg Simple]

Keep responses to the list and not the individual responders.

Forwarded on your behalf.

Thanks for the reply.
- my .bash_profile does indeed source .bashrc
- I added an echo to .bashrc to be doubly sure - it displays as expected

-----Original Message-----
Behalf Of cyg Simple
Sent: August-31-17 8:31 AM
Subject: Re: Bash monitor mode remains enabled if disabled in .bashrc

Post by Michel LaBarre
Playing with set -m/+m and shopt -s lastpipe, in an interactive bash shell,
I came across a situation
which is minor unless it has broader implications for others that I do not
know about.
Specifically if "set +m" is present in .bashrc, it looks like job control
(monitor mode) is off
in an interactive shell (as per "echo $-") but it is actually on.
I ran into this with "shopt -s lastpipe" behaviour with and without job
control.
I can also reproduce it with "sleep 25&" then "fg" will fail with "no job
control".
If I "set +m" within the interactive shell rather than, or in addition to,
.bashrc, both the
flags ($-) and behaviour (lastpipe and fg) reflect job control being off.

Are you sure that .bashrc is being sourced? The initial start of an
interactive shell doesn't read .bashrc by default. It reads
bash_profile when starting interactive mode. Now most likely your
bash_profile contains lines to check the existence of .bashrc and
source it but you need to check.

My .bash_profile does indeed source .bashrc
I added an echo to .bashrc to be doubly sure - it displays as expected> --