macos - bash:ps grep用于Umlaut(OS X)处理

Question

在shell脚本中，我需要找出特定的应用程序是否仍在运行。如果我们的应用程序名称不包含任何Umlauts（äöüàéè...），这将是一个简单的任务。我如何才能可靠地为有问题的过程“ grep”？

在此示例中，shell脚本获取应用程序名称作为参数“amétiqsiMedBüro.app”。有多个同时运行的自定义副本，它们的名称不同，脚本应仅检查特定的应用程序（通过参数获取的一个），而忽略其他应用程序。

将grep用作特定应用程序名称（参数）时，完全没有命中：

bash> ps ax | grep "amétiq siMed Büro.app"

bash>

点击次数过多：

bash> ps ax | grep "/[A]pplications/am" 
 4335   ??  S      5:19.01 /Applications/ame?M^Atiq siMed Bu?M^Hro.app/Contents/MacOS/siMed2
10188   ??  S      0:03.18 /Applications/ame?M^Atiq siMed SUPPORT.app/Contents/MacOS/siMed2

再次尝试手动缩小grep时再次失败：

bash> ps ax | grep "/[A]pplications/am" | grep "Büro"

bash>

似乎grep在第一次出现Umlaut字符的位置后停止工作。

我也尝试过 lsof-没有成功。知道下一步该怎么做吗？

运行OS X 10.7-10.9

Answer 1

tl; dr


使用pgrep代替ps + grep
使用iconv -t UTF8-MAC将搜索字符串转换为NFD（标准化分解Unicode）形式。

pgrep -qlf "$(iconv -t UTF8-MAC <<<'amétiq siMed Büro.app')" && echo "RUNNING"

简而言之：Mac文件系统（HFS +）以分解的Unicode格式（NFD）存储文件名，而您在shell中键入的则是合成的Unicode格式（NFC），并且shell和Unix实用程序都不会处理两个等效的字符串-内容相同，即使内容相同，也可以采用与内容相同的不同形式。

如果您对血腥细节感兴趣，请继续阅读。



背景

一些带重音的Unicode字符具有组合形式-直接代表该字符的单个代码点（例如 ü）以及等效的分解形式-基本字符后跟组合的变音字符（例如 u，后跟 ¨）;有关更多信息，请参见 https://en.wikipedia.org/wiki/Unicode_equivalence。

仅包含组成字符的字符串采用NFC规范化形式（C表示“ Composed”），而仅包含分解字符的字符串采用NFD规范化形式（D表示“ Decomposed”）。

Mac文件系统（HFS +）将文件名存储在NFD（已分解）中，这具有以下含义：


通过Finder和Spotlight启动的应用程序在系统的进程表中表示为NFD字符串。
同样，在外壳程序（Terminal.app中的bash）中，以下所有技术都会产生NFD字符串：


路径名扩展（例如 echo *.app）
ls和类似实用程序的输出
提示时交互式文件名完成

相反，如果您在外壳程序中键入脚本或应用程序名称（或从其他位置复制NFC表单），则将以NFC表示。


问题的症结：shell和Unix实用程序无法识别NFD和NFC形式的等效性，因此将它们视为不同的形式。

麻烦且晦涩的解决方法是仅将NFD字符串与NFD字符串匹配，并且仅将NFC字符串与NFC字符串匹配。

阴险的是，给定字符串的NFD和NFC形式在外壳中看起来完全相同-应当如此-但是要区别对待。

要确定给定的字符串是NFD还是NFC形式，请使用例如：

 cat -v <<<'amétiq siMed Büro.app'

如果字符串在NFC中，则输出与输入相同。
如果字符串在NFD中，则输出包含乱码；例如， ame?M-^Atiq siMed Bu?M-^Hro.app（实际上，这是 ps报告的内容-尽管不应该）。


或者，通过管道传输到 hexdump -C以查看各个字节值。

请注意，关于 man的 ps注释不能正确显示包含多字节字符的参数列表本身是不正确的（至少从OS X 10.9.2开始）：NFC字符串正确打印，而NFD字符串不是正确。
与 pgrep相比，它可以正确打印NFC和NFD字符串，但在匹配时无法识别它们的等效项，如所述。



在NFC和NFD表单之间转换


要在NFD和NFC之间一般转换任何字符串，请使用 iconv和 UTF8-MAC编码方案。


以下示例使用输入字符串 'ü'


以NFC形式 $'\xc3\xbc'-即字节 0xC3 0xBC，它是Unicode代码点 0xFC的UTF8编码
以NFD形式 $'u\xcc\x88'-即 u-基本字符-后跟字节 0xCC 0x88，这是Unicode代码点 0x308的UTF8编码，即所谓的组合音调（ ¨）。


展示转换；请注意，在终端中，结果将始终显示为 ü-例如，通过管道传送至 hexdump -C以查看字节值。

  # NFC -> NFD
iconv -t UTF8-MAC <<<$'\xc3\xbc' # -> $'u\xcc\x88'

  # NFD -> NFC
iconv -f UTF8-MAC <<<$'u\xcc\x88' # -> $'\xc3\xbc'

使用这些转换是安全的，因为如果输入字符串已经是目标格式，则将其保留原样。


