Closed ritwik12 closed 1 year ago
What is the test
argument in your example supposed to be?
FWIW, it's not that it takes the last two arguments. It's that positional arguments must appear last, after all options/flags. And that it usually expects exactly two positional arguments: the target host:port and then the action: "list", "describe", or the name of a method to invoke. A third positional argument is allowed with "list" (a service name) and required with "describe" (the name of the symbol to describe).
So in your example, the first positional argument is "test" and the second is "eg://Grpc". (This should result in a usage error since the second argument is not "list" or "describe" nor is it a valid method name.)
I see, how are we processing a valid service name? we are going some pre processing in the service name such as it should not have any characters other than alphabets etc?
My test argument is going to be a URL which we will later convert to a hostname:port service name is going to be a valid service name. like serviceName/Method.
I'm facing issues when my address is not in the form of hostname:port and there is another argument in the command (could be unrecognised argument)
A valid service name is a fully-qualified method name in protobuf -- which means dot-separate identifiers, where an identifier can begin with a letter or underscore and contain thereafter letters, numbers, and underscores. You can optionally provide the URI path of the service, which allows for a slash (/
) between a fully-qualified service name and the method name. So the following are examples of valid RPC method names:
package.of.file.Service.Method
package.of.file.Service/Method
Colons are not allowed.
Thanks @jhump I get it for service name and using the same.
My issue is with address which is picking up any unrecognised argument and putting it into address argument even when there is a a://serviceName mentioned before package.of.file.Service/Method
Example:
grpcurl foo bar://serviceName package.of.file.Service/Method
Instead of picking up bar://serviceName in address argument. it picks up foo
@ritwik12, I still don't understand what you're trying to do. Why is there an extra "foo" argument in that example? You are using the CLI incorrectly: it only accepts two positional arguments, the target host and the method, but you are passing three.
@jhump Let me give you context.
I am working on a wrapper over grpcurl at my current organisation for some internal specific things. For that we want to parse address in the form of bar://serviceName so that we can extract the service name. from it and add the address in the form of hostname:port as per the request from the user based on several other stuff.
We are also having several other arguments and some unrecognized arguments as well, we are saving user effort and automating a lot of things in the backend, so wanted to know the possibility because I am facing issues when there is an extra argument which I have not defined in my grpcurl wrapper and is not grpcurl argument as well. in that case grpuril gets confused for the address and symbol and sometimes it takes FOO in address and takes actual address and symbol in symbol only as a list.
It is totally fine if it is not possible, we will make sure in some other way then.
So my doubt here is, why does grpcurl takes two of my argument in Symbol as a list and takes some other one in Address? I think there is some preprocessing in code to judge from the arguments for address and symbol.
some preprocessing in code to judge from the arguments for address and symbol.
I already described it. The arguments are positional. The first argument is the address. The second argument is either a method name or the words "list" or "describe". If the second argument is "list" or "describe", a third argument is allowed, which is a symbol (the service whose methods are listed or the element that will be described).
Passing extra arguments to grpcurl
, before or after the expected positional arguments, will not work.
However, you could always fork the main
package of grpcurl
. While it is a bit long, to handle all of the possible command-line flags, the real meat of the logic is in a Go package ("github.com/fullstorydev/grpcurl"
). So you could write your own frontend/command-line interface by writing your own main
package that uses that same package to do the hard part of the processing.
@jhump Thanks for all your answers. this clears my doubts.
I have noticed that address and symbol should be present at last two places respectively in the command. but I have also noticed that whenever there is another address or symbol kind of value in the command, it tries to pick that instead of the last two values
Eg:
here, it should have taken
eg://Grpc
in address andcom.a.b/methodName
in symbol but it is takingtest
in address instead.Is there some preprocessing for symbol or address in the command?