difference in sequence of command line options results in different behaviour #10

New Issue

asdf · 2019-11-24T00:13:56Z

asdf commented

2019-11-24 00:13:56 +00:00

The command gfu -d -i gophermap will:

read file gophermap
deconstruct gopher menu formatted lines
make changes in-place, saving them back to file gophermap

The same command written as gfu gophermap -d -i tries to read from stdin.

The command `gfu -d -i gophermap` will: - read file `gophermap` - deconstruct gopher menu formatted lines - make changes in-place, saving them back to file `gophermap` The same command written as `gfu gophermap -d -i` tries to read from stdin.

asdf self-assigned this 2019-11-24 00:13:56 +00:00

sloum commented

2019-11-24 05:04:55 +00:00

Golang's flag package does not allow positional arguments to come before flags. By that I mean, it allows it, but it breaks. :(

asdf commented

2019-11-24 10:49:56 +00:00

Well, thanks for the tip. It would have taken me a while to figure that out!

It is not great that the flag package implements this in an unusual way. I can document it to make it clearer.

The cobra library keeps coming up when looking in to things like this. Looks interesting.

Well, thanks for the tip. It would have taken me a while to figure that out! It is not great that the flag package implements this in an unusual way. I can document it to make it clearer. The [cobra](https://github.com/spf13/cobra) library keeps coming up when looking in to things like this. Looks interesting.

asdf commented

2019-11-24 10:54:25 +00:00

Documentation updated. An alternative is to avoid arguments, and use a flag to specify an input file. For example:

gfu -d --input-file=gophermap --output-file=plaintext

Let me know if this is preferred.

Documentation updated. An alternative is to avoid arguments, and use a flag to specify an input file. For example: gfu -d --input-file=gophermap --output-file=plaintext Let me know if this is preferred.

asdf closed this issue

2019-11-24 10:54:25 +00:00

sloum commented

2019-11-24 16:04:41 +00:00

I like the idea of positional arguments to handle it, but I agree that it is less flexible than the ideal. What do you think? I could go either way. Using flags gives the added benefit of clarity I suppose.

asdf commented

2019-11-25 00:37:30 +00:00

I'm also split on this, but maybe moreso about fixing it within the boundaries of the standard libraries, or fixing it nicely by using Cobra.

Adding an external, non-standard dependency for something as simple as this doesn't seem very correct, but (for me at least) this has been a great place to experiment and learn by trying new things.

Something to consider as time permits.

I'm also split on this, but maybe moreso about fixing it within the boundaries of the standard libraries, or fixing it nicely by using Cobra. Adding an external, non-standard dependency for something as simple as this doesn't seem very correct, but (for me at least) this has been a great place to experiment and learn by trying new things. Something to consider as time permits.

sloum commented

2019-11-25 01:01:35 +00:00

I agree re: added dependencies. It seems like it should be workable without an outside dependency. For my Python programs I generally just write an argument parser myself and take everything in from the command line as a list. This could be done here as well. That would eliminate the outside library, provide a learning opportunity in Go, and solve the problem (in theory). Maybe a route to go eventually. For now the documentation update seems solid.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/gfu#10