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 printnone
ornull
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: