Hi !
You allways lean things on a forum (c) (r) (tm). I didn't knew you could use a "for (( i=0; i<100; i++ )); do" construction. Thanx for the tip :-p !
Quote:
|
Originally Posted by jschiwal
I think that the chunkiness is caused by buffering in the pipe.
echo "$(ulimit -p)*1024 | bc"
8192
|
Yep. But it's not the pipe
, it's tr which seems to work line by line.
I had the same problem than tvynr, so tried this code :
Code:
$ cat testprog
i=0
# Do an infinite loop :
while test 0; do# Output the number in a 00012 shape. So it looks nice.
# And go down one line each time, cause otherwise :
# The chunk ends with something similar to
# 1397
# 1398
# 1399
# 14 -> it spat a chunk
# So with \r, you get :
# 1499 -> X_X
j="$i"
# While j is /shorter/ than 6, fill it with zeroes.
while [ ${#j} -lt 6 ]; do j="0$j"; done
# Print formated $i and go down 1 line :
echo -ne "$j\r\033[1B"
# Wait 5/100 th of a second.
usleep 50000
i=$[$i+1]
done
$ ./testprog
00000
00001
00002
.....
01397
01398
01399
014
# This is first chunk (it doesn't realy end with 01400).
# You press control-c
$ ./testprog>testoutput
# Wait for a while
# Press control-c
$ vi testoutput
# type /014
# When you're on the last line of 1st chunk, delete what's afterwards.
# exit vi.
$ ls -l testoutput
# And... Oh, my ! it's 8192 chars long !!!
Now, if the pipe was buffering, we couldn't get anything smooth with the read method.
So read does the following :
read 1st char. It's not \r. Continue.
read 2nd char. It's not \r. Continue.
...
read 6nd char. It IS \r. Echo it.
loop.
While tr/sed/other do the following.
read 1st char. It's not \n. Continue.
read 2nd char. It's not \n. Continue.
...
read 8193nd char. It's not \n. Buffer full.
Process it anyway (you can check this by doing tr '\r' 'abc').
loop.
So sed/grep/tr/ others are stupid. Cause they don't do this when their output isn't piped.
What is the sed option to tell it to do a per-character analyzis ???
BTW, thanx for helping, now i'll be able to do something similar.
