Command to show current pokemon

[axiomabsolute]

I'm less familiar with the Pokemon in the more recent regions, and don't always recognize them right away from the image. Is there an easy way to tell which Pokemon is currently being featured?

[LazoCoder]

There used to be a function pokemon ? that attempted to do this but it was hacky and unreliable so I had to remove it.

What if the name of the Pokemon is printed to the terminal each time the pokemon random function is called? Like this:

$ pokemon random
Terminal theme changed to Pikachu.
$ pokemon random
Terminal theme changed to Ivysaur.

Do you think that would be a good solution?

[axiomabsolute]

Yeah, I think that would help

[kylebegovich]

I believe I've accomplished what you're discussing. I'll try to make a version of the $ pokemon ? command as well in a separate PR

[ghost]

Hey guys,
Great project! What's the status of this issue ?

[giftig]

It struck me the other day, this shouldn't actually be a difficult issue; you can do this without binding it to one terminal or another simply by setting the current pokemon as an env var in your current terminal window when you set it.

Also, being able to reliably determine the current pokemon in your window could pave the way for other cool features, like "pokemon evolve" -> swap to evolved form of current pokemon.

[samuelhnrq]

I mean I was struggling with this issue too, you cant set an environment variable from a child process, e.g. python interpreter. What I ended up doing was implementing a FIFO pipe to communicate. But I just realized, that is single process only.

I had a huge epiphany when writing this, /tmp is cleared on boot, so we can save a 'current sessions' (maybe JSON?) database there! Summing that up with the fact that PID's are seldom re-utilized (and we can save process name just to be sure), I think it's a trustworthy system enough, what do you guys think?

[sylveon]

What about using PID and starttime in Unix Epoch? This would make the temporary file easier to parse and write to, as well as being simple plaintext since we don't have to escape possibly user-generated strings (the process name) and a better guarantee on the process being the same than the one we saved in /tmp:

20191 1507678429 700

where the format is <PID> <TIMESTAMP> <POKEMON ID>

[samuelhnrq]

Another epiphany, we don't need to keep a global database file, there is no point, pokemon processes don't care about each other, so we can simply keep a pid-named file on tmp, e.g. /tmp/pkmn_session3398 and simply lookup the existence of such file to check the current pokemon, (and also we can't forget to clear it when we clear the pokemon explicitly, and to make the slideshow update it) and I really think there is no harm leaving a ~20kb tops, file on the hard drive that will be wiped on next reboot. And even on absurd worst case scenario that the user closes the current bash with a set pokemon, and opens a different bash session on the same pid, we still are simply overwriting the file, max he can do is evolve from nothing, or get the current pokemon also from nothing.

And we don't need to care about if the PID is going to be re-utilized later because the only PID we will be checking is the current bash session's PID (environment variable $$), no checking needed. And of course we can use this approach to solve other problems, like evolving, and like, time with this pokemon, etc. I think this is the best solution so far, anyone else wants to implement this? A flaw in my thinking I didn't see?

[sylveon]

Looks good to me, however I would also separate by user, like this: /tmp/pkmn_$USERNAME_session3398, because we will likely have issues reading the file if another bash session spawns with the same PID of an older bash session from a different user, because of file permissions. (That's extremely rare, but something to consider)

[jimmyorourke]

Just submitted #148 which I think is a nice solution for this

[wangyingbo]

guys, any progress?