Add --stop-after-empty-queue flag to presage-cli sync#342
Add --stop-after-empty-queue flag to presage-cli sync#342gferon merged 6 commits intowhisperfish:mainfrom
Conversation
Break when receive hits QueueEmpty
|
This makes it impossible to print new messages as they come in. |
|
Thanks! The original code is intended behaviour and essentially waits until the next message comes. "Hanging" is here desirable and you can abort the receiving loop with exiting the program. |
|
You guys are the devs, so you decide, but this definitely isn't normal
behavior for a CLI, and means that this tool (which I understand is more of
a demo) can't really be used as a CLI to signal. Generally CLIs do one
thing per command, and then return their results. There is a perfectly good
"receive" command if you want to receive messages after sending.
I was going to make a similar patch for the register (with CAPTCHA) vs
verify (with SIM code), which in the signal-cli is two steps (again, so
that it can be programmatically controlled)... but I'm guessing you all
won't want that either!
Many thanks for putting this stuff together, I'll play with my own toys
over in my branch :)
…On Mon, Nov 17, 2025 at 4:28 AM Gabriel Féron ***@***.***> wrote:
*gferon* left a comment (whisperfish/presage#342)
<#342 (comment)>
Thanks! The original code is intended behaviour and essentially waits
until the next message comes. "Hanging" is here desirable and you can abort
the receiving loop with exiting the program.
—
Reply to this email directly, view it on GitHub
<#342 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAT6ESHUK7TXHXJN4DIRCIL35GINDAVCNFSM6AAAAACMIZLSWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBQG43TIMJSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
How about adding a CLI argument, which enables this behavior? |
Indeed, but depending on the tool, the result is not a single value, but a stream – especially if the input too is a stream (network or local input). Popular examples are
That would be a good approach. |
|
Sounds good, I'll pursue the CLI argument option.
…On Mon, Nov 17, 2025 at 10:07 AM Hermann Höhne ***@***.***> wrote:
*hoehermann* left a comment (whisperfish/presage#342)
<#342 (comment)>
Generally CLIs do one thing per command, and then return their results.
Indeed, but depending on the tool, the result is not a single value, but a
stream – especially if the input too is a stream (network or local input).
Popular examples are cat, netcat, socat, grep, sed, awk, and many more.
So presage-cli's default behaviour can be regarded "reasonable".
How about adding a CLI argument, which enables this behavior?
That would be a good approach.
—
Reply to this email directly, view it on GitHub
<#342 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAT6ESEPLNBQQV3CEQSR6RL35HQD3AVCNFSM6AAAAACMIZLSWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBSGM2TKMZUG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Ok, please take a look. |
|
+1 to having this cli argument (but for all such commands that opens stream, not only receive) |
Could you please tell why this hanging is implemented in such a strange way? Why does it wait for 60 seconds for a Received::Contacts message? (In case of sending a message) https://github.com/whisperfish/presage/blob/main/presage-cli/src/main.rs#L308 |
|
Yeah, so the CLI wasn't ever made to be a fully fledged client, more of a demo and test platform for the library's API. If you were to make your own client, you poll on the receive stream in parallel with sending a message, in which case it doesn't really matter. Sometimes when linking too many times for example, the main client won't send contacts again, which is why I ended up adding this waiting period. |
|
@thandal thanks for your patience and contribution! I've been busy with a new addition to my family 😄 |
gferon
changed the title
|
Great! And congratulations! |
5 participants
Break when receive hits QueueEmpty