#897426 Unix pathnames being misinterpreted as commands

Package:
hexchat
Source:
hexchat
Description:
IRC client for X based on X-Chat 2
Submitter:
Matthew Wilcox
Date:
2026-04-23 23:23:03 UTC
Severity:
normal
Tags:
#897426#5
Date:
2018-05-02 13:31:50 UTC
From:
To:
If I try to paste output into hexchat, it will attempt to interpret any
unix pathnames as IRC commands.  For example:

   [CC]    t_truncate_self
/bin/bash ../libtool --quiet --tag=CC --mode=link gcc t_truncate_self.c -o t_truncate_self -g -O2 -g -O2 -DDEBUG  -I../include -DVERSION=\"1.1.1\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DHAVE_FALLOCATE   -lattr /usr/lib/libhandle.la -lacl -lpthread   ../lib/libtest.la
libtool:   error: cannot find the library '/usr/lib/libhandle.la' or unhandled argument '/usr/lib/libhandle.la'

will not paste the second line as text to the person I'm having a
conversation with; rather it will attempt to interpret the second line
as a command, and the conversation gets derailed with missing lines.

Hexchat used to have code to detect unix pathnames, but it's currently
commented out.  I've written and lightly tested a better heuristic --
IRC commands do not contain a /, so if we see a / before we see a space,
we can infer this is not an IRC command.

This is a superset of the current test for "//" at the beginning of
a string, so delete that check as well.

Description: Don't interpret unix pathnames as commands
 Replace the list of common unix pathnames with a simpler heuristic;
 if there are two '/' characters before there is a ' ', this cannot be an
 IRC command, so just send it to the server as text instead of a command.
Author: Matthew Wilcox <willy@infradead.org>
--- hexchat-2.14.1.orig/src/common/outbound.c
+++ hexchat-2.14.1/src/common/outbound.c
@@ -4852,6 +4852,9 @@
 static int
 handle_user_input (session *sess, char *text, int history, int nocommand)
 {
+	char cmd_char = prefs.hex_input_command_char[0];
+	unsigned int i;
+
 	if (*text == '\0')
 		return 1;

@@ -4859,50 +4862,27 @@
 		history_add (&sess->history, text);

 	/* is it NOT a command, just text? */
-	if (nocommand || text[0] != prefs.hex_input_command_char[0])
+	if (nocommand || text[0] != cmd_char)
 	{
 		handle_say (sess, text, TRUE);
 		return 1;
 	}

-	/* check for // */
-	if (text[0] == prefs.hex_input_command_char[0] && text[1] == prefs.hex_input_command_char[0])
-	{
-		handle_say (sess, text + 1, TRUE);
-		return 1;
-	}
-
-#if 0 /* Who would remember all this? */
-	if (prefs.hex_input_command_char[0] == '/')
+	/*
+	 * There are no commands with an embedded /, so if we see one before
+	 * we see a space, assume somebody's pasting a unix pathname or
+	 * similar.  It can't be a command.
+	 */
+	for (i = 1; text[i]; i++)
 	{
-		int i;
-		const char *unix_dirs [] = {
-			"/bin/",
-			"/boot/",
-			"/dev/",
-			"/etc/",
-			"/home/",
-			"/lib/",
-			"/lost+found/",
-			"/mnt/",
-			"/opt/",
-			"/proc/",
-			"/root/",
-			"/sbin/",
-			"/tmp/",
-			"/usr/",
-			"/var/",
-			"/gnome/",
-			NULL
-		};
-		for (i = 0; unix_dirs[i] != NULL; i++)
-			if (strncmp (text, unix_dirs[i], strlen (unix_dirs[i]))==0)
-			{
-				handle_say (sess, text, TRUE);
-				return 1;
-			}
+		if (text[i] == cmd_char)
+		{
+			handle_say (sess, text, TRUE);
+			return 1;
+		}
+		if (text[i] == ' ')
+			break;
 	}
-#endif

 	return handle_command (sess, text + 1, TRUE);
 }

#897426#8
Date:
2018-05-03 08:39:47 UTC
From:
To:
Control: tag -1 upstream

Yeah, it's a somewhat annoying thing I noticed myself.

The concept sounds good to me, could you please try to get this uptream?

The github project is https://github.com/hexchat/hexchat


Thanks!

#897426#13
Date:
2018-05-03 08:39:47 UTC
From:
To:
Control: tag -1 upstream

Yeah, it's a somewhat annoying thing I noticed myself.

The concept sounds good to me, could you please try to get this uptream?

The github project is https://github.com/hexchat/hexchat


Thanks!

#897426#16
Date:
2018-09-01 19:46:08 UTC
From:
To:
Hi Matthew,

Looking if you had the time to submit a PR upstream for this :)

I privately pointed this bug to the upstream developer, and it looked
like he would be in favor of this change!

#897426#21
Date:
2026-04-23 23:20:58 UTC
From:
To:
Hi,

This change is included [1] in zoitechat, the newly uploaded [2] active
hexchat fork. Better late than never!

sney


[1]
https://github.com/ZoiteChat/zoitechat/commit/73733e417615fbc324b679ca56cfc430c8b3fb8d
[2]
https://tracker.debian.org/news/1744495/accepted-zoitechat-2180dfsg-1-all-amd64-source-into-unstable/