fullstorydev / grpcurl

Like cURL, but for gRPC: Command-line tool for interacting with gRPC servers
MIT License
10.36k stars 497 forks source link

Positional Arguments - Address and Symbol #377

Closed ritwik12 closed 1 year ago

ritwik12 commented 1 year ago

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:

grpcurl -d '{"message": "Hello"}'  test eg://Grpc com.a.b/methodName
 Namespace(d='{"message": "Hello"}', header=None, rpc_header=None, plaintext=False, cert=None, key=None, cacert=None, address='test', symbol='eg//Grpc') 

here, it should have taken eg://Grpc in address and com.a.b/methodName in symbol but it is taking test in address instead.

Is there some preprocessing for symbol or address in the command?

jhump commented 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.)

ritwik12 commented 1 year ago

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)

jhump commented 1 year ago

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.

ritwik12 commented 1 year ago

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

jhump commented 1 year ago

@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.

ritwik12 commented 1 year ago

@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.

ritwik12 commented 1 year ago

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.

jhump commented 1 year ago

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.

ritwik12 commented 1 year ago

@jhump Thanks for all your answers. this clears my doubts.