I would have written to the bug tracker directly, but it seems to be
broken for me for days, I consistenly get:

undef error - DBD::mysql::st execute failed: You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version for the 
right syntax to use near 'groups LEFT JOIN bug_group_map ON 
bug_group_map.group_id = groups.id AND bug_id ' at line 1 [for Statement 
"SELECT DISTINCT groups.id, name, description, CASE WHEN bug_group_map.group_id 
IS NOT NULL THEN 1 ELSE 0 END, CASE WHEN groups.id IN(-1) THEN 1 ELSE 0 END, 
isactive, membercontrol, othercontrol FROM groups LEFT JOIN bug_group_map ON 
bug_group_map.group_id = groups.id AND bug_id = ? LEFT JOIN group_control_map 
ON group_control_map.group_id = groups.id AND group_control_map.product_id = ? 
WHERE isbuggroup = 1 ORDER BY description" with ParamValues: 0=15922, 1=5] at 
Bugzilla/Bug.pm line 3869.

when I try to access it.

Anyway, the copy is available at

  
http://web.archive.org/web/20241009201026/https://bugs.busybox.net/show_bug.cgi?id=15922

and the example program in the bug report sets argv[0] to an xterm
escape sequence to set terminal title:

  strcpy(argv[0], "/\033]0;X\007");

That specific example is for the nestat, b/c netstat does not sanitize
the cmdline contents before pringing it, as e.g. ps does.

The read_cmdline() function replaces C0 characters (i.e. 0x00..0x1F,
where "c" in "C0" stands for "control") with a safe placeholder.  But
terminal escape sequences can use C1 controls (i.e. 0x80..0x9F) too.

In the example above "\033]" part is the 7-bit spelling of an OSC
(Operating System Command) command, but there's a 8-bit spelling
"\x9d" for it too.  Also, the "\007" terminator is actually
non-standard, the standard VT terminator is ST (String Terminator)
that has 7-bit spelling "\033\\", and 8-bit spelling "\x9c".

So you can change that a.c test from the bug to set:

#define UTF8 "\xc2"
  strcpy(argv[0], "/" UTF8 "\x9d" "0;" "Gotcha" UTF8 "\x9c");

and this new, 8-bit argv evades read_cmdline() filtering.

  $ grep -B1 strcpy a.c
  #define UTF8 "\xc2"
          strcpy(argv[0], "/" UTF8 "\x9d" "0;" "Gotcha" UTF8 "\x9c");
  $ cc a.c
  $ ./a.out &
  $ settitle() { printf '\033]0;%s\033\\' "$1"; }
  $ settitle Hello

Terminal's title (stock gnome terminal on ubuntu) is now "Hello".

  $ ./a.out &
  [1] 2169
  $ ps | grep out
   2179 uwe       0:00 {a.out} /
   2182 uwe       0:00 grep out

and the terminal changes title to "Gotcha".

The story is (ironically) a bit more complicated with xterm(1) b/c its
doparsing() in charproc.c ignores C1 controls it has decoded from
UTF-8:

#if OPT_WIDE_CHARS
        /*
         * If we have a C1 code and the c1_printable flag is not set, simply
         * ignore it when it was translated from UTF-8.  That is because the
         * value could not have been present as-is in the UTF-8.
         *
         * To see that CASE_IGNORE is a consistent value, note that it is
         * always used for NUL and other uninteresting C0 controls.
         */
#if OPT_C1_PRINT
        if (!screen->c1_printable)
#endif
            if (screen->wide_chars
                && (c >= 128 && c < 160)) {
                sp->nextstate = CASE_IGNORE;
            }

but in non-utf8 mode it still processes C1 controls by default.
Another obstacle in that case is allowC1Printable, that the xterm
manual claims is false by default, but in my tests it seems to be
true, so you need to use `xterm +u8 +k8` (and may be use C or 8859
locale) and comment out that "\xc2" in the test program to get plain
ISO-8859 C1 commands ("\x9d") instead of their UTF-8 encodings
("\xc2\x9d")

-uwe
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox

Reply via email to