Open dr-kd opened 2 months ago
Hi @dr-kd and thanks for your detailed report.
For your first point, output messages of the objects import
command amongst others (objects delete
, etc.) were not designed to be machine readable in the first place, and that's why we skip them if we detect a non-tty output.
For most of those commands, the return code can be used to detect success / failure.
I am curious about your use case, your intent was to parse the success message and to extract information from it?
Second point: Looks like a bug, looking into it.
Return code makes sense - in that manner I can run extra stuff in the pipe with some && [success command here] || [fail command here]
- I just found the absence of output a little confusing and counter-intuitive as it's not the usual behaviour I'd expect to see. I would imagine if I was getting the output I'd be piping it straight into our opensearch dashboards analytics via syslog for reporting. And in that case there would be fewer moving parts and thus a smaller surface for failure rather than relying on extra && ||
type constructs.
@dr-kd Understood 👍
Potentially, we could introduce a FORCE_TTY
kind of env variable, that would force messages output even if a non-tty shell is detected 🤔
I think a flag --tty
or maybe --stdio
might be a better fit - then one's script has to explicitly point out the fact that it's a script with standard output handles at the time it is is told to run.
Agreed on the flag. Just a gotcha: This thing could not play nice with the progress indicators / loaders that the CLI currently have. Outputting those to something else than a terminal might wield weird results. We will have to check if we can avoid forcing tty on those.
A couple of issues spotted when running algolia CLI headless:
1 - important - using algolia cli for reporting from scripts
Seems like algolia CLI is a good component for no code integrations if this was fixed
results in this output on console and the empty file
/tmp/result.txt
:I would expect to see something like the below in the file and console but it's empty.
This one is less important but still significant
Shows that the CLI is written with some assumptions about what type of system it's running on. In this case a headless VM in the cloud:
In this case where xdg-open is unavailable I'd expect the tool to echo the URL.