2012-03-01 20:04:28 -05:00
|
|
|
class Pry
|
2012-12-25 16:35:17 -05:00
|
|
|
class Command::Hist < Pry::ClassCommand
|
|
|
|
match 'hist'
|
|
|
|
group 'Editing'
|
|
|
|
description 'Show and replay Readline history. Aliases: history'
|
2012-08-11 20:22:29 -04:00
|
|
|
|
|
|
|
banner <<-USAGE
|
|
|
|
Usage: hist
|
|
|
|
hist --head N
|
|
|
|
hist --tail N
|
|
|
|
hist --show START..END
|
|
|
|
hist --grep PATTERN
|
|
|
|
hist --clear
|
|
|
|
hist --replay START..END
|
|
|
|
hist --save [START..END] FILE
|
|
|
|
USAGE
|
|
|
|
|
|
|
|
def options(opt)
|
|
|
|
opt.on :H, :head, "Display the first N items.", :optional_argument => true, :as => Integer
|
|
|
|
opt.on :T, :tail, "Display the last N items.", :optional_argument => true, :as => Integer
|
|
|
|
opt.on :s, :show, "Show the given range of lines.", :optional_argument => true, :as => Range
|
|
|
|
opt.on :G, :grep, "Show lines matching the given pattern.", :argument => true, :as => String
|
|
|
|
opt.on :c, :clear, "Clear the current session's history."
|
|
|
|
opt.on :r, :replay, "Replay a line or range of lines.", :argument => true, :as => Range
|
|
|
|
opt.on :save, "Save history to a file.", :argument => true, :as => Range
|
|
|
|
|
|
|
|
opt.on :e, :'exclude-pry', "Exclude Pry commands from the history."
|
|
|
|
opt.on :n, :'no-numbers', "Omit line numbers."
|
|
|
|
opt.on :f, :flood, "Do not use a pager to view text longer than one screen."
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
def process
|
2012-12-09 16:37:36 -05:00
|
|
|
# The last value in history will be the 'hist' command itself
|
|
|
|
@history = Pry::Code(Pry.history.to_a[0..-2])
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
if opts.present?(:show)
|
|
|
|
@history = @history.between(opts[:show])
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
if opts.present?(:grep)
|
|
|
|
@history = @history.grep(opts[:grep])
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
@history = case
|
|
|
|
when opts.present?(:head)
|
|
|
|
@history.take_lines(1, opts[:head] || 10)
|
|
|
|
when opts.present?(:tail)
|
|
|
|
@history.take_lines(-(opts[:tail] || 10), opts[:tail] || 10)
|
|
|
|
when opts.present?(:show)
|
|
|
|
@history.between(opts[:show])
|
|
|
|
else
|
|
|
|
@history
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
if opts.present?(:'exclude-pry')
|
|
|
|
@history = @history.select { |l, ln| !command_set.valid_command?(l) }
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
if opts.present?(:save)
|
|
|
|
process_save
|
|
|
|
elsif opts.present?(:clear)
|
|
|
|
process_clear
|
|
|
|
elsif opts.present?(:replay)
|
|
|
|
process_replay
|
|
|
|
else
|
|
|
|
process_display
|
|
|
|
end
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
private
|
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
def process_display
|
|
|
|
unless opts.present?(:'no-numbers')
|
|
|
|
@history = @history.with_line_numbers
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
render_output(@history, opts)
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
def process_save
|
|
|
|
case opts[:save]
|
|
|
|
when Range
|
|
|
|
@history = @history.between(opts[:save])
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
unless args.first
|
|
|
|
raise CommandError, "Must provide a file name."
|
2012-03-01 20:04:28 -05:00
|
|
|
end
|
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
file_name = File.expand_path(args.first)
|
|
|
|
when String
|
|
|
|
file_name = File.expand_path(opts[:save])
|
2012-03-01 20:04:28 -05:00
|
|
|
end
|
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
output.puts "Saving history in #{file_name}..."
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
File.open(file_name, 'w') { |f| f.write(@history.raw) }
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
output.puts "History saved."
|
|
|
|
end
|
|
|
|
|
|
|
|
def process_clear
|
|
|
|
Pry.history.clear
|
|
|
|
output.puts "History cleared."
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-08-11 20:22:29 -04:00
|
|
|
def process_replay
|
|
|
|
@history = @history.between(opts[:r])
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
replay_sequence = @history.raw
|
|
|
|
|
2012-11-21 08:22:39 -05:00
|
|
|
# If we met follow-up "hist" call, check for the "--replay" option
|
|
|
|
# presence. If "hist" command is called with other options, proceed
|
|
|
|
# further.
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
check_for_juxtaposed_replay(replay_sequence)
|
2012-03-01 20:04:28 -05:00
|
|
|
|
2012-12-28 09:44:04 -05:00
|
|
|
replay_sequence.lines.each do |line|
|
|
|
|
_pry_.eval line
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
end
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
|
2012-11-21 08:22:39 -05:00
|
|
|
# Checks +replay_sequence+ for the presence of neighboring replay calls.
|
|
|
|
# @example
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
# [1] pry(main)> hist --show 46894
|
|
|
|
# 46894: hist --replay 46675..46677
|
|
|
|
# [2] pry(main)> hist --show 46675..46677
|
|
|
|
# 46675: 1+1
|
|
|
|
# 46676: a = 100
|
|
|
|
# 46677: hist --tail
|
|
|
|
# [3] pry(main)> hist --replay 46894
|
|
|
|
# Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
|
|
|
|
# [4] pry(main)>
|
|
|
|
#
|
|
|
|
# @raise [Pry::CommandError] If +replay_sequence+ contains another
|
|
|
|
# "hist --replay" call
|
|
|
|
# @param [String] replay_sequence The sequence of commands to be replayed
|
|
|
|
# (per saltum)
|
|
|
|
# @return [Boolean] `false` if +replay_sequence+ does not contain another
|
|
|
|
# "hist --replay" call
|
|
|
|
def check_for_juxtaposed_replay(replay_sequence)
|
|
|
|
if replay_sequence =~ /\Ahist(?:ory)?\b/
|
2012-11-23 07:18:46 -05:00
|
|
|
# Create *fresh* instance of Options for parsing of "hist" command.
|
2012-11-21 08:22:39 -05:00
|
|
|
_slop = ClassCommand::Options.new(self.slop)
|
|
|
|
_slop.parse replay_sequence.split(' ')[1..-1]
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
|
|
|
|
if _slop.present?(:r)
|
2012-11-21 08:22:39 -05:00
|
|
|
replay_sequence = replay_sequence.split("\n").join('; ')
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
index = opts[:r]
|
2012-12-27 21:03:09 -05:00
|
|
|
index = index.min if index.min == index.max || index.max.nil?
|
Store `hist --replay <i>` calls in history
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
2012-08-22 19:27:02 -04:00
|
|
|
|
|
|
|
raise CommandError, "Replay index #{ index } points out to another replay call: `#{ replay_sequence }`"
|
|
|
|
end
|
|
|
|
else
|
|
|
|
false
|
|
|
|
end
|
|
|
|
end
|
2012-03-01 20:04:28 -05:00
|
|
|
end
|
2012-08-11 20:22:29 -04:00
|
|
|
|
2012-12-25 16:35:17 -05:00
|
|
|
Pry::Commands.add_command(Pry::Command::Hist)
|
|
|
|
Pry::Commands.alias_command 'history', 'hist'
|
2012-03-01 20:04:28 -05:00
|
|
|
end
|