LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

Reply
 
Search this Thread
Old 09-01-2006, 07:23 AM   #16
jahvascriptmaniac
Member
 
Registered: Aug 2006
Posts: 34

Rep: Reputation: 15

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.
 
Old 09-01-2006, 07:25 AM   #17
jahvascriptmaniac
Member
 
Registered: Aug 2006
Posts: 34

Rep: Reputation: 15
Hi !
You always 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 formatted $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 really 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 analysis ???

BTW, thanx for helping, now i'll be able to do fix my script !
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bash scripting question nitroid Programming 3 04-13-2006 07:08 AM
Bash Scripting Question fiod Linux - Newbie 4 11-19-2005 05:09 AM
Bash scripting question Hammett Linux - General 4 11-29-2004 06:29 AM
bash scripting question Andy@DP Programming 4 04-13-2004 05:06 PM
Bash Scripting Question Rezon Programming 2 10-30-2003 10:16 AM


All times are GMT -5. The time now is 05:33 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration