exec
Synopsis:
exec [
exec -direct <commands>
exec -name <name> <shell commands>
exec -out <process id | shell commands>
exec -msg <nickname | channel> <process id | shell commands>
exec -notice <nickname | channel> <process id | shell commands>
exec -in <process id> <text to send to process>
exec -window <process id | shell commands>
exec -
exec -close <process id>
Description:
exec allows
you to spawn other processes from within your client, which are naturally treated
as child processes. For example, if you wished to check your email without suspending
your client (or quitting TekNap), you could simply exec your favorite
mail program.
Processes can be given unique names, allowing them to be referred to more intuitively
than trying to figure out its process id number. Processes can also accept any
signal normally available through use of the Unix "kill" command (letting you
kill, suspend, etc. any process that accepts such a signal). Process identifiers
begin with a "%". Thus, a process named "mail" with pid 0 could be referred
to as either "%mail" or "%0".
exec can take several different flags, each of which allow you to manipulate
the subprocess in different ways. At the most basic level, the only argument
you really need to give is the external program to run. If no arguments are
given at all, a list of any currently running processes is returned.
When using the -out, -msg, or -notice flags, output can
be sent to the target upon startup of the subprocess, or redirected to it after
it's already running by using its process id.
Another flag of note, -close, can be used to shut down renegade subprocesses
that simply won't go away (i.e. with their own quit command, with the kill
signal, etc.). This actually just severs the link between the subprocess
and the client, so it will die on its own the next time it tries to send data
to the client.
Something to remember when worried about a shell processing arguments is the
-direct flag, which executes the commands without spawning a shell. This
can cut down on security risks, and save some memory.
Options:
-direct executes commands without spawning a shell
-name give the subprocess a logical name
-out send subprocess output to your current channel
-msg send subprocess output to a nick or channel with msg
-notice send subprocess output to a nick or channel with notice
-in send a text string to the specified subprocess
-window redirect subprocess output to another window
-
-close forcibly kill the subprocess and its children
Examples (assume that the
process used with these examples is the Unix mail program):
To start a process:
/exec mail
To start a process without
a shell interfering:
/exec -direct mail
To start a process and give
it a human-readable name:
/exec -name mail mail
To send the output of a
new subprocess to your current channel:
/exec -out mail
To send the output of a
running subprocess to JoeBob with a msg:
/exec -msg joebob %mail
To send the output of a
new subprocess to #blah with a notice:
/exec -notice #blah mail
To send a text string (command)
to a running subprocess:
/exec -in %mail ?
To send a running subprocess
the kill signal:
/exec -kill %mail
To forcibly close down a
stubborn subprocess that just won't die:
/exec -close %mail
Aliases:
When using exec with the -in flag, the functionality is identical
to using msg to send a message to a process. See msg for more
information.
See Also:
msg
set exec_protection
set notify_on_termination
set security
set shell
set shell_flags
set shell_limit
Restrictions:
Use of external programs from within TekNap can sometimes be dangerous if you
don't know what you're doing. The danger doesn't necessarily lie in the external
programs themselves, but rather in any lack of knowledge about them you may
have. When all else fails, don't use a command if you don't know what it does.
You can explicitly limit your ability to use exec in several ways.
Other Notes:
The available signals that may be sent to a process will vary from system to
system.