> Since those are not numeric, bash treats them as expressions to be
> evaluated. You don't have to use the $ to obtain variable evaluation
> when using [[ or [. You get:
c=1;a="c";b=2;[[ a -lt b ]]; echo $?
0
c=3;a="c";b=2;[[ a -lt b ]]; echo $?
1
I see. I was aware of explicit indirection as
On 3/6/11 2:53 PM, Doug McMahon wrote:
> with the current bash used in ubuntu 11.04 there no longer is a
> ~/.bash_history created
> If there is an existing ~/.bash_history in place or one is inadvertently
> created, *see below, then it will not be written to
Demonstrably false:
(1)$ ./bash
(2)$
On 3/6/11 3:13 PM, Peggy Russell wrote:
> Hi Chet,
>
> Summary
> ***
> When a variable name and its' value are the same characters (a="a"),
> a recursion error occurs.
Quite true.
If you expand the problem expression, you get
[[ a -lt b ]]
Since those are not numeric, bash treats them as e
On 3/7/11 11:52 AM, Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:24 AM, Linus Torvalds
> wrote:
>>
>> and I think one reason why the race is hard to get rid of is simply
>> that system call return is _the_ common point of signal handling in
>> UNIX (technically, obviously any return to user sp
On 3/7/11 12:42 PM, Oleg Nesterov wrote:
> On 03/07, Chet Ramey wrote:
>>
>>> On 03/07, Chet Ramey wrote:
*** 3090,3096
--- 3099,3107
waitpid_flags |= WNOHANG;
}
+ waiting_for_child++;
pid = WAITPID (-1, &status, waitpid_flags)
with the current bash used in ubuntu 11.04 there no longer is a
~/.bash_history created
If there is an existing ~/.bash_history in place or one is inadvertently
created, *see below, then it will not be written to
If one was to crash the system while a command was running in a terminal
then a ~/.ba
Hi Chet,
Summary
***
When a variable name and its' value are the same characters (a="a"),
a recursion error occurs.
Steps to recreate "problem"
***
Step 1:
1. Execute the command
.
a="cat";b="dog";[[
(03/07/2011 12:22 PM), Steven W. Orr wrote:
> Sorry, but I'm not sure I see why this helps.
>
> I think it says (I assume you meant a space between the 100 and the
> greater than, otherwise you're just trying to close channel 100):
>
> foo='sleep 100 >&- 2>&- &'
Yeah. That's how I typed it. Your
On Mon, Mar 07, 2011 at 03:22:26PM -0500, Steven W. Orr wrote:
> foo='sleep 100 >&- 2>&- &'
>
> "Sleep for 100 seconds and then close channel 1 and channel 2."
No. Redirections are done first.
On 3/7/2011 2:02 PM, Micah Cowan wrote:
(03/07/2011 10:31 AM), Steven W. Orr wrote:
I want to compute a command string which will end up in foo.
Then I want to run that command and cause stdout and stderr to be piped
to tee for safe keeping while it also goes to the screen.
After the command f
(03/07/2011 10:31 AM), Steven W. Orr wrote:
> I want to compute a command string which will end up in foo.
>
> Then I want to run that command and cause stdout and stderr to be piped
> to tee for safe keeping while it also goes to the screen.
>
> After the command finishes, I need tee to exit.
>
I want to compute a command string which will end up in foo.
Then I want to run that command and cause stdout and stderr to be piped to tee
for safe keeping while it also goes to the screen.
After the command finishes, I need tee to exit.
It sounds easy, but it's not.
eval "$foo" 2>&1 | tee
On 03/07, Chet Ramey wrote:
>
> > On 03/07, Chet Ramey wrote:
> > >
> > > *** 3090,3096
> > > --- 3099,3107
> > > waitpid_flags |= WNOHANG;
> > > }
> > >
> > > + waiting_for_child++;
> > > pid = WAITPID (-1, &status, waitpid_flags);
> >
> > OK, and what
On Mon, Mar 7, 2011 at 8:45 AM, Chet Ramey wrote:
>
> The one thing that jumps out at me here is the number of signal-handling
> system calls. wait_sigint_handler gets installed and removed as the
> SIGINT handler a lot. I wonder if we would see an improvement if I
> used a global SIGINT handler
> On 03/07, Chet Ramey wrote:
> >
> > > So I don't think my patch is really doing what it _intends_ to do.
> >
> > Let's take a step back and approach this a different way. Instead of
> > trying to intuit whether or not the child did anything with the SIGINT,
> > let's try to make the race conditi
> The trace I just captured looks like this:
>
> 08:12:54.424327 clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x7fdf2ad8e9f0) = 15397
> 08:12:54.424394 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> 08:12:54.424432 rt_sigprocmask(SIG_BLOCK, [CH
On Mon, Mar 7, 2011 at 8:24 AM, Linus Torvalds
wrote:
>
> and I think one reason why the race is hard to get rid of is simply
> that system call return is _the_ common point of signal handling in
> UNIX (technically, obviously any return to user space, but there are
> no appreciable interrupts etc
On 03/07, Chet Ramey wrote:
>
> > So I don't think my patch is really doing what it _intends_ to do.
>
> Let's take a step back and approach this a different way. Instead of
> trying to intuit whether or not the child did anything with the SIGINT,
> let's try to make the race condition smaller.
O
On Mon, Mar 7, 2011 at 7:52 AM, Chet Ramey wrote:
>
> Let's take a step back and approach this a different way. Instead of
> trying to intuit whether or not the child did anything with the SIGINT,
> let's try to make the race condition smaller.
I can still easily see the porblem. I think your pa
> So I don't think my patch is really doing what it _intends_ to do.
Let's take a step back and approach this a different way. Instead of
trying to intuit whether or not the child did anything with the SIGINT,
let's try to make the race condition smaller.
The following patch is a very small chan
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-007
Bug-Reported-by:Matthias Klose
Bug-Reference-ID: <4d6fd2ac.1010...@debian.org>
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug
[...]
> If your question is whether or not the call to `g' can result
> in an unset
> variable error even though f has a local copy already
> declared, the answer
> is no. That is ksh93-style static scoping, and bash does not have it.
>
Yes, that was my question. Thanks for the answer. I t
22 matches
Mail list logo
