I have a code which does something similar to this one.
while(1){
printf("Telegrams received %d\r",telegrams); //notice \r
telegrams++;
sleep(); // for 0.2s
}
The output from this is one line in a command line which is being updated. However my problem is, that the line isn't updated after every telegram, but only after every 17... (which takes something like 3 seconds).
Is there any way, how to make this work to change every 0.2 seconds?
(when I press enter, there is displayed everything...)
I'm running this on raspberry pi with raspbian.
Thanks
Found an answer - I need to use fflush(stdout) after every printf.
Related
I've wrote this simple script, it generates one output line per second (generator.sh):
for i in {0..5}; do echo $i; sleep 1; done
The raku program will launch this script and will print the lines as soon as they appear:
my $proc = Proc::Async.new("sh", "generator.sh");
$proc.stdout.tap({ .print });
my $promise = $proc.start;
await $promise;
All works as expected: every second we see a new line. But let's rewrite generator in raku (generator.raku):
for 0..5 { .say; sleep 1 }
and change the first line of the program to this:
my $proc = Proc::Async.new("raku", "generator.raku");
Now something wrong: first we see first line of output ("0"), then a long pause, and finally we see all the remaining lines of the output.
I tried to grab output of the generators via script command:
script -c 'sh generator.sh' script-sh
script -c 'raku generator.raku' script-raku
And to analyze them in a hexadecimal editor, and it looks like they are the same: after each digit, bytes 0d and 0a follow.
Why is such a difference in working with seemingly identical generators? I need to understand this because I am going to launch an external program and process its output online.
Why is such a difference in working with seemingly identical generators?
First, with regard to the title, the issue is not about the reading side, but rather the writing side.
Raku's I/O implementation looks at whether STDOUT is attached to a TTY. If it is a TTY, any output is immediately written to the output handle. However, if it's not a TTY, then it will apply buffering, which results in a significant performance improvement but at the cost of the output being chunked by the buffer size.
If you change generator.raku to disable output buffering:
$*OUT.out-buffer = False; for 0..5 { .say; sleep 1 }
Then the output will be seen immediately.
I need to understand this because I am going to launch an external program and process its output online.
It'll only be an issue if the external program you launch also has such a buffering policy.
In addition to answer of #Jonathan Worthington. Although buffering is an issue of writing side, it is possible to cope with this on the reading side. stdbuf, unbuffer, script can be used on linux (see this discussion). On windows only winpty helps me, which I found here.
So, if there are winpty.exe, winpty-agent.exe, winpty.dll, msys-2.0.dll files in working directory, this code can be used to run program without buffering:
my $proc = Proc::Async.new(<winpty.exe -Xallow-non-tty -Xplain raku generator.raku>);
I've noticed that if I press up arrow at a prompt then I get the previous command and up again gets me the command before that.
Whereas if I press up arrow before the previous program has completed then instead I get the previous command displayed, the cursor is at the end of the line, but oh-my-zsh is now in "search for lines that start with ... " mode meaning I can't press up to get the previous command.
I'm sure this behavior is well known and expected but just in case you don't get it you can repo it like this
Type ls return
Type sleep 3 return
wait 3 seconds for prompt to appear
press ⬆ (should show sleep 3)
press ⬆ again (should show ls)
press return (to run ls)
Type sleep 3 return ⬆ (press the up arrow before the 3 seconds elapses)
It should now be showing sleep 3
Press ⬆
it will still be showing sleep 3 but it want it to be showing ls. Instead it is in "search for commands that start with sleep 3 mode instead of just go to previous command mode.
To make try to clear in both cases these are the steps
lsreturn
sleep 3return
⬆
⬆
But they end up with different results depending on if step3 happens before or after step2 finishes.
Note I saw this Q&A: https://unix.stackexchange.com/questions/324623/how-to-make-oh-my-zsh-history-behavior-similar-to-bashs
But that doesn't seem to be what I'm looking for. I like oh-my-zsh's partial line + up = search for lines that start with the partial. What I'm trying to fix is that if I press up on step 2 above it magically inserts a partial where as if I wait until step 2 finishes it doesn't.
How do I get oh-my-zsh to be consistent here so that a premature up arrow behaves the same as a normal up arrow?
I'm surprised this question isn't common. It's seriously infuriating to have the terminal act inconsistently. I'd except most devs using oh-my-zsh to run into this issue all the time and be massively frustrated.
The example above with sleep 3 is only to make it easy to show the problem. In actual usage the problem happens frequently even with short lived commands. I type say git status return git commit somefile -m "short comment" return ⬆⬆ expecting to see "git status". 66% of the time I get git status and the other 34% I get `git commit somefile -m "short comment" and pressing ⬆ again just blinks the cursor and I have to press Ctrl-C to break out of zsh's partial complete mode.
The fact that this does not seem to be a common complaint for oh-my-zsh makes me wonder if I have something setup wrong.
To make it clearer run zsh without oh-my-zsh.
zsh -d -f
autoload -U up-line-or-beginning-search
zle -N up-line-or-beginning-search
bindkey "^[[A" up-line-or-beginning-search
Now try the steps above. You'll get consistent behavior.
This might be an overkill solution but, following this guide you can see that you can bind new actions to the up/down arrow key. So if you add:
bindkey "^[[A" up-line-or-beginning-search # Up
bindkey "^[[B" down-line-or-beginning-search # Down
to your ~/.zshrc, it should remove the functionality you talked about. I managed to get it to work while still maintaining regular search capabilities but this is not thoroughly tested and should probably be used with care.
I have a problem with ksh in that a while loop is failing to obey the "while" condition. I should add now that this is ksh88 on my client's Solaris box. (That's a separate problem that can't be addressed in this forum. ;) I have seen Lance's question and some similar but none that I have found seem to address this. (Disclaimer: NO I haven't looked at every ksh question in this forum)
Here's a very cut down piece of code that replicates the problem:
1 #!/usr/bin/ksh
2 #
3 go=1
4 set -x
5 tail -0f loop-test.txt | while [[ $go -eq 1 ]]
6 do
7 read lbuff
8 set $lbuff
9 nwords=$#
10 printf "Line has %d words <%s>\n" $nwords "${lbuff}"
11 if [[ "${lbuff}" = "0" ]]
12 then
13 printf "Line consists of %s; time to absquatulate\n" $lbuff
14 go=0 # Violate the WHILE condition to get out of loop
15 fi
16 done
17 printf "\nLooks like I've fallen out of the loop\n"
18 exit 0
The way I test this is:
Run loop-test.sh in background mode
In a different window I run commands like "echo some nonsense >>loop_test.txt" (w/o the quotes, of course)
When I wish to exit, I type "echo 0 >>loop-test.txt"
What happens? It indeed sets go=0 and displays the line:
Line consists of 0; time to absquatulate
but does not exit the loop. To break out I append one more line to the txt file. The loop does NOT process that line and just falls out of the loop, issuing that "fallen out" message before exiting.
What's going on with this? I don't want to use "break" because in the actual script, the loop is monitoring the log of a database engine and the flag is set when it sees messages that the engine is shutting down. The actual script must still process those final lines before exiting.
Open to ideas, anyone?
Thanks much!
-- J.
OK, that flopped pretty quick. After reading a few other posts, I found an answer given by dogbane that sidesteps my entire pipe-to-while scheme. His is the second answer to a question (from 2013) where I see neeraj is using the same scheme I'm using.
What was wrong? The pipe-to-while has always worked for input that will end, like a file or a command with a distinct end to its output. However, from a tail command, there is no distinct EOF. Hence, the while-in-a-subshell doesn't know when to terminate.
Dogbane's solution: Don't use a pipe. Applying his logic to my situation, the basic loop is:
while read line
do
# put loop body here
done < <(tail -0f ${logfile})
No subshell, no problem.
Caveat about that syntax: There must be a space between the two < operators; otherwise it looks like a HEREIS document with bad syntax.
Er, one more catch: The syntax did not work in ksh, not even in the mksh (under cygwin) which emulates ksh93. But it did work in bash. So my boss is gonna have a good laugh at me, 'cause he knows I dislike bash.
So thanks MUCH, dogbane.
-- J
After articulating the problem and sleeping on it, the reason for the described behavior came to me: After setting go=0, the control flow of the loop still depends on another line of data coming in from STDIN via that pipe.
And now that I have realized the cause of the weirdness, I can speculate on an alternative way of reading from the stream. For the moment I am thinking of the following solution:
Open the input file as STDIN (Need to research the exec syntax for that)
When the condition occurs, close STDIN (Again, need to research the syntax for that)
It should then be safe to use the more intuitive:while read lbuffat the top of the loop.
I'll test this out today and post the result. I'd hope someone else benefit from the method (if it works).
I built a OS X command line tool in Swift (same problem in Objective-C) for downloading certain files. I am trying to update the command line with download progress. Unfortunately, I cannot prevent the print statement to jump to the next line.
According to my research, the carriage return \r should jump to the beginning of the same line (while \n would insert a new line).
All tests have been performed in the OS X Terminal app, not the Xcode console.
let logString = String(format: "%2i%% %.2fM \r", percentage, megaBytes)
print(logString)
Still, the display inserts a new line. How to prevent this?
Note: This won't work in Xcode's debugger window because it's not a real terminal emulator and doesn't fully support escape sequences. So, to test things, you have to compile it and then manually run it in a Terminal window.
\r should work to move to the beginning of the current line in most terminals, but you should also take a look at VT100 Terminal Control Escape Sequences. They work by sending an escape character, \u{1B} in Swift, and then a command. (Warning: they make some pretty ugly string definitions)
One that you'll probably need is \u{1B}[K which clears the line from the current cursor position to the end. If you don't do this and your progress output varies in length at all, you'll get artifacts left over from previous print statements.
Some other useful ones are:
Move to any (x, y) position: \u{1B}[\(y);\(x)H Note: x and y are Ints inserted with string interpolation.
Save cursor state and position: \u{1B}7
Restore cursor state and position: \u{1B}8
Clear screen: \u{1B}[2J
You can also do interesting things like set text foreground and background colors.
If for some reason you can't get \r to work, you could work around it by saving the cursor state/position just before you print your logString and then restoring it after:
let logString = String(format: "\u{1B}7%2i%% %.2fM \u{1B}8", percentage, megaBytes)
print(logString)
Or by moving to a pre-defined (x, y) position, before printing it:
let x = 0
let y = 1 // Rows typically start at 1 not 0, but it depends on the terminal and shell
let logString = String(format: "\u{1B}[\(y);\(x)H%2i%% %.2fM ", percentage, megaBytes)
print(logString)
Here's an example assuming some async task is taking place with callbacks that pass a Progress type.
// Print an empty string first otherwise whichever line is above the printed out progress will be removed
print("")
let someProgressCallback: ExampleAsyncCallbackType = { progress in
let percentage = Int(progress.fractionCompleted * 100)
print("\u{1B}[1A\u{1B}[KDownloaded: \(percentage)%")
}
The key part is \u{1B}[1A\u{1B}[K and then whatever you want to print out to the screen following.
Your example will only work on the actual command line, not in the debugger console. And you also need to flush stdout for every iteration, like this:
var logString = String(format: "%2i%% %.2fM \r", 10, 5)
print(logString)
fflush(__stdoutp)
I have a problem , when i try to put a breakpoint on debug mode and i record with "swtBot Test Recorder" the generated code is :
bot.contextMenu("Add Breakpoint...").click();
bot.textWithLabel("Line number: ").setText("58");
bot.button("OK").click();
(i pressed right click on the field near line number column and select Add Breakpoint)
But when i put this code in my #Test it's wrong. I need a way to put a breakpoint on a specific line.
This works for Linux, i don't know about Windows:
bot.menu("Navigate").menu("Go to Line...").click();
bot.text().setText(breakpointString);
bot.button("OK").click();
bot.menu("Run").menu("Toggle Line Breakpoint").click();