↩️ compliment after encouragement~

[HuggieBo]

It would be nice if you can get a Compliment after an Encouragement.

Imagine you are trying to get something to work and you are struggling with it.

➜  ~ false
did mommy's girl make a big mess~
➜  ~ false
just know that mommy still loves you~

but then you manage to do the task. I think it would be very nice if you would get a compliment for that.

➜  ~ true
➜  ~

But when I disable compliments this does not happen. The Problem is, that I do not want constant compliments for busy commands like cd or ls. Could there be like a MOMMY_REWARD option, that gives you a compliment after finishing a task?

[fwdekker]

hiya! thanks for opening this issue.

do i understand correctly that you want to configure mommy to only show a compliment if you previously received an encouragement?

so, with your feature enabled, you'd get:

$ true
$ false
encouragement~
$ true
compliment~
$ true
$ true
$ false
encouragement~
$ false
encouragement~
$ true
compliment~

is that correct?

[HuggieBo]

Yes, exactly!

[fwdekker]

cool! good to know.

personally, i have mommy's compliments disabled for the reason you mentioned: it gets spammy real fast when i use cd or ls or whatever. so: your idea is great!

as for how to implement this:

just a note to myself, is that mommy cannot filter by the contents of the issues command she's responding to. see also #148.

anyway, the challenge is now whether it's technically possible to give a compliment only after an encouragement. how do you even keep that kind of state? mommy could add it to ~/.local/state, but then it'd be shared by all shells of the current user, which i think would be a strange experience. mommy also cannot set environment variables, because variables set inside a command aren't returned to the shell that invoked it.

hmmm... not sure what other options exist...

[HuggieBo]

I've thought about this and remebred that in bash $? exists. It also works for sh, zsh and fish( with $status).
$? is the Status Code of the last command. Couldn't find it in the POSIX Standard though. I believe it was introduced by the bourne shell for scripting purposes(like $0-9 and $@ )

Edit:
Good News! I was wrong. It is POSIX. Source

[HuggieBo]

While looking more around in the POSIX docs I found about $$, which is the PID of the running Programm i.e. the Shell. So you could have a per shell state file named mommy_state_$$ and keep alot of state around. This also works for tmux.

[HuggieBo]

I think I may understand the Problem more now. Mommy is not a straight up wrapper but it runs after any givven shell command, right? So $? is already used to get the status code of the just ran command. I think changing the structure of how mommy functions is a bad Idea.

The best Options I have come up with so far.

1. a state file for each PID. The Shells PID would need to be given as an extra Argument, so its a breaking change for current installs. This would be the cleanest Implementation though.
2. a state file for each user. This could lead to conflicts when having multiple shells open, but I find this neglible. Very Straight forward to implement and does not break any current installs.
3. use a different way to invoce mommy. Use it in more of a wrapper style and not a script that runs post command. In this way we could save the current $?, run the command and then compare it to the new $?. I do not how easy this would be to implement, as I dont quite grasp the source yet. Would also be kinda a bad Idea(depending on the implementation). It would be best if the pre-command run part is just saving the current $? to a new variable and then just invocing the mommy script with that extra variable.

[fwdekker]

using a file per shell pid is a good idea! i could avoid the breaking change by instead making the mommy script check /proc/$$/stat to find the parent shell's id directly, without the user having to provide it.

i'll try implementing it when i have time. my two concerns with this are as follows:

• i know linux has /proc/$$/stat, but i'm not sure about bsd systems, nor about some other misc OSes,
• writing to and reading from file will cause some additional runtime overhead. but now that i write this, probably not significantly more than mommy already incurs due to reading config files.
  i'll just try to implement it and then check the potential drawbacks later :)

[HuggieBo]

I agree with the first concern. Wouldn't it be smarter to use ps -o ppid -p $$ then? ps is defined in posix so it should work on any posix system with a posix shell. Fish would need to use $fish_pid.

[fwdekker]

good one! looked it up, and i'll do you one better: apparently the parent pid is stored in $PPID, and this is part of posix!

when i have time (which might take a while), i'll try to implement it :)