Issues capturing output of algolia cli / running on headless systems

[dr-kd]

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

psql -t postgres://user@pass:host.name/mydb -c 'select row_to_json(a) from my_data a' \
    |      algolia objects import my_poc --file - \
| tee /tmp/result.txt ; cat /tmp/result.txt && echo ===END==

results in this output on console and the empty file /tmp/result.txt:

===END==

I would expect to see something like the below in the file and console but it's empty.

✓ Successfully imported 9999 objects to my_poc 9.99999s

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:

   $ algolia open cli-repo
   exec: "xdg-open": executable file not found in $PATH

In this case where xdg-open is unavailable I'd expect the tool to echo the URL.

[clemfromspace]

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.

[dr-kd]

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.

[clemfromspace]

@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 🤔

[dr-kd]

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.

[clemfromspace]

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.