readline: persistent history + repl changes

[a8m]

As I commented in #343
I think the persistent history support should be part of the readline module.
After this changes, any cli that using readline would be able to support too.
e.g:

varrl=readline.createInterface({input: process.stdin,output: process.stdout,history: 'path/to/history'});

The "main" changes is in the readline module and it's tested too.

I also changed a bit the repl module, and add the history support by default.
Maybe it should become with flags(NODE_DISABLE_HISTORY, NODE_HISTORY_PATH) like @evanlucas suggested, but this is out of the scope of this PR.

Thanks.

[brendanashworth]

Is there a benefit to loading the current history into memory rather than just appending to the as-is history file? From what I'm seeing, it would allow a programmer to access previous history - at the expense of a breaking change to what they might have previously relied on (i.e., first command ran = first index).

[a8m]

Sorry, I didn't get your point.
I try to explain the process:
first, if there's an history support, fetch from the file, and store in-memory.
so, the previous history is available at the start.
then, on each line, store the current history in the file.

[brendanashworth]

@a8m its alright. I intended to ask: why load on startup and overwrite the entire file every time a new line is entered, rather than appending each time a new line is entered?

For a big file (lets say 10Mb), and someone enters twenty lines, that'd be ~210Mb of input / output rather than just a few bytes (~8Kb) by appending to the file using fs.appendFileSync(). This would also avoid using lots of RAM by loading the file into memory.

Edit: this would also allow for two readline's to be run at once with the same history file.

[a8m]

I agree with you @brendanashworth, it really more sense.
But, because the limit for lines-history(for some reason) it's 30 rows, it's really doesn't matter.
What we can do, it's making it configurable too(make the 30 the default), then append to a file and trim it when it exceeds a particular size.
e.g:

varrl=readline.createInterface({//...history: 'path/to/history'});rl.setHistorySize(100);

what are your thoughts?

[brendanashworth]

@a8m I like that idea, 👍 from me on that topic.

On a side note, could you clean up your commit title and description to fit the guidelines?

[a8m]

Update:
I've change a bit the previous commit.
Currently, on each line, it's appending to the history file.
Then, when the close function is fired, test if the in-memory history is greater than or equal to _hisotrySize. if so, call writeFileSync and copy the in-memory history to ensure the file is not exceeding the _hisotrySize.(Can you think about more elegant/cheap way to trim the file?).

Also, I've updated the docs and the tests too.
Cheers.

[chrisdickinson]

This change should not be made to the REPL module, it should be specific to iojs command line repl.

[a8m]

/cc @chrisdickinson

[vkurchatkin]

I don't think readline should do any io. The user can just pass history array and retrieve it later

[rvagg]

+1 to @vkurchatkin's comment above

[a8m]

@vkurchatkin writing to the terminal is also io, but I get your point.
so, if the load and the save operations will move to the user land, it will look something like that:

readline.createInterface({//...history: loadSync('history')}).on('line',// append to a file).on('close',// or save on closing)

If this is acceptable to you guys, I'll make this changes.
Thx.

[vkurchatkin]

@a8m it is, but readline doesn't write directly, you provide a stream. This way you can use it with any kind of stream. The same principle applies to history, so that user can store history in memory or database.

[piscisaureus]

What @vkurchatkin said.

[a8m]

@piscisaureus this PR was updated after @vkurchatkin comments.
Thx

[vkurchatkin]

it's not clear from the example what is the result of loadHistorySync(). It's better to use array literal

[evanlucas]

history should be passed here as well

[a8m]

Right! (I'm usually using it with option object)
changed!

[brendanashworth]

style: missing semicolon here

[brendanashworth]

Is there an update on this? It hasn't been touched in a while.

[a8m]

It's up to you guys.

[silverwind]

With 0450ce7 landed, I think this may be obsolete now.

[Fishrock123]

Yep, seems like it.