Re-use probes support

[jimaek]

The API can support running tests from the same probes as some previous measurement by providing the ID. https://github.com/jsdelivr/globalping/pull/453

Need to figure out the best way to implement it in the CLI.

Here is my idea:

1. Document the feature in README and CLI docs
2. Add --reuse parameter. The CLI will store in some env var the ID of the last measurement and with that parameter will automatically get and reuse the last ID. If there is no ID stored it will just run a fresh measurement. see below

@MartinKolarik thoughts?

[MartinKolarik]

First, the simple part: document that the ID can be passed to the --from parameter. That's something you can do even if you got the ID from some other source: ping google.com --from zFUra8K0lGO3vqBn

The history idea seems cool, but might need to allow more than just one ID to be useful. I suggest keeping the --from parameter for this but using bash-like numbered entries:

--from !1 # reuses first ID from the session
--from !2 # reuses second ID from the session
--from !! # reuses the most recent ID from the session

This way, people will most likely do !1, but then, when they need to add in a second set, it naturally works with !2. Note that the history should be stored per session only, and only commands where the location is explicitly set should create new entries - if I run !! five times, there should still be just one history entry.

[jimaek]

Your version sounds good for advanced users but I think we need a simple version of it for people unfamiliar with bash variables.

How about we combine both ideas?

[MartinKolarik]

I wouldn't mind having an extra way for the --from !! case, but trying to think of a better name. --reuse doesn't seem as clear and fluent as our other options. Would --from previous be simple enough?

[jimaek]

Ok sure, lets add also from previous and from last

[MartinKolarik]

So numbered references as I described + previous/last and no --reuse ?

[jimaek]

Yep sounds good to me

[didil]

@jimaek @MartinKolarik 1/ I'm not sure I understand what is meant by "the session" here ? I don't think the CLI saves any state or history at the moment 2/ I don't think the syntax --from !1 will work, that syntax is already autoexpanded by bash. If I try to run globalping ping google.com --from !1 and the command corresponding to number "1" in my history is ls /tmp, the resulting command will be globalping ping google.com --from ls /tmp

[jimaek]

1. Correct, part of the task would be to save the measurement IDs of tests in an env var to allow the CLI on the next run to re-use it if needed
2. @MartinKolarik what do you suggest? We can just keep the last/previous syntax

[didil]

@jimaek I don't think the Go program can set an env variable that will be accessible by future runs of the CLI. I think we would need to create a file on disk and save the data there.

[jimaek]

Why not? e.g. https://gobyexample.com/environment-variables

We also plan to use something similar to set a future API key.

[didil]

@jimaek Environment variables set from inside a process are only available inside that process execution, they are not available for other processes or for future processes of the same program

[MartinKolarik]

@jimaek I don't think the Go program can set an env variable that will be accessible by future runs of the CLI. I think we would need to create a file on disk and save the data there.

Yes, a file in %tmp%. I think using the parent PID + start time for the filename should work well to identify a terminal session, but you might find some other approaches too.

I don't think the syntax --from !1 will work, that syntax is already autoexpanded by bash. If I try to run globalping ping google.com --from !1 and the command corresponding to number "1" in my history is ls /tmp, the resulting command will be globalping ping google.com --from ls /tmp

Indeed, we could also go without a prefix character or choose a different one, will comment more later.

[MartinKolarik]

Indeed, we could also go without a prefix character or choose a different one, will comment more later.

Let's allow:

• @1, @2, etc to mean "first", "second", etc in the current session
• ~1, ~2, ... to mean "last", "second-to-last"
• previous/last as an alias to ~1

[radulucut]

Hi @MartinKolarik ~ gets expanded by bash, maybe we can go with @-1 @-2 for last, second to last etc?

[MartinKolarik]

~ gets expanded by bash,

Indeed but ~1 etc only gets expanded if you use pushd in the current session; otherwise, it doesn't expand, so it might be fine? And of course, you can still quote it if needed. @jimaek wdyt?

[MartinKolarik]

It's true the +/- approach is often used in CLIs as well so I'm not strongly against, just ~1 would generally be easier to type.

[jimaek]

I vote for -1, it's safe and makes logical sense for users

[jimaek]

But without @. Just -1, -2... or previous/last

[MartinKolarik]

But without @. Just -1, -2... or previous/last

No, that makes no sense, as primarily we have @1, see https://github.com/jsdelivr/globalping-cli/issues/79#issuecomment-1858113646. For negative numbers, it's either @-1 or ~1 with the caveat it doesn't play nicely with pushd. Also, note that the positive variant is more important, I expect people to primarily use @1