Add kgx term

[Botspot]

[pi-dev500]

Wouldn't you prefer to trick the .bashrc to allow compatibility to all terminals ?

[Botspot]

Wouldn't you prefer to trick the .bashrc to allow compatibility to all terminals ?

Please be more specific about what your idea is and what advantages it has.

[pi-dev500]

You could back up the .bashrc, then add add some lines at it's end with something that put back in place the original bashrc before executing the command, and, at end, after the command, an exit. This should permit to have a modified bashrc that have a duration of ~1sec and that doesn't impact the system.

[Botspot]

You could back up the .bashrc, then add add some lines at it's end with something that put back in place the original bashrc before executing the command, and, at end, after the command, an exit. This should permit to have a modified bashrc that have a duration of ~1sec and that doesn't impact the system.

The terminal-run script is used by pi-apps to run anything in a terminal, including install, uninstall, updates, and a few other things. The .bashrc script is run by all shells on startup. How would modifying that file do anything useful? I can only think of bad ways that could go wrong.

[pi-dev500]

As .bashrc is executed on startup of shell, we should just have to add the 3 lines of code at end of .bashrc, then start the terminal that will revert the changes made on .bashrc, run the command, and exit instead of running habitual prompt. The fact that changes made to .bashrc are reverted on first terminal start that occurs after the modification of the file just make that the next terminal start will not be affected. Sorry if you don't understand me properly, I'm not native speaker...

[Botspot]

As .bashrc is executed on startup of shell, we should just have to add the 3 lines of code at end of .bashrc, then start the terminal that will revert the changes made on .bashrc, run the command, and exit instead of running habitual prompt. The fact that changes made to .bashrc are reverted on first terminal start that occurs after the modification of the file just make that the next terminal start will not be affected. Sorry if you don't understand me properly, I'm not native speaker...

I think I understand this now. It seems like a bad idea.

1. The command passted to terminal-run can be any number of lines long, sometimes over 100 lines long. There is no assumption that it is 3 lines long.
2. We have to deal with edge cases. What if the .bashrc file is nonexistent, or read-only?
3. What if two instances of terminal-run try to edit .bashrc at the same time? How would each running terminal know which lines to remove?
4. As .bashrc is intended for the user to edit, how can we be certain that bash even reaches the end of the file to run our commands? Maybe the user put exit 0 earlier up in the script, just like as seen in /etc/rc.local.
5. What if the user's .bashrc was edited by the user to now contain a syntax error? In some cases, bash will completely refuse to run a script even if the first few lines are valid.
6. What if the file is left behind with pi-apps commands in it, due to a power failure during the few seconds it takes for the terminal to open, or what if the terminal never opens to clear the lines from .bashrc?
7. We would have to be really careful to not remove user-added code from .bashrc. It could be hard to tell the difference.
8. We would have to be really careful to make sure all pi-apps-added lines are always removed and not treated as user-added code. There is no room for mistakes. Any failure on this would leave pi-apps code running on every terminal launch/

We cannot think in terms of "what would work good enough for me and my system?" I would estimate that the Pi-Apps terminal-run script has probably been run 100 million times. (give or take a power of 10) So for 100 million times, it has to always work perfectly, or fail in a safe way, with a useful error. And I think that editing .bashrc is too unsafe for certain edge cases.

[theofficialgman]

Just dropping the upstream bug link here so its easier to find https://gitlab.gnome.org/GNOME/console/-/issues/135

Until that is resolved in some manner by upstream this is a NACK from me.