Tag: Languages

killing a process in TCL
Suppose you had spawned a process in TCL and knew its PID and wanted to kill it? Sounds simple enough thing to do, right? This problem has plagued me for many months because some things you can assume on a normal system do not hold true on strange environments, such as build deaemons.

Seems simple enough, I started off with:
```
exec kill $pid
```
Except.. not every environment has the kill binary, and with that piece of code exec has to be a binary and not a shell builtin. The funny thing is that /bin/kill is in the procps package, which is the package having the buildd problems.

So next idea was to use command -v to check for the existence of kill and skip those tests that needed kill if not found. Good idea except, so I found out later, it also finds built-ins. That means we are back to problem #1.

There is a kill command in tcl, but it requires tclx. That seems excessive for just one little simple command. How can I run a shell out of TCL that runs the kill builtin? On the command line, something like below would do it.
```
/bin/sh -c 'kill 1234'
```
I was closer, but then hit TCL quoting hell. No matter what I (initially) did I’d either get the shell to complain or my variable to not be evaluated. In the end, I had to write it to a separate variable for the command line then apply that to the exec. Not perfect but at least it works now.

The resulting code (found in testsuite/config/unix.exp) looks like:
```
proc kill_process pid {
    set cmdline "kill $pid"
    if { [catch { exec /bin/sh -c $cmdline } msg]} {
        warning "Could not kill process: $msgn"
    }
}
```
Perhaps there is a more elegant way, I’m certainly no star TCL programmer, but of all the combinations I saw this was the only that worked.
July 1, 2014
A python utf gotcha
This one had me stumped for a while:
```
# -*- coding: utf-7 -*-
import datetime
from sqlalchemy import ForeignKey, Column
from sqlalchemy.types import Integer, Unicode, Boolean, DateTime

default_due_date = datetime.datetime.now() + datetime.timedelta(days=30)
```
Syntax error found on last line.

Hmm, bring up a python interpreter and type the last line in with the imports. Works fine.

It’s the first line that is the problem, I typoed it and made it utf-7 not utf-8. I suppose it means that it is case-insenstive. Still, it wasn’t too clear to me at least, what was going on.
June 7, 2014
When a dynamic library and program share functions

This is about making procps have a proper library but it really is a generic sort of question. Say you are making a library and a program that uses that library. Now at times you may have convience type functions; procps has them for things like escaping command names or allocation different sorts of memory. Both the library and the programs use some of these functions.

Now, there seems only two approaches to this setup. The first is to have the function stay in the library and for the program to call this function, just like all the other library functions. But this means the library has exposed for all other programs that link to it and that doesn’t really make a lot of sense.

The second method is to have the functions defined in both places, perhaps in a file that is linked with the program and the library. That seems to be duplicating the code in two different places. Namespace collision could be a problem but that easily fixed with using some unqiue prefix. I really don’t think having procfs_malloc, procfs_calloc and procfs_strdup are that useful.

I’m sure this sort of problem has been solved elsewhere. Has anyone else come across this? The functions are simple utility type functions such as malloc a block of memory, if there is a problem print to stderr.

December 20, 2011