Make local `-listen` binding opt-in, or allow `-listen` to use first available port in a range.

[strazto]

tl;dr

It's annoying that running a new session of tty-share fails if localhost:8000 is unavable, eg another tty-share session is using it. (especially when you only care about the public session)

It would be nice if the default was to bind to the first available port in a range, eg localhost:8000-8010. If 8000 is taken, then the session binds to localhost:8001 etc.

Details

It's great that tty-share's flexibility has been enhanced, but I find that a few new features detract from its vision as the "easy" non-astonishing method of sharing your terminal.

One such feature is the local session feature. I find that this feature typically makes launching parallel sessions annoying, or launching sessions when localhost:8000 has been bound, for example, if I'm running a local dev server.

The solution is fairly simple, of course, just give it the listen arg- tty-share -listen localhost:8001, but this step is still a step away from tty-share being the "easy mode" of session sharing.

This could be resolved by either:

• Making the local address binding optional, or
• Allowing users to specify a range of ports, similar to the mosh over which to iterate, & bind on, failing only if no port was available, ie tty-share -listen localhost:8000-8010.
  • A reasonable default would probably be localhost:8000-8010.
  • I'm not sure about
  • the best/most conventional syntax to specify port ranges in the argument, (localhost:8000-8010 vs localhost:8000:8010)
    • (mosh uses 8000:8010 syntax, but you also choose the bound address separately from the port, so it looks less weird because the colon only means one thing)
    • csf also uses the start:end convention, same note as above.
  • or whether its worth allowing multiple ranges, as in "localhost:8000-8010,8080,8888".

To me, specifying a port range feels like the better option

• simpler from the perspective of users who just want the public proxy, and no worse for users who want to bind to a local port for whatever reason.
• Besides the step of parsing the argument, iterating over the range & binding to a port, less complex application logic, as a local listening address is always used.

A few caveats:

• One useful thing about this binding issue is that it does remind me that I've got a session running I might want to kill.
• I was developing tty-share when I ran into this, so I was probably spinning up more sessions than the average user.

[elisescu]

Fair point, @matthewstrasiotto. At first sight, I tend to agree with your suggested approach, of using the next available port in a range (with a reasonable default range), but I would like to think a bit more about it. And hopefully will get some time to look into it soon

[0x326]

I think a boolean flag -local would be appropriate (e.g. -local=true, -local=false, true by default). I would prefer this over a port-range-only option, but I think a boolean flag and a port range would be appropriate too