How to suppress async messages for background jobs
Hi, when using & at the end of a command, bash prints messages like: [EMAIL PROTECTED]:~$ kwrite & =>[1] 20986 [EMAIL PROTECTED]:~$ =>[1]+ Donekwrite [EMAIL PROTECTED]:~$ is there a way to tell bash not to print those lines marked with => ? I could not find any command searching in the bash manual or googling... Thanks, Francesco ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bug with 3.1.10 on FreeBSD
There seems to be a problem with bash 3.1.10 on FreeBSD as described in this thread. --- http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023123.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[Fwd: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)]
FYI. Original Message Subject: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters) Date: Sun, 5 Mar 2006 04:01:19 -0500 From: Kris Kennaway <[EMAIL PROTECTED]> To: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED], [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> On Sun, Mar 05, 2006 at 09:57:54AM +0100, Nicolas Rachinsky wrote: * Kris Kennaway <[EMAIL PROTECTED]> [2006-03-05 03:41 -0500]: > On Sun, Mar 05, 2006 at 09:36:25AM +0100, Nicolas Rachinsky wrote: > > The problem seems to depend on the installed bison version. With no > > bison or bison-2.1_1 installed it works fine, with bison-1.75_2,1 it > > doesn't. > > Installed at what point: the build time of the bash port, or runtime > (which would be very odd)? The build time. I submitted ports/94086, which contains a fix/workaround. Great, thanks for tracking this down! Can others confirm this solution? Kris ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to suppress async messages for background jobs
Francesco Montorsi wrote: > Hi, > when using & at the end of a command, bash prints messages like: > > [EMAIL PROTECTED]:~$ kwrite & > =>[1] 20986 > [EMAIL PROTECTED]:~$ > =>[1]+ Donekwrite > [EMAIL PROTECTED]:~$ > > is there a way to tell bash not to print those lines marked with => ? > I could not find any command searching in the bash manual or googling... These messages will be printed unless job control is turned off. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
quoting inside backquotes in 3.1
Is it intentional that the following script, which worked in 2.05b now produces errors in 3.1: : `: "\\""` That now results in: unexpected EOF while looking for matching ``' Using a third backslash fixes it but this is inconsistent with ash bash2 bsh ksh pdksh and zsh. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: trap handler scope wrong?
Does redirecting to /dev/tty work if the original stdout of the shell was NOT a tty? This script runs as a cron job so it has no tty.
Also is there a better way to save the original stdout and switch back to it
than this:
trap "cat $LOG > &3" ERR
{
foo
bar
} 3>&1 > /dev/null
Chet Ramey wrote:
The ERR trap is handled in the context in which the shell is currently
running. If you want to display the log file on the terminal when the
ERR trap is run, you can either save the original stdout and make the
trap command (the `cat $LOGFILE') redirect its stdout there, or you can
redirect the trap command's standard output directly to /dev/tty.
Chet
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Trap on ERR not inherited by subshell with "set -E"
Markus Laire wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include > -I../bash/lib -g -O2 > uname output: Linux Knoppix 2.6.12 #2 SMP Tue Aug 9 23:20:52 CEST 2005 > i686 GNU/Linux > Machine Type: i386-pc-linux-gnu > > Bash Version: 3.0 > Patch Level: 16 > Release Status: release > > Description: > Bash manpage says that if "set -E" is set, > "any trap on ERR is inherited by shell functions, command > substitutions, > and commands executed in a subshell environment. The ERR trap is > normally not inherited in such cases." > But when running this script > trap 'echo ERR' ERR > set -E > echo "Fail in this shell" > false > ( echo "Fail in subshell" ; false ) > Only first 'false' is trapped, and the 'false' in subshell is not > trapped. Thanks. This will be fixed in the next version. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: backtick expansion is truncated
Brian Minton wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 > uname output: Linux bminton.is-a-geek.net 2.6.15.4 #0 SMP Sat Feb 18 12:04:34 > EST 2006 i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.1 > Patch Level: 5 > Release Status: release > > Description: > If I use a long backtick expansion, it is not all evaluated in some > circumstances (but it apparently is if only using builtins). > > Repeat-By: > for f in `seq 2`; do ls /dev/null; done|wc -l > yields 4097, not 2 that it should. However, > for f in `seq 2`; do echo /dev/null; done|wc -l > yields 2 (presumably because of using the bash builtin echo) Please install bash-3.1 patch 7 and see if the behavior persists. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
gnu.org mailing list info
Chet Ramey wrote: > Now that bug-bash appears to have arisen from the ashes, I will send > out the updated patch 10 again. These following blog messages about the lists had interesting information aout the recent problems. http://www.fsf.org/blogs/sysadmin/lists https://savannah.gnu.org/forum/forum.php?forum_id=4322 Summary: Due to various problems the MTA on lists.gnu.org melted down with 1.6 million messages in the queue and needed significant manual tending to get back on track again. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Fwd: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)]
Chet Ramey wrote: Mike Jakubik wrote: FYI. This has been a known issue with bison-1.75 for over three years: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html http://lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html Chet Thanks, sorry for the noise. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
