純 POSIX sh 實作各種功能

看到「pure sh bible」這篇,講純 POSIX 的 sh 可以怎麼實作各種功能,Hacker News 上的討論在「Pure Sh Bible (github.com/dylanaraps)」這邊。

一般我在寫 cross platform 的 shell script 時候會假設是 POSIX environment,而不是只有 POSIX sh 硬扛,所以還是有 awkgrepsed 這類工具可以用... 而這篇裡面提到的方法有些很明顯是硬扛過去的 XD

不過裡面還是有些章節是應該要熟悉的,像是對 string 的處理算是蠻好用的,不需要拿 sed 出來用。

另外可以用 bash 的話,有很多東西會好寫很多,但開頭的 #!/bin/bashFreeBSD 上會因為 bash 會裝到 /usr/local/bin/bash,就不是很好搞... 一個解法是用 /usr/bin/env bashPATH 找,但也不是完全保險的方法 (PATH 有時候會清空...)。

在 Shell 下一行用 SQLite 查詢 CSV 內的資料

Simon Willison 這邊看到 command line 下用 SQLite 的技巧:「One-liner for running queries against CSV files with SQLite」。

範例指令是這樣 (整理了一下排版):

sqlite3 :memory: \
    -cmd '.import -csv taxi.csv taxi' \
    'SELECT passenger_count, COUNT(*), AVG(total_amount) FROM taxi GROUP BY passenger_count'

可以看出來這個方式是將 csv 檔先讀到 in-memory database (:memory:),再用 SQLite 下指令處理,另外也可以自己變化,應該可以透過 /dev/stdin 這樣的方式讀 pipe 的東西。

拿來簡單跑一些東西應該還不賴?

moreutils

今天的 Hacker News Daily 上面看到「Moreutils: A collection of Unix tools that nobody thought to write long ago (joeyh.name)」這則,講 moreutils 這套工具。

翻了一下之前在「當程式沒問題時就會吃掉輸出的 chronic」這邊有提過 chronic 了,原文的討論裡面也提到了其他工具的用法,像是 sponge 可以在 pipe stdin 都收完後才開檔案寫入,可以避免 shell 直接先把檔案幹掉的問題:

awk '{do_stuff()}' myfile.txt | sort -u | column --table > myfile.txt

在這個例子裡面因為 myfile.txt 先被 shell 清空幹掉了,awk 就讀不到東西,這時候可以用 sponge 接,等到 pipe stdin 都收完後才寫檔案:

awk '{do_stuff()}' myfile.txt | sort -u | column --table | sponge myfile.txt

另外是 vipe,可以在先將程式輸出的結果丟進 $EDITOR 裡面,然後再往後丟,像是:

git branch | vipe | xargs git branch -D

還有其他的工具可以用,我自己是把 moreutils 當標配在裝了...

與 jq 互相配合的 jc

Simon Willison 的 blog 上看到的工具:「jc」,專案的網站:「JSON CLI output utility」。

可以把許多種輸出結果轉成 JSON 格式:

CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.

所以就可以這樣用:

dig example.com | jc --dig

然後再丟給 jq

dig example.com | jc --dig | jq -r '.[].answer[].data'

支援的格式不少,在「Parsers」這段可以看到。

Ubuntu 22.04 後可以直接透過系統的 apt 安裝:「Ubuntu – Details of package jc in jammy」,在那之前也可以透過 pip 裝起來用...

等 Ubuntu 22.04 出了以後應該會變成標配安裝...

FreeBSD 把 root 預設的 shell 改成 /bin/sh

Hacker News 首頁上看到 FreeBSD 把 root 的 shell 從 /bin/csh 換成 /bin/sh 了:「sh(1): make it the default shell for the root user」,Hacker News 上的討論也可以看一看:「FreeBSD switches the default root shell from csh to sh (freebsd.org)」。

依照說明是把 FreeBSD 的 /bin/sh 加上了不少東西,所以算是堪用了:

In the recent history sh(1) has gain the missing features for it to
become a usable interractive shell:
- command completion
- persistent history support
- improvements on the default bindings in emacs mode
- improvements in the vi mode (repect $EDITOR)
- print a newline when exiting via ^D
- default prompt and improvements on how PS1 can be configured
- and more.

This changes also simplifies making tiny freebsd images with only sh(1)
as a shell

