bash completion issue

[João M . S . Silva]

Hi,

I don't know if this is a know issue. It probably is, because I'm not
a bash-completion long-time user:

$ tar Jxvf pkg/mpfr-3.1.0.tar.xz -C -srbash: compgen: -r: invalid option
compgen: usage: compgen [-abcdefgjksuv] [-o option]  [-A action] [-G
globpat] [-W wordlist]  [-F function] [-C command] [-X filterpat] [-P
prefix] [-S suffix] [word]

After "-sr" I pressed tab for auto-completion. The minus was a typo
that caused the error.

-- 
João M. S. Silva

Re: sed problem

[Dennis Williamson]

Wrong list. Your question is not about Bash and it's not about a bug in
Bash.

Re: sed problem

[dethrophes]

Am 02.04.2012 15:25, schrieb Dennis Williamson:

Wrong list. Your question is not about Bash and it's not about a bug in
Bash.

bash completion not bash.
http://bash-completion.alioth.debian.org/ 

Re: sed problem

[Dennis Williamson]

You must have replied to the wrong message. The original was about sed, not
completion.

Re: Strange behaviour on 'read' from a pipe

[Lluís Batlle i Rossell]

On Sun, Apr 01, 2012 at 06:27:46PM -0400, Chet Ramey wrote:
> On 4/1/12 1:02 PM, Lluís Batlle i Rossell wrote:
> > On Sun, Apr 01, 2012 at 11:06:22AM -0400, Chet Ramey wrote:
> >> On 4/1/12 5:53 AM, Andreas Schwab wrote:
> >>
>  It looks like a simple race condition.  I suspect that the scheduler
>  arranges things so that the child process ends up exiting between the
>  open and the read, but I don't have any real evidence to back it up.
> >>>
> >>> Note that the opening of the pipe as part of the redirection in the
> >>> parent blocks until there is a writer, ie. until the child opens the
> >>> pipe.  Can this open call return EINTR?
> >>
> >> open() is supposed to return EINTR only if interrupted by a signal.  The
> >> only signal I can see occurring is SIGCHLD, and bash installs the SIGCHLD
> >> handler with SA_RESTART.
> > 
> > Then, any idea of what can be happening?
> 
> It looks like a race condition, like I said.  I can't reproduce it on my
> system, so I don't have anything to troubleshoot.

Running "strace ./script" says these next. Notice it hangs at open(). If I use
"strace -f" to follow the child, all works.

OTH, I tried in another computer with the same bash+libc (hashes compared), and
it worked there. But in the problematic computer (linux 3.2.11 x86_64) also
other bash/libc versions hanged.

...
read(255, "\nfunction spawn {\n\"$@\"\ne"..., 281) = 201
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
lseek(255, -113, SEEK_CUR)  = 168
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fd40fbbc9d0) = 29446
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(255, "\nwhile true; do\necho reading"..., 281) = 113
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
brk(0x21b2000)  = 0x21b2000
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "reading\n", 8reading
)= 8
open("/tmp/pipe", O_RDONLYdebug:done
) = ? ERESTARTSYS (To be restarted)
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29446, si_status=0,
si_utime=0, si_stime=0} (Child exited) ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 29446
wait4(-1, 0x7fff2c3c0798, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0x)= 2
open("/tmp/pipe", O_RDONLY

Re: sed problem

[lina]

On Sat, Aug 13, 2011 at 11:14 PM, Francky Leyn  wrote:
> Hello,
>
> I have the following problem: I must write a sed script that
> converts parts of groff syntax to LaTeX syntax.
>
> eg: .BI -o gif_output_file -> \textbf{-o} \textit{gif\_output\_file}
>
> Lets neglect the underscores for the moment.
>
> This can be dan with
>
> s/\.BI \([^ ]*\) \([^ ]*\)/\\textbf{\1} \\textit{\2}/
>
> However, it also has to work for:
>
> eg: .BI -o " gif_output_file
>
> It doesn't: this is the output:
>
> \textbf{-o} \textit{"} gif\_output\_file"
>
> Of couse.
>
> My question: how do you write it correctly in sed?


I came up with a very clumsy one, but easily to see what's going on,
anyway, it seems work.

$ echo "BI -o\" gif_output_file" | sed  -e 's/.* \(\-o\)\([\"]*\)
\(.*\)/\\texbf{\1} \\textit{\2} \\textit{\3}/g; s/\_/\\_/g ; s/
\\textit{}//g '
\texbf{-o} \textit{"} \textit{gif\_output\_file}

echo "BI -o gif_output_file" | sed  -e 's/.* \(\-o\)\([\"]*\)
\(.*\)/\\texbf{\1} \\textit{\2} \\textit{\3}/g; s/\_/\\_/g ; s/
\\textit{}//g '
\texbf{-o} \textit{gif\_output\_file}


You are welcome.


>
> Best reagrds,
>
> Francky

Re: Strange behaviour on 'read' from a pipe

[Lluís Batlle i Rossell]

On Sun, Apr 01, 2012 at 06:27:46PM -0400, Chet Ramey wrote:
> On 4/1/12 1:02 PM, Lluís Batlle i Rossell wrote:
> > On Sun, Apr 01, 2012 at 11:06:22AM -0400, Chet Ramey wrote:
> >> On 4/1/12 5:53 AM, Andreas Schwab wrote:
> >>
>  It looks like a simple race condition.  I suspect that the scheduler
>  arranges things so that the child process ends up exiting between the
>  open and the read, but I don't have any real evidence to back it up.
> >>>
> >>> Note that the opening of the pipe as part of the redirection in the
> >>> parent blocks until there is a writer, ie. until the child opens the
> >>> pipe.  Can this open call return EINTR?
> >>
> >> open() is supposed to return EINTR only if interrupted by a signal.  The
> >> only signal I can see occurring is SIGCHLD, and bash installs the SIGCHLD
> >> handler with SA_RESTART.
> > 
> > Then, any idea of what can be happening?
> 
> It looks like a race condition, like I said.  I can't reproduce it on my
> system, so I don't have anything to troubleshoot.

Trying to reproduce the race, I got rid of 'sleep', and expected this to never
hang. But it hangs where I try. Should I submit this to LKML maybe?

I think it should not hang ever, but maybe I forecast something bad.
-
#!/var/run/current-system/sw/bin/bash

PIPE=/tmp/pipe

rm -f $PIPE
mkfifo $PIPE

function spawn {
echo DONE > $PIPE
}

spawn sleep 1 &

while true; do
echo reading
while read LINE < $PIPE; do
echo $LINE
spawn &
done
done
---

test - StringComparisons dont work

[Fidu]

BASH_VERSION='4.1.5(1)-release'

Hi!
x=sss;
test "rrr" > $x  redirects to file sss, instead of comparing.
Any hint?


Qu2:
How to use
 expr?expr:expr
  conditional operator
   = *= /= %= += -= <<= >>= &= ^= |=
  assignment

I didn't find any working construction?
   ($x=3)?(x=10:x=0);
Operators aren't explained anywhere?

thanks, Andrew

Re: test - StringComparisons dont work

[Greg Wooledge]

On Mon, Apr 02, 2012 at 04:28:54PM +0200, Fidu wrote:
> test "rrr" > $x  redirects to file sss, instead of comparing.
> Any hint?

test rrr \> "$x"

or

test rrr ">" "$x"

However, it should be noted that ">" as a string comparison operator in
the test command is an extension, and not portable.  As such, it might
be better to use [[ so that you can *plainly see* that the code is using
bashisms, and is not sh-compatible.

[[ rrr > "$x" ]]

This gives you the benefit of not needing to quote the > operator, as well
as the visual clue about non-portability.

Re: Strange behaviour on 'read' from a pipe

[Lluís Batlle i Rossell]

On Mon, Apr 02, 2012 at 04:39:19PM +0200, Lluís Batlle i Rossell wrote:
> Trying to reproduce the race, I got rid of 'sleep', and expected this to never
> hang. But it hangs where I try. Should I submit this to LKML maybe?
> 
> I think it should not hang ever, but maybe I forecast something bad.
> -
> #!/var/run/current-system/sw/bin/bash
> 
> PIPE=/tmp/pipe
> 
> rm -f $PIPE
> mkfifo $PIPE
> 
> function spawn {
> echo DONE > $PIPE
> }
> 
> spawn sleep 1 &
> 
> while true; do
> echo reading
> while read LINE < $PIPE; do
> echo $LINE
> spawn &
> done
> done
> ---

Adding a 'sleep 0.1' before 'echo DONE' makes it hang very early in three linux
machines I tried. Let me know if you can reproduce it. Let me know if this helps
you reproduce the problem. Here again:

--
#!/bin/sh

PIPE=/tmp/pipe

rm -f $PIPE
mkfifo $PIPE
set -x

spawn() {
sleep 0.1
echo DONE > $PIPE
}

spawn &

while true; do
while read LINE < $PIPE; do
echo $LINE
spawn &
done
done
---

Re: Strange behaviour on 'read' from a pipe

[Greg Wooledge]

On Mon, Apr 02, 2012 at 08:46:12PM +0200, Lluís Batlle i Rossell wrote:
> #!/bin/sh

You're running this in sh?  But reporting it as a bug in bash?

> PIPE=/tmp/pipe
> 
> rm -f $PIPE
> mkfifo $PIPE
> set -x
> 
> spawn() {
> sleep 0.1
> echo DONE > $PIPE
> }
> 
> spawn &
> 
> while true; do
> while read LINE < $PIPE; do
> echo $LINE
> spawn &
> done
> done

I ran this, with #!/bin/bash and with sleep 1 instead of sleep 0.1,
on an HP-UX 10.20 system and a Debian 6.0 (Linux) system.  For me,
it printed "DONE" once per second until I pressed ctrl-C, on both
systems.

Changing the sleep 1 back to sleep 0.1 and re-running on the Linux
system produced the same result, just 10 times as fast.

Changing the #!/bin/bash to #!/bin/sh and re-re-running on Linux
still produced the same result.

Re: Strange behaviour on 'read' from a pipe

[Lluís Batlle i Rossell]

On Mon, Apr 02, 2012 at 03:29:33PM -0400, Greg Wooledge wrote:
> On Mon, Apr 02, 2012 at 08:46:12PM +0200, Lluís Batlle i Rossell wrote:
> > #!/bin/sh
> 
> You're running this in sh?  But reporting it as a bug in bash?

In that case, sh points to bash. Sorry for the confusion I could have caused.

> > while true; do
> > while read LINE < $PIPE; do
> > echo $LINE
> > spawn &
> > done
> > done
> 
> I ran this, with #!/bin/bash and with sleep 1 instead of sleep 0.1,
> on an HP-UX 10.20 system and a Debian 6.0 (Linux) system.  For me,
> it printed "DONE" once per second until I pressed ctrl-C, on both
> systems.
> 
> Changing the sleep 1 back to sleep 0.1 and re-running on the Linux
> system produced the same result, just 10 times as fast.
> 
> Changing the #!/bin/bash to #!/bin/sh and re-re-running on Linux
> still produced the same result.

I found the race condition, after implementing it in C. It's there in the script
too.

It can happen that the child spawns, but does not reach the "open pipe writing"
call of echo DONE, while the loop goes another round, runs read LINE again, and
reads *EOF*, exiting the inner while loop.

Sorry for the headache.

Here is the proper version without race condition, that uses the close/read()=0
as synchronisation:

---
#!/bin/bash

PIPE=/tmp/pipe

rm -f $PIPE
mkfifo $PIPE

spawn() {
echo DONE > $PIPE
}

spawn &

# read A  -- to read EOF from the child, to ensure it closed the pipe.
while (read LINE ; echo $LINE; read A; echo child closed) < $PIPE; do
spawn &
done


Best regards,
Lluís.