replace search.from and search.to with search.range?

[radare]

pro/con? discuss

[Maijin]

Like what e cmd.range=0x0,0xffff ?

I don't care much personally - All I know is that, this will just break tests and existing scripts and for update the update you will need to retype the whole range.

[radare]

Its just a matter of practicity. Setting one var is sometimes faster than two, but its sometimes anoying if you wanna query one value or another. The range strings support multiple expressions to be evaluated like this

Range=0-100,400-1000

On 27 Mar 2017, at 13:36, Maijin notifications@github.com wrote:

Like what e cmd.range=0x0,0xffff ?

I don't care this will just break tests and existing scripts and for update the update you will need to retype the whole range.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Maijin]

k

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of radare2. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.

[karliss]

For the ease of use instead of replacing it could be made an alias using getter/setter callbacks. So that modifying search.range updates search.from and search.to.

[trufae]

search.range=1-100,300-500 cannot update from/to because it have more than 2 values. so it must be something like search.in=range and then use search.range instead of from/to.

everyone is used to the from-to workflow now. but i do understand the benefits of having such expressions to define multiple range searchs. Anyone else willing to comment here?

[ret2libc]

IMHO we don't need it and this can be closed. I agree everyone is used to *.from/*.to and I personally don't feel the need for this.

[trufae]

I think its useful, but i think it should be implemented in @@, so my proposal here is.. instead of making more confusing eval variables. We can do something like / foo @@[100-200,300-6000] which will basically update search.in/from/to for each range defined with parenthesis, brackets, dashes and commas. there's something similar in @@s:

[ret2libc]

There is also | @{from to} temporary set from and to for commands supporting ranges, but that allows you to set just one range.

[trufae]

Yeah i would prefer to extend @{} to support multiple ranges instead of adding another modifier. Shouldn't be hard to implement

[ret2libc]

There is just a semantic problem, which is that in general @? are used for a single temporary change. We usually use @@? for a kind of foreach statements, so it may be a bit confusing having @{..} support multiple ranges (I'm thinking about something like ... @{from1 to1}{from2 to2})

[trufae]

Yes, this seems like a reasonable syntax to me, but i like the comma-dash syntax to define ranges of things, but this is also fine. what do u think about chaining multiple @{}@{}@{} like this?

[ret2libc]

I think @{}@{}@{} is not that good, because it is ambiguous. Usually @ starts a new "temporary change command" (the @?).

[trufae]

Agree, so i'm fine with your proposal. i can do it for the current command parser, but im not fluent enough with treesitter to go for the newshell, do you want to implement it?

[ret2libc]

I can extend your PR with the tree-sitter changes.

[ret2libc]

Though I don't consider this high priority as it is just syntax sugar.

[trufae]

Yeah not a priority/rush, i also have a long list of things to take care before caring about this issue, but yeah, i appreciate if you could extend my pr when i get it there