curl/trurl

ability to get told the port number was not provided?

bagder opened this issue · 5 comments

Right now trurl provides the default port number if none was provided and trurl knows the URL scheme. Like for https://example.com it shows 443.

I can imagine that there might be use cases where you actually rather want to know that no port number was present in the URL. If so, how should we ask for that information?

Perhaps a flag --explicit-port where if this is passed and no port is specified then it would print none or null or something? or in the JSON output it could be something like:

$ trurl "https://fake.host/hello#frag" --set user=::moo:: --json --explicit-port
 [
    {
      "url": "https://%3a%3amoo%3a%3a@fake.host/hello#frag",
      "scheme": "https",
      "user": "::moo::",
      "host": "fake.host",
      "port": null,
      "path": "/hello",
      "fragment": "frag"
    }
  ]

Perhaps a flag --explicit-port where if this is passed and no port is specified then it would print none or null or something? or in the JSON output it could be something like:

$ trurl "https://fake.host/hello#frag" --set user=::moo:: --json --explicit-port
 [
    {
      "url": "https://%3a%3amoo%3a%3a@fake.host/hello#frag",
      "scheme": "https",
      "user": "::moo::",
      "host": "fake.host",
      "port": null,
      "path": "/hello",
      "fragment": "frag"
    }
  ]

I would suggest adding a default_port key to the JSON output, as shown below:

[
  {
    "url": "https://%3a%3amoo%3a%3a@fake.host/hello#frag",
    "scheme": "https",
    "user": "::moo::",
    "host": "fake.host",
    "port": null,
    "default_port": "443",
    "path": "/hello",
    "fragment": "frag"
  }
]

But the --explicit-port option is way better.

For JSON output I prefer using the different keys port + default_port for consistency. For --get output I prefer adding a qualifier to the {port} somehow so that a user can actually ask for and use both in the same output. Maybe like:

$ trurl https://example.com --get 'used: {port} provided: {raw:port}'
used: 443 provided:

(The raw name obviously subject for improvement)

I like raw because it is short, but it feels unintuitive. maybe {defined:port} or {explicit:port} but that feels long. Another option may be using a modifier character, something like {port!} but I don't think anything else works like this in trurl.

For JSON output I prefer using the different keys port + default_port for consistency. For --get output I prefer adding a qualifier to the {port} somehow so that a user can actually ask for and use both in the same output. Maybe like:

$ trurl https://example.com --get 'used: {port} provided: {raw:port}'
used: 443 provided:

(The raw name obviously subject for improvement)

I would say that if we have port and default_port in the JSON output, it would make sense to have {port} and {default_port} as well. But raw sounds good. {scheme} can also benefit from this too, since when the scheme is not provided it defaults to http.

$ trurl example.com --get 'used: {scheme} provided: {raw:scheme}'
used: http provided: