stripping white space

Stripping away whitspace from call parameters is a regular command line behavior. If white space should be kept, arguments have to be single or double quoted.

# comment character

If you are using a channel name as a parameter to ot-snippet-param, it will contain a leading # character. The # character marks the start of a comment with bash, which is true with calling functions too: anything after the comment character will be ignored. You have to quote according parameters on calling ot-snippet in parameter mode to avoid that.

ot-snippet-strm is not affected by this unwanted shell interception, as it just reads the values from stdin as they are given.

A possible workaround in parameter mode is, to leave away the normally expected # character with channel names when using specific snippets. The snippet will then just add a hardcoded # character in front of the channel argument.

Note: This has the disadvantage, that using snippets requires knowledge about them, to use them 'correctly'.

With V001 there existed the now obsolete snippet "freenode", which did just that:

# freenode --------------------------------------------------------------------
# a generic snippet expecting <nick> <channel-name> (without leading #)
freenode=("
$2> there exists a specialized channel at freenode irc $open_irc:
$2> ircs://chat.freenode.net/#$3")

embedded variables

There are likely no IRC clients or networks accepting $ (dollar) being used with a valid nickname; nonetheless its possible to use \044 (the octal representation of the dollar character).

If such a value gets used with internal calls doing argument escaping, one might end up at some valid environment variable.

So - if you would feed in a nickname $USER as argument to exec yourself, the called application will just receive the expanded current user account name. Using the replaced content with your output will potentially leak it this way to the public.

Note: Using the stream mode of ot-snippet doesn't eliminate this problem entirely as it will just avoid the first/initial escaping done by the shell call performed by the IRC clients; using nested shell calls later on (using custom functions) could still end up at resolving unwanted variable results.

A typical use case for nested evaluation is using internal variables to keep shared text used with several snippets. Altough its tempting to use linebreaks, tabs or even IRC color codes as escape characters, on should avoid that. To expand the embedded characters one has to turn on escapce code expansion, which will at the same time "translate" a malicious nickname to a variable name. At the moment the internal variable gets used with a snippet, the output will contain the local user's account name instead of the expected nickname of the addressed user...

Note: Using the stream mode of ot-snippet doesn't eliminate this problem entirely as it will just avoid the first/initial escaping done by the shell call performed by the IRC clients; in this case the output should for a one call nesting contain the text $USER instead the expanded value.

#!/bin/bash

function nested
{
	# using any subshell feeding in parameters
	# in this case just returning the value of
	# a variable
	v=$(sh -c "echo \"$1\"")
	echo "nested: $v"
}

function outer
{
	v=$(sh -c "echo \"$1\"")
	echo "outer: $v"
	nested "$v"
}

outer "$1"

/exec para-show.sh "\044USER"

 outer: $USER
 nested: demo

embedded command expansion

The main reason to avoid using the parameter mode from IRC is, that one typically feeds in user nicknames with snippet names. As you got no control over usable nicknames (other than getting careful about suspicious looking ones) they could just contain malicious/unwanted instructions. Feeding in nicknames into a shell call is just handled like any other parameter and such expanded in case it contains according expressions.

Its seemingly allowed with (many/all?) IRC networks to use backticks with nicknames. In parameter mode a nickname like `ls` would be expanded as part of the call of ot-snippet via the shell function and the expanded result gets used as parameter(s).

It takes little to imagine to find more harmful samples than returning your own ~ directory. The parameter mode is kept available as its useful for testing at a terminal but should not be used from IRC clients.

ot-snippet-strm is not affected by this shell interception, as it just reads the values from stdin as they are given without any side effects.

# workarounds for known issues -----------------------------------------
# uncomment to suppress warning at ot-snippet*log

dbind-warning

Using mate-terminal at centos adds a warning to the log (known bug):

(mate-terminal:10017): dbind-WARNING **: 20:39:15.346: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-5JpJNPCMtv: Connection refused

The warning can be ignored - to suppress it with ot-snippet, uncomment:

# uncomment to suppress dbind-warnings at ot-snippet-002.log (centos/mate-terminal)
# details https://orcus.de/main_support/ot-snippet.htm#ki-dbind
export NO_AT_BRIDGE=1

To suppress the warning for all gtk applications, one could export above variable from ~/.profile or ~/.xsessionrc , ~/.xinitrc too.

GLib-warning

Using the default zenity version 3.32.0+17+gfb0938f-1 with lxde at arch linux shows a known glitch/warning:

(zenity:584): GLib-WARNING **: 11:30:09.587: ../glib/glib/giounix.c:410Error while getting flags for FD: Bad file descriptor (9)

The warning can be ignored and has to be fixed with zenity - there is no other workaround available than filtering related messages from the ot-snippet logs. To filter the messages, search and uncomment:

# Glib-warnings (arch/zenity) - details:
# https://orcus.de/main_support/ot-snippet.htm#ki-glib
'Error while getting flags for FD'

GtkDialog warning

Like many other gtk applications is zenity affected by a change at gtk (demanding a parent window with a dialog window:

Gtk-Message: 03:21:25.615: GtkDialog mapped without a transient parent. This is discouraged.

The warning can be ignored and has to be fixed with zenity - there is no other workaround available than filtering related messages from the ot-snippet logs. To filter the messages, search and uncomment:

# GtkDialog-warnings (arch/zenity) - details:
# https://orcus.de/main_support/ot-snippet.htm#ki-gtkdialog
'GtkDialog mapped without a transient parent'