tma 2021-12-30: Under Windows 'alited' creates a directory '.config' in the users home directory with every start. Application config files should be in APPDATA=C:\Users\<UserName>\AppData\Roaming\<AppName>.

HE 2021-12-30: Alited looks promising but directly after starting I found one or better, two issues which let me directly stop my experiments.

Opening a ticket on github is only possible for registered users so this is not a possible way for me to inform the author.

Therefore, I added a Discussion section to provide what I found.

Alited opens a server socket on 127.0.0.1:51837 by using the package comm. This is not possible to change without changing the code. Neither the used port nor that the port is opened for listening.

This is an issue in a couple of cases:

• The port is used for some reason other than alited. Alited will never show itself on the GUI. Moreover, there is no warning what went wrong and a look into the task list shows that alited is still running.
  That means it hangs forever. Or, at least for a couple of minutes before I killed these processes.
  Reason is a missing timeout when using "::comm::comm send $comm_port" to test if the task using the port is a alited instance. There is no guarantee that a listener port is answering the connection attempt. And then alited hangs.
• It is not possible to use two instances of alited in parallel. For example, I'm often working on different programs at the same time using different virtual work spaces. In such cases I want different instances.
  Reason is that the used port is not configurable. We can use more than one configuration file but, they use always the same port.
• This open port is a security thread because it allows other users on the same machine to send commands to a running alited instance. I tried:

                Two user foo and foo1.
                foo starts alited.
                foo1 starts tclsh and executes the following:

                        package require comm
                        comm::comm send 51837 exec touch ~/securityIssue.txt
                        comm::comm send 51837 exit
                        exit

This created a new text file and than closed the alited instance of foo. To make it clear, this allows everything to be executed by foo1 in context of foo what exec accepts. So you can destroy all the data foo can reach. I don't understand the need to use comm with -listener 1 for alited. The documentation does not describe a use case for it. At least I doesn't find it. To remote control an application to be tested, the listener mode of comm is not needed in alited.

To check for another running instance of the user also can be done in a different way. For example, assuming a local installation of the user with a lock file.

Perhaps one can explain the reason for using comm in listener mode?