On 7/23/15 6:52 PM, isabella parakiss wrote:
>
> No. Don't minimize this, it's not only about BASH_REMATCH.
OK. You did, however, spend an entire message on it.
> The fact that a certain special variable is readonly for no real reason
> doesn't change this absurd nonsense about any other glob
On 7/28/15 6:34 AM, David Waddell wrote:
> Hi
>
> Just a quick query re. the a behavior of trap when called from
> function, not sure if it’s a bug or inconsistency or intentional.
>
>
>
> Basically it seems (without set –o errtrace)
>
> - an ERR trap can be set from within a
On Tue, Jul 28, 2015 at 6:51 AM, Chet Ramey wrote:
> On 7/20/15 6:15 PM, James Chang wrote:
>
> > > I recently ran into an odd issue running the testsuite for bash.
> After
> > > running the scripts, /tmp/xx isn't deleted, and another user can't
> run the
> > > testsuite due to permis
2015-07-28 11:48:54 +0200, Andreas Schwab:
> Running exec in an interactive shell does not restore the terminal
> signals TSTP, TTIN, TTOU, causing them to be ignored in the new command.
>
> $ trap
> $ exec bash
> $ trap
> trap -- '' SIGTSTP
> trap -- '' SIGTTIN
> trap -- '' SIGTTOU
>
> Andreas.
Hi
Just a quick query re. the a behavior of trap when called from function,
not sure if it's a bug or inconsistency or intentional.
Basically it seems (without set -o errtrace)
- an ERR trap can be set from within a function when no ERR trap is
currently defined.
- ER
On 7/20/15 6:15 PM, James Chang wrote:
> > I recently ran into an odd issue running the testsuite for bash. After
> > running the scripts, /tmp/xx isn't deleted, and another user can't run
> the
> > testsuite due to permission errors. Is it possible to specify bash not
> to
> > u
Running exec in an interactive shell does not restore the terminal
signals TSTP, TTIN, TTOU, causing them to be ignored in the new command.
$ trap
$ exec bash
$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprin
