Re: Questions to bash "read" builtin functionality (and supposed problem with while).
I have a similar problem to report as Fiedler Roman regarding read and also
another problem regarding while. Maybe the while case is intended behavior
though. =)
See comments in the script below.
bash --version
GNU bash, version 4.2.39(1)-release (x86_64-redhat-linux-gnu)
Example script starts here.
#!/bin/bash -x
fifo_dir=`mktemp -d`
xl_console_input="$fifo_dir/fifo_in"
xl_console_output="$fifo_dir/fifo_out"
function domain_running
{
local domain="$1"
xl list "$domain" >/dev/null 2>&1
}
# I've also tried variants like:
# IFS= read -N 16384 -r -t 2 -d '' data
# which neither put anything into $data.
function poke_console
{
local data
local ret
# Pole the console, see what happens.
echo
# Now read all data available from the console.
while :
do
# Now, read from the console, with \n as delimiter.
read -t 2 data
ret=$?
# Problem is here, $data is empty when read has timed
out, i.e, not
# read a complete line. I expect data to contain the
line read so
# far.
echo "$data" >&2
# If we didn't time out, there's more data available
# that we want to flush.
[[ $ret -gt 128 ]] || continue
# Ok, so we've timed out, I already know that $data
doesn't contain the
# reminder of the line, let's try getting it by
looking for another delimiter.
# : is the delimiter we expect if we're seeing the
login prompt which should
# be the usual case.
read -d':' -t 1 data
# Data is still empty here ...
if [[ -n "$data" ]]
then
[[ "$data" =~ "login" ]] && return 0
fi
# And this delimiter is if someone has left the
console logged in.
read -d'#' -t 1 data
# ... and here too.
if [[ -n "$data" ]]
then
[[ "$data" =~ 'root@' ]] && return 1
fi
# And data is empty on the next iteration of the loop too.
done < "$xl_console_output"
# Console is in an unknown state.
return 100
}
function parse_until
{
# Cut away for brevity.
}
function remove_pipe_dir
{
rm -r "$fifo_dir"
}
trap remove_pipe_dir TERM
# It the below also a bug?
# while can't handle nulls, this doesn't work:
# while read -d \x00 cfg
# while this does work:
# read -d \x00 test < <(find . -name some_file -print0) ; echo $test
while read cfg
do
name=`sed -rn 's/name.*=[[:space:]]*"(.*)"/\1/p' "$cfg"`
domain_running "$name" || continue
mkfifo "$xl_console_input"
mkfifo "$xl_console_output"
xl console "${name}" < "$xl_console_input" > "$xl_console_output" &
(
poke_console
case $? in
0)
echo root
parse_until 'assword'
echo password
;;
1)
echo "\`date\` ': BAD YOU! CONSOLE WAS NOT
LOGGED OUT!' >> /root/I_will_never_again_leave_my_computer_unlocked"
;;
100)
echo "Can't find login prompt nor root prompt." >&2
esac
parse_until 'root@' '#' || exit $? # Exit if we can't login.
echo date -u -s \""`date -u "+%Y-%m-%d %H:%M:%S.%N
UTC" -d "now"`"\"
parse_until 'root@' '#'
echo exit
) > "$xl_console_input"
rm "$xl_console_input" "$xl_console_output"
# This doesn't work, combined with the read -r \x00 above.
#done < <(find /guests/vmname -name "xl.config" -print0)
done < <(find /guests/vmname -name "xl.config")
End of script here.
Sample output, supposed error marked in the output below:
[root@machine ~]# sync_time
++ mktemp -d
+ fifo_dir=/tmp/tmp.SbGOeR3Nk1
+ xl_console_input=/tmp/tmp.SbGOeR3Nk1/fifo_in
+ xl_console_output=/tmp/tmp.SbGOeR3Nk1/fifo_out
+ trap remove_fifo_dir TERM INT
+ read cfg
++ find /guests/vmname -name xl.config
++ sed -rn 's/name.*=[[:space:]]*"(.*)"/\1/p' /guests/vmname/xl.config
+ name=vmname
+ domain_running vmname
+ local domain=vmname
+ xl list vmname
+ mkfifo /tmp/tmp.SbGOeR3Nk1/fifo_in
+ mkfifo /tmp/tmp.SbGOeR3Nk1/fifo_out
+ xl console vmname
+ poke_console
+ local data
+ local ret
+ echo
+ :
+ read -t 2 data
+ ret=0
+ echo $'\r'
+ [[ 0 -gt 128 ]]
+ continue
+ :
+ read -t 2 data
+ ret=0
+ echo $'\r\r'
+ [[ 0 -gt 128 ]]
+ continue
+ :
+ read -t 2 data
+ ret=0
' echo 'Fedora release 17 (Beefy Miracle)
Fedora release 17 (Beefy Miracle)
+ [[ 0 -gt 128 ]]
+ continue
+ :
+ read -t 2 data
+ ret=0
' echo 'Kernel 3.6.6-1.fc17.x86_64 on an x86_64 (hvc0)
Kernel 3.6.6-1.fc17.x86_64 on an x86_64 (hvc0)
+ [[ 0
|& in bash?
One feature of other shells (e.g. zsh and tcsh) I'd really love to have in bash is "|&", which redirects both stdout and stderr--basically just a shortcut for "2>&1 |". Has this ever been considered for bash? It may not seem like much of a difference, but it's saved me an enormous numbers of keystrokes over the years. There's nothing more frustrating in bash than getting to (or worse, just past) "|" and realizing I need to redirect stderr as well as stdout, then cursoring back and executing a keyboard-acrobatic "2>&1" for the zillionth time - John
Re: |& in bash?
On 1/17/13 1:01 PM, John Caruso wrote: > One feature of other shells (e.g. zsh and tcsh) I'd really love to have > in bash is "|&", which redirects both stdout and stderr--basically just > a shortcut for "2>&1 |". Has this ever been considered for bash? That has been in bash since bash-4.0. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: |& in bash?
In article , Chet Ramey wrote: > On 1/17/13 1:01 PM, John Caruso wrote: >> One feature of other shells (e.g. zsh and tcsh) I'd really love to have >> in bash is "|&", which redirects both stdout and stderr--basically just >> a shortcut for "2>&1 |". Has this ever been considered for bash? > > That has been in bash since bash-4.0. I'm simultaneously happy and chagrined :-) (most of the servers I manage are on bash 3.x, so I hadn't encountered it). Thanks. - John
Re: Questions to bash "read" builtin functionality (and supposed problem with while).
On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas wrote: > I have a similar problem to report as Fiedler Roman regarding read and also > another problem regarding while. Maybe the while case is intended behavior > though. =) > # It the below also a bug? > # while can't handle nulls, this doesn't work: > # while read -d \x00 cfg > # while this does work: > # read -d \x00 test < <(find . -name some_file -print0) ; echo $test > > \x00 doesn't mean anything special for bash it's just an "x" followed by 2 zeros (echo, printf can interpret it and it has a special meaning inside $'') Even if it did, you cannot really pass the null byte as an argument, bash uses null delimited string so the best you can do is to pass the empty string: read -d '' The good thing is that it works to read null delimited input! you need a bit more work to be fully safe though: while IFS= read -rd ''; do . done < <(find ... -print0) Pierre PS: next time consider trimming your use case to avoid us avoid to search for your problems.
interrupted system call when using named pipes on FreeBSD
this is somewhat a continuation of this thread:
http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html
i've gotten more or less the same report in Gentoo:
http://bugs.gentoo.org/447810
the simple test case is:
$ cat test.sh
#!/bin/bash
while :; do
(:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)&
while read x ; do : ; done < <(echo foo)
done
execute `./test.sh` and we see failures pretty much all the time.
a simple patch to workaround/fix the issue by Yuta SATOH:
--- bash-4.2/redir.c
+++ bash-4.2/redir.c
@@ -632,7 +632,9 @@
}
else
{
- fd = open (filename, flags, mode);
+ do {
+ fd = open (filename, flags, mode);
+ } while ((fd < 0) && (errno == EINTR));
#if defined (AFS)
if ((fd < 0) && (errno == EACCES))
{
but we're not sure if this is the route to take ? seems like if bash is
handling SIGCHLD, there's no avoiding this sort of check.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] bash: speed up `read -N`
On Monday 19 November 2012 19:46:17 Mike Frysinger wrote: > Rather than using 1 byte reads, use the existing cache read logic. > This could be sped up more, but this change is not as invasive and > should (hopefully) be fairly safe. ping ... -mike signature.asc Description: This is a digitally signed message part.
