Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI history skips blank lines. #4768

Merged
merged 5 commits into from
Nov 14, 2015
Merged

CLI history skips blank lines. #4768

merged 5 commits into from
Nov 14, 2015

Conversation

pires
Copy link
Contributor

@pires pires commented Nov 12, 2015

  • CHANGELOG.md updated
  • Rebased/mergable
  • Tests pass
  • Sign CLA (if not already signed)

Also:

  • Refactored command parsing tokenization.
  • Fixed cmd/influx lint.
  • Improve coverage for cmd/influx

Fixes #4719

// write out the history
if len(historyFile) > 0 {
select {
case <-c.Quit:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean I will only get history written if I type exit at the CLI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This structure doesn't really gain anything over a simple for loop since there are no goroutines running here. The agreement that ParseCommand offers is that it returns true if parsing should continue, false otherwise.

@otoolep
Copy link
Contributor

otoolep commented Nov 12, 2015

OK, I see that you state that history is only written if I enter exit. Why did you make this change? Why shouldn't I get history I send control-D or control-C?

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@otoolep you are right and I've just reverted to previous behavior. I've updated the commit message and PR description. Anything else?

@otoolep
Copy link
Contributor

otoolep commented Nov 12, 2015

I don't really see the point of the Quit channel. Am I missing something?

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@otoolep the return false in ParseCommand when exit is executed seems ambiguous. After all, exit is a valid command and should be part of history as well. If later we want to integrate the parser in order to validate queries, with this change we will be able to use return false there to redeem said instructions invalid.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

Also, one will be able to gracefully terminate the CLI from anywhere in the CLI code.

@otoolep
Copy link
Contributor

otoolep commented Nov 12, 2015

OK, that is a valid point about exit being part of the history.

The bigger issue here is that the CLI structure is not super. ParseCommand should really be returning tokens, and the code should switch on those tokens. But that would be a much bigger change. In other words, parsing should be distinct from what happens when a particular token is detected.

I'm not sure if you up for some more refactoring, but this code definitely needs it. Parsing and execution are coupled too tightly together.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@otoolep my idea is to iteratively refactor the code. Big changes tend to be harder to review and merge. I do agree parsing should be split from execution. I have said before I want to integrate the parser in order to validate queries before executing them against a server, etc. But for this to happen, I'll need more time with the code and debate online with you guys.

@otoolep
Copy link
Contributor

otoolep commented Nov 12, 2015

Sure -- I am happy to support you @pires.

To that end, do you think the addition of Quit gets you any closer to that? The blank-line fix is definitely needed. I am OK with merging as is, with an eye to future improvements, assuming we can get a second +1.

@otoolep
Copy link
Contributor

otoolep commented Nov 12, 2015

@corylanou @gunnaraasen

}
}

Loop:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would love to see this go away in a future iteration. In general I don't like to use goto if we can avoid it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually found about labels in Go by looking at other pieces of the InfluxDB code. And while I never liked labels either, at this time it's a compromise I can live for the time being.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

Thank you @otoolep.

If there's a better alternative to explicitly trigger program termination from anywhere in this code other than ParseCommand == false, please do let me know.

@corylanou
Copy link
Contributor

@pires we really need the cli to support a signal exit like we do in influxd:

https://github.com/pires/influxdb/blob/4719-cli_history_refactor/cmd/influxd/main.go#L90

Right now if we do a force quit it will leave your terminal in a messed up state as it doesn't cleanly shut down the liner package.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@corylanou I agree I can improve the shutdown code and will do it in this PR. Will add support to OS signals as well.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@corylanou done. Anything else?

fmt.Printf("There was an error writing history file: %s\n", err)
}
// exit CLI
os.Exit(0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we really need a "close" function here. Then we can do something like:

if c.Line != nil {
    c.Line.Close()
    c.Line = nil
}

And any other cleanup we need.

If we do an os.Exit without closing the liner down that is what will leave your terminal in a bad state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

@pires
Copy link
Contributor Author

pires commented Nov 12, 2015

@corylanou anything else?

@corylanou
Copy link
Contributor

Very nice. Thanks for all your hard work on this. It's very much appreciated. +1

@pires
Copy link
Contributor Author

pires commented Nov 13, 2015

@corylanou @otoolep thank you for your guidance and patience.

@pires
Copy link
Contributor Author

pires commented Nov 14, 2015

Is anything missing for this to be merged?

@corylanou
Copy link
Contributor

@otoolep want to take one more look now that it's done?

if e != nil {
break
}
// write valid commands only to in-memory history
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment accurate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nop. Thanks!

@otoolep
Copy link
Contributor

otoolep commented Nov 14, 2015

All looks good to me, one question about a comment.

+1 from me, @corylanou -- please merge when ready.

Thanks for all the hard work @pires

@pires
Copy link
Contributor Author

pires commented Nov 14, 2015

@otoolep @corylanou nit fixed. Thank you all, once more.

corylanou added a commit that referenced this pull request Nov 14, 2015
@corylanou corylanou merged commit bb00645 into influxdata:master Nov 14, 2015
@pires pires deleted the 4719-cli_history_refactor branch November 15, 2015 23:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants