procps/proc/escape.h

14 lines
386 B
C
Raw Normal View History

2002-12-21 16:04:50 +05:30
#ifndef PROCPS_PROC_ESCAPE_H
#define PROCPS_PROC_ESCAPE_H
#include "readproc.h"
2002-12-21 16:04:50 +05:30
#define ESC_BRACKETS 0x2 // if using cmd, put '[' and ']' around it
#define ESC_DEFUNCT 0x4 // mark zombies with " <defunct>"
library: refactor 'escape' logic for newlib essentials This new library provides callers with pure strings or string vectors. It is up to those callers to deal with potential utf8 multibyte characters and any difference between strlen and the corresponding printable widths. So, it makes no sense for the library to go to all the trouble of invoking those rather expensive 'mbrtowc' & 'wcwidth' functions to ultimately yield total 'cells'. Thus, this patch will eliminate all the code and parms that are involved with such possible multibyte issues. [ Along the way we'll lose the ability to substitute ] [ '?' for an invalid/unprintable multibyte sequence. ] [ We will, however, replace ctrl chars with the '?'. ] [ This presents no problem for that ps program since ] [ it now duplicates all of the original escape code. ] [ And, we'll no longer be executing that code twice! ] [ As for the top program, it takes the position that ] [ it is wrong to alter kernel supplied data. So with ] [ potential invalid/unprintable stuff, he'll rely on ] [ terminal emulators to properly handle such issues! ] [ Besides, even using a proper multibyte string, not ] [ all terminals generate the proper printable width. ] [ This is especially true when it comes to an emoji. ] [ And should callers chose not to be portable to all ] [ locales by calling setlocale(LC_ALL, ""), they can ] [ expect to see lots of "?", regardless of what this ] [ library fixes in a faulty multibyte string anyway. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-24 11:30:00 +05:30
int escape_command (unsigned char *outbuf, const proc_t *pp, int bytes, unsigned flags);
2002-12-21 16:04:50 +05:30
library: refactor 'escape' logic for newlib essentials This new library provides callers with pure strings or string vectors. It is up to those callers to deal with potential utf8 multibyte characters and any difference between strlen and the corresponding printable widths. So, it makes no sense for the library to go to all the trouble of invoking those rather expensive 'mbrtowc' & 'wcwidth' functions to ultimately yield total 'cells'. Thus, this patch will eliminate all the code and parms that are involved with such possible multibyte issues. [ Along the way we'll lose the ability to substitute ] [ '?' for an invalid/unprintable multibyte sequence. ] [ We will, however, replace ctrl chars with the '?'. ] [ This presents no problem for that ps program since ] [ it now duplicates all of the original escape code. ] [ And, we'll no longer be executing that code twice! ] [ As for the top program, it takes the position that ] [ it is wrong to alter kernel supplied data. So with ] [ potential invalid/unprintable stuff, he'll rely on ] [ terminal emulators to properly handle such issues! ] [ Besides, even using a proper multibyte string, not ] [ all terminals generate the proper printable width. ] [ This is especially true when it comes to an emoji. ] [ And should callers chose not to be portable to all ] [ locales by calling setlocale(LC_ALL, ""), they can ] [ expect to see lots of "?", regardless of what this ] [ library fixes in a faulty multibyte string anyway. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-24 11:30:00 +05:30
int escape_str (unsigned char *dst, const unsigned char *src, int bufsize);
2002-12-21 16:04:50 +05:30
#endif