Re: trap handler scope wrong?
Phillip Susi wrote:
> I ran into something weird the other day, but I'm not sure if it's a bug
> or not since I'm a bit new to bash shell scripting. Basically I have a
> script that has structure like this:
>
> set -e
> trap "cat $LOGFILE" ERR
> {
> foo
> bar
> baz
> } > $LOGFILE 2>&1
>
> If an error happens inside the {} block, it looks like the ERR trap
> handler is called inside the {} context, so it's stdout is redirected to
> the log file. I had expected it to be called in the same scope it was
> defined in so that it's stdout would not be redirected.
> Is this a bug, or expected behavior? If it is expected, can anyone
> suggest a way to do what I'm trying to? The reason for this structure
> was to redirect verbose output to a log file which would normally be
> deleted from the EXIT trap handler, but if anything goes wrong, the ERR
> handler is to cat the full log file so I can see exactly what went wrong.
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
--
``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: Failure of removing pattern.
[EMAIL PROTECTED] wrote:
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> A refference to a shell variable doesn't work under specific case.
> The result of the following operations isn't shown and prompt doesn't
> return when environment variable LANG is Ja_JP on AIX 5.2L
> $ i=123456789012l
> $ echo ${i%l}
> (Pronput doesn't return...)
>
> Fix:
> This problem is avoidable by the modification shown below:
> Replace l. 3365 in subst.c ("ret = wcsdup (wparam);")
> to the following two lines:
>
> ret = (wchar_t *) malloc((size_t)(n + 1) * sizeof(wchar_t));
> wcscpy(ret, wparam);
>
I assume that this version of AIX has wcsdup(). Does that expansion
work when you #undef HAVE_WCSDUP in config.h and use the replacement
version in subst.c?
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: How to suppress async messages for background jobs
Chet Ramey ha scritto: 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. how can I turn job control off without recompiling the shell ? The only option I found is --disable-job-control for ./configure :( THanks indeed, Francesco ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: quoting inside backquotes in 3.1
>
> Your interpretation has evolved. Consider
> http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00047.html
> when you argue seemingly the exact opposite: that quoted strings should
> be recursively parsed inside ``.
Perhaps it has. But in that mail from last year, the string in question was:
echo `echo '${'`
But by my current understanding, the answer is still the same - inside
the backticks, no \ appears, so all characters are passed literally
to the subshell between the two ``. Then, inside the subshell,
you are executing echo '${', which has well-defined semantics,
so the overall output is still ${. So even though my interpretation
may have refined a bit, the sample in that older email still
results in the same string by either interpretation.
>
> I will, as I said, look for a backwards-compatible solution. That may
> involve finding a different way to solve the original problem that
> prompted the change.
>
I look forward to seeing what you come up with. I wish I
could help by coming up with a solution myself, but have not
had time to do so yet.
--
Eric Blake
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: core/loop vi mode when '.' used to repeat a replace
[EMAIL PROTECTED] wrote: > Bash Version: 3.1 > Patch Level: 11 > Release Status: release > > Description: > I've noticed that if I use ',' to repeat a substitution > in vi-mode, bash either dumps core or goes into a hard > loop. > > Repeat-By: > Any command should do, I used this now as I was filling out > this form: > > $ set -o vi > $ date; date; date > Fri Mar 3 12:53:06 CST 2006 > Fri Mar 3 12:53:06 CST 2006 > Fri Mar 3 12:53:07 CST 2006 > > Now, with vi-mode in effect, type 'ESC -' to bring up the > "date..." command, type 'f e' to move the cursor to the > first 'e', type 'r e' to replace the 'e' with 'e', type ';' > to move the cursor to the second 'e', type '.' to repeat > the previous substitution. > > For me, bash goes into a hard loop at this point and I need > to 'kill -9' the process. I can't reproduce it. Can you run this in a debugger and get a stack trace of the point it goes into the hard loop or core dumps? (Or anyone else, if they can produce it as well.) Thanks. 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