以前也是用 csh 系列的 (像是 tcsh),後來開始用 Linux 就往 BashZsh 定居了...

很久沒出新版的 mosh...

在今天的 Hacker News Daily 上看到 mosh 的連結,看了一下 Hacker News 上的討論,發現原作者有上去跟大家討論一些目前的情況:「Mosh: The Mobile Shell (mosh.org)」。

原作者是 Keith Winstein,在 Hacker News 上的帳號名稱是 keithwinstein,可以用 Ctrl-F 翻一下他回應的東西。

關於四年沒有新版的原因,一方面是他覺得已經將後續的開發與維護交棒出去,不應該因為接手的人太忙就冒出來;另外一方面是目前的版本也沒有安全問題,沒有迫切需要丟出一個新版本:

I think the truth is that we don't feel like we need a release. We've never had a security hole, our track record speaks for itself, and I wouldn't really want us to rush anything and blow that. There are some features that it would be really nice to have in a release (like 24-bit color support, and working around a recent MacOS clock bug), but I handed over the maintainership to somebody else about six years ago and that person is currently, I think, dealing with a bunch of stuff (look around the world the last year...). I'm not eager to step back in and bigfoot them -- especially when I'm no longer particularly familiar with the codebase (and recent commits) as I used to be.

Mosh works as advertised and has never had a security hole -- we're pretty proud of that! We'll probably cut a release at some point to add those features (24-bit colors, the MacOS clock workaround) but I'm not feeling like it's urgent enough to upset what I had hoped was a transition plan.

It would feel arrogant to compare Mosh to TeX, but it doesn't seem that crazy to imagine that some software might reach a point where it has accomplished 95% of its goals, and the benefit from adding further features has to be weighed against the risk of introducing a security hole or other regression through further churn. If the TCP specification, or OpenSSH, or TeX, or GNU bash had canonical GitHub repositories, they would probably be full of a bunch of user support issues and inactive PRs too. :-)

看了一下 GitHubContributors 這頁,可能是 cgull

的確是一個很穩定的軟體,在桌機與筆電上面都用了八九年了,解決了網路切換 (或是不穩定) 的問題:「把 SSH 換成 Mosh」。

Mac OS 7/8/9 上的 SSH client

Hacker News 首頁上看到「Ssheven: A modern SSH client for Mac OS 7-9 (github.com/cy384)」這個,為了 Mac OS 7/8/9 (PowerPC 平台) 實做 SSH client。

翻了一下程式碼,看起來是透過 libssh2 實做加解密的部份,依照 libssh2 的官網,支援的演算法雖然不是超級新,但看起來還算可以 (至少有目前還算安全的演算法可以用):

Hacker News 上有看到一些老機器跑出來玩 XD

tikwidd 8 hours ago

So far it's working well on my LC III (68030 with 36mb ram)!
I'm writing this comment from the LC III using w3m over ssh :)

SSH 對傳入參數的 quoting

昨天在 Hacker News 首頁上看到「SSH quoting」這個,看得出來作者被 OpenSSH 玩弄到不要不要的樣子...

先簡單的整理一下:

$ ssh example.com 'cd /tmp; pwd'
/tmp
$ ssh example.com 'bash -l -c "cd /tmp; pwd"'
/tmp
$ ssh example.com bash -l -c "cd /tmp; pwd"  
/home/gslin

第三個指令發生的「預期外的行為」,但寫習慣的人會把指令全部包成一個字串,就很自然的避開這個問題了。當然 OpenSSH 的設計 (讓你不用加 quote 也會動) 的確也是容易中獎的點啦...

原來 Sentry 有支援 Bash...

Sentry 可以拿來蒐集自己開發軟體的錯誤事件,剛剛突發奇想用搜尋引擎找了一下,發現 Sentry 是有支援 Bash 的:「Sending Sentry Events from Bash」。

文章裡面也直接提到了 hook 的用法,在裝了 sentry-cli 後可以掛進來:

#!/bin/bash
export SENTRY_DSN=
eval "$(sentry-cli bash-hook)"

自己架 Sentry 的步驟我有丟在「Sentry」這邊,或者也可以用雲端的版本。

丟給同事參考看看...

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇,在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ],被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串,不過文章作者找到更多奇怪的 bug report,像是 () 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了,但我應該還是會繼續這樣寫 (算是 best practice 了),可以避免在遇到老系統上遇到問題...