Repository navigation
Feature Request: text_only output support #14
Description
Activity
- addedenhancementNew feature or requestNew feature or requestgood first issueGood for newcomersGood for newcomers
on Sep 17, 2026 Hi @ritwik-g, I'd like to work on adding the
--text-onlyflag support for whisperer extraction. Could you please assign this issue to me?Hi @ritwik-g, I'd like to work on adding the
--text-onlyflag support for whisperer extraction. Could you please assign this issue to me?Hi @miraj2729 please feel free to raise a PR and share here. We can assign it to you once the initial PR is opened
Thanks @ritwik-g! I'm currently setting up the environment and writing the code for this. I'll submit the PR shortly. Please hold this issue for me!
Reacted by Ritwik GHi, I have addressed all the feedback and fixed the checks. The PR is ready for review when you get a chance. Thanks!
This is the PR right? @chandrasekharan-zipstack
Reacted by Chandrasekharan Mchandrasekharan-zipstack commented
on Sep 18, 2026 ContributorMore actionsThis is already covered on
mainby the generic-o rawoutput format, which prints the extraction'sresult_textalone, unwrapped, with layout preserved:unstract whisper extract invoice.pdf -o raw > invoice.txt unstract whisper retrieve <whisper_hash> -o raw
-o rawworks across product commands (each declares which field it prints;unstract --discover fulllists them), so there is no whisperer-specific flag to add.How close is it to the API's
text_only? Functionally identical for the caller:result_textis the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: withtext_only=truethe server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible.Why not pass
text_onlystraight through to the API? The CLI calls the API via thellmwhisperer-clientSDK (currently pinned at 2.9.0), andwhisper_retrieve()there does not expose atext_onlyargument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local-o rawalready gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner.If the gap here was discoverability rather than capability, a README example or a line in the
whisper retrievehelp text is the change to make.
Correction (2026-09-18): the two examples above put
-o rawafter the subcommand, which fails today withNo such option '-o'(the bug in #12 / #15). Until #19 merges, global flags go before the subcommand:unstract -o raw whisper extract invoice.pdf > invoice.txt unstract -o raw whisper retrieve <whisper_hash>
PR #19 makes both placements work and closes this issue.
This is already covered on
mainby the generic-o rawoutput format, which prints the extraction'sresult_textalone, unwrapped, with layout preserved:unstract whisper extract invoice.pdf -o raw > invoice.txt
unstract whisper retrieve <whisper_hash> -o raw
-o rawworks across product commands (each declares which field it prints;unstract --discover fulllists them), so there is no whisperer-specific flag to add.How close is it to the API's
text_only? Functionally identical for the caller:result_textis the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: withtext_only=truethe server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible.Why not pass
text_onlystraight through to the API? The CLI calls the API via thellmwhisperer-clientSDK (currently pinned at 2.9.0), andwhisper_retrieve()there does not expose atext_onlyargument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local-o rawalready gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner.If the gap here was discoverability rather than capability, a README example or a line in the
whisper retrievehelp text is the change to make.Okay @chandrasekharan-zipstack in that case this ticket is invalid. Lets close this. Lets close the PR also. But anyway please note there are some bugs that might make this usage itself bit difficult.
@miraj2729 thank you for the effort. But apologies since this might not be an actual requirement anymore. Please feel free to raise contributions in the future.
- Thank you for the clarification, @ritwik-g! Completely understand. It was a great learning experience working on this repository. Looking forward to contributing to other issues in the future!…On Fri, 18 Sept 2026 at 13:49, Ritwik G ***@***.***> wrote: *ritwik-g* left a comment (Zipstack/unstract-cli#14) <#14 (comment)> This is already covered on main by the generic -o raw output format, which prints the extraction's result_text alone, unwrapped, with layout preserved: unstract whisper extract invoice.pdf -o raw > invoice.txt unstract whisper retrieve <whisper_hash> -o raw -o raw works across product commands (each declares which field it prints; unstract --discover full lists them), so there is no whisperer-specific flag to add. *How close is it to the API's text_only?* Functionally identical for the caller: result_text *is* the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: with text_only=true the server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible. *Why not pass text_only straight through to the API?* The CLI calls the API via the llmwhisperer-client SDK (currently pinned at 2.9.0), and whisper_retrieve() there does not expose a text_only argument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local -o raw already gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner. If the gap here was discoverability rather than capability, a README example or a line in the whisper retrieve help text is the change to make. Okay @chandrasekharan-zipstack <https://github.com/chandrasekharan-zipstack> in that case this ticket is invalid. Lets close this. Lets close the PR also. But anyway please note there are some bugs that might make this usage itself bit difficult. #12 <#12> @miraj2729 <https://github.com/miraj2729> thank you for the effort. But apologies since this might not be an actual requirement anymore. Please feel free to raise contributions in the future. — Reply to this email directly, view it on GitHub <#14?email_source=notifications&email_token=COTTY52XZ2AYNIX2UB4LZE35PTSKJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZSGY4TIMJUGA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5726941404>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/COTTY54XMEPTPSSMHSWCH6L5PTSKJAVCNFSNUABGKJSXA33TNF2G64TZHMYTGMBXG4YTKOJZG45US43TOVSTWNJUHEYDINBWGQ3TTILWAI> . You are receiving this because you were mentioned.Message ID: <Zipstack/unstract-cli/issues/14/5726941404 ***@***.***>Reacted by Ritwik G and Chandrasekharan M
The current cli output for whisperer extraction contains the result and the metadata as well.
Retrieve API supports a
text_onlyoutput which simply shows the text result as it is (If it is layout preserved the output will also be layout preserved. This mode can be useful when we only need theresult_text.