[GH-ISSUE #48] Better scripting support (URLs output, ...) #44

New issue

Open

opened 2026-03-02 23:01:58 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 23:01:58 +03:00

Owner

Originally created by @xmo-odoo on GitHub (May 14, 2021).
Original GitHub issue: https://github.com/agrinman/tunnelto/issues/48

This overlaps with but is more general than #25 I think.

The current output of tunnelto is somewhat uncomfortable when using it in a scripting context (e.g. as part of a script or as a tunneling tool for an S2S integration test suite):

getting the public URL requires reading stderr, which is not great when simultanously trying to keep / pipe stderr for error reporting / inspection
care has to be taken to avoid blocking
the formatting of the output is not really conducive to parsing either

I'm thinking one option would be a riff on the usual pidfile method: the ability to give tunnelto a directory name, and it'd write the public URL to $outdir/$pid. tunnelto's pid should be easy for the parent proces to retrieve.

For forward-compatibility purposes, the file could be written in a machine-readable format (e.g. json) so it could be extended more easily in the future, though I'm not entirely sure what else would be added to it, unless it grows an ngrok-like automation API (I don't know if that's in the plans, in that case also writing the endpoint would be useful).

Originally created by @xmo-odoo on GitHub (May 14, 2021). Original GitHub issue: https://github.com/agrinman/tunnelto/issues/48 This overlaps with but is more general than #25 I think. The current output of tunnelto is somewhat uncomfortable when using it in a scripting context (e.g. as part of a script or as a tunneling tool for an S2S integration test suite): * getting the public URL requires reading stderr, which is not great when simultanously trying to keep / pipe stderr for error reporting / inspection * care has to be taken to avoid blocking * the formatting of the output is not really conducive to parsing either I'm thinking one option would be a riff on the usual pidfile method: the ability to give `tunnelto` a directory name, and it'd write the public URL to `$outdir/$pid`. tunnelto's pid should be easy for the parent proces to retrieve. For forward-compatibility purposes, the file could be written in a machine-readable format (e.g. json) so it could be extended more easily in the future, though I'm not entirely sure what else would be added to it, unless it grows an ngrok-like automation API (I don't know if that's in the plans, in that case also writing the endpoint would be useful).