You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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):
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).
The text was updated successfully, but these errors were encountered: