| 1 | | I guess indeed that the current code don't handle fine the fork/exec case: |
| 2 | | - Two Terminals teams is due to the fork |
| 3 | | - after the exec, the Terminal team is still there, but now running the shell: it's not detect by the code, as the team ID was already seen at previous update cycle. |
| 4 | | - The Terminal icon appearing as a generic app icon must be due that while the code don't detect that the team is not anymore running the same executable, the icon is retrieved *after* the team's command line has change, leading to... /bin/bash generic app icon. |
| | 1 | I guess indeed that the current code don't handle fine the fork/exec case. So, depending on when the update code run; you can have: |
| | 2 | |
| | 3 | - Two Terminals teams is due to the fork: the exec are not yet done for the child team... |
| | 4 | - after an exec done by a team already detected in previous cycle, the team name and/or icon is not updated according to the new running image |
| | 5 | - depending on when the icon is retrieved, it could be the one from before or after the exec. As this retrieval is done in a lazy way (at drawing time), it would explain why the end icon is not always either wrong or right. In the Terminal icon case, it's either the (just) forked Terminal icon or the (new) /bin/bash (generic app icon) which was exec'ed in its place. |
