在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
最佳答案
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实现时,这种情况发生了变化)。