要获得字符串的可重用的ANSI-C引号形式-NFC还是NFD-您可以使用下面列出的 bash shell函数 quoteNonAscii；在当前情况下，以NFD格式获取应用程序名称的表示形式：


cd到 /Applications（或您的应用程序所在的任何地方）
运行 quoteNonAscii am*tiq*siMed*B*ro.app-路径名扩展将确保glob扩展为文件名的NFD形式。

# Pass any string to this function to output 
# an ANSI-C-quoted string with all non-ASCII bytes represented
# as \x{nn} hex. codes; trailing newlines are always trimmed.
# Examples:
#    quoteNonAscii 'ü'   # (if NFC) -> $'\xc3\xbc'
#    quoteNonAscii 'ü'  # (if NFD) -> $'u\xcc\x88'
quoteNonAscii() {
  hexdump -ve '/1 "%02x "' <<<"$*" | 
    awk -v RS=' '  '
      BEGIN { printf "$\x27" }                # print the opening of the ANSI-C-quoted string, `${single quote}`
      $1=="0a" { nls=nls "\x5cn"; next }      # store consecutive newlines in a temp. variable
      nls      { printf "%s", nls; nls="" }   # a non-newline char; we now know that the newlines stored so far are NOT trailing, so we print them and clear the temp. variable.
      $1>"7f"  { printf "\\x" $1; next }      # a non-ASCII byte -> PRINT AS `\xnn`
      $1=="22" { printf "\x5c\x22"; next }    # a double-quote char. -> escape with `\`
      $1=="27" { printf "\x5c\x27"; next }    # a single-quote char. -> escape with `\`
      $1=="07"  { printf "\\a"; next }        # bell char.
      $1=="08"  { printf "\\b"; next }        # backspace
      $1=="09"  { printf "\\t"; next }        # tab
      $1=="0b"  { printf "\\v"; next }        # vertical tab
      $1=="0c"  { printf "\\f"; next }        # ff
      $1=="0d"  { printf "\\r"; next }        # CR
      $1=="1b"  { printf "\\e"; next }        # escape
      { system("printf %b \"\\x" $1 "\"") }   # a byte that is an ASCII char -> print as a CHAR.
      END { print "\x27"}'                    # print the closing `{single quote}` of the ANSI-C-quoted string.  
}

macOS中的语言环境：

注意：这是原始答案的修订后遗留物，希望其中仍包含有用的信息。


在交互式外壳中运行 locale会告诉您有效的语言环境，反映在以下环境变量中： LANG， LC_COLLATE， LC_CTYPE， LC_MESSAGES， LC_MONETARY， LC_NUMERIC， LC_TIME 。例如，如果美国英语语言环境生效，您将看到：

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

默认情况下， Terminal.app和其他终端程序（例如 iTerm）默认会预先配置外壳程序的语言环境，以匹配通过 System Preferences > Language & Region指定的用户语言环境（在 Terminal.app中，您可以通过 Preferences... > Settings > {Your Profile} > Advanced关闭此行为，选中框 Set locale environment variables on startup）。


字符编码-反映在语言环境ID的 .{encoding}后缀中，通常为 .UTF8-将匹配终端程序设置中配置的编码（对于 Terminal.app，请转到 Preferences... > Settings > {Your Profile} > Advanced并更改 Character encoding设置） ，如果支持（使用 locale -a查看所有支持的语言/地区+编码组合）。
Terminal和 iTerm都默认为UTF-8，这是一个明智的选择。
如果您的终端程序被配置为使用不受支持的字符编码，则报告的语言环境ID将在 en_US中没有编码后缀（例如，仅 Terminal），并在 "C"中完全还原为 iTerm语言环境-事情可能无法正常工作（ Terminal仍然可以让您从该编码中打印非ASCII字符，但实用程序无法将它们识别为字符，从而导致 illegal byte sequence错误）。
同样，如果您在 System Preferences中配置了不受支持的主要语言和地理区域的组合（例如，将“德语”（ de）与“美国”（ US）组合在一起，则会导致支持的语言环境 de_US） ，只有 LC_TYPE将与终端程序的编码匹配，而其他 LC_*类别将默认为 "C"。

如果需要手动设置语言环境，请运行：


export LANG={localeId}或
export LC_ALL={localeId}


区别在于 export LANG=...为所有 LC_*类别提供默认值，同时允许您有选择地覆盖它们，而 export LC_ALL=...覆盖所有 LC_*类别。
支持的语言环境ID可以用 locale -a列出；最好选择一种基于UTF-8的代码，例如 de_CH.UTF-8。
可以通过 "POSIX"或 "C"选择 POSIX locale-本质上是纯ASCII的美国英语语言环境。
注意：macOS随附的所有Unix实用程序都存在上述问题：它们无法将NFC和NFD中的等效Unicode字符串识别为相同。
除了这个问题，原则上许多（但不是全部）Unix实用程序都支持UTF8多字节字符识别。


从macOS 10.14开始的一个明显例外-即完全不支持UTF8的实用程序- awk;在较早的macOS版本中， sort也不支持UTF8（当以前使用的过时GNU实现替换为最新的BSD实现时，这种情况发生了变化）。