bash」タグアーカイブ

bash Color 256

前々回、tree コマンドを Python で自作したんだけど。
「ディレクトリを青色にしたけど tree コマンドとなんか色が違う」
の本家 tree コマンドの色を出力したい。

bash:tip_colors_and_formatting – FLOZz’ MISC

こんなページを発見。
bash ってここまで高機能だったのか、マジで知らなかった!
というか \033 だけじゃなく \e とか \x18 でも良かったのか。
アンダーラインも点滅も反転も、256 色で色指定さえも思いのまま。

しかし文句の付けようがない完璧で解りやすいまとめだなぁ。
こんな有用なページを筆者も作りたい、それは別の話で。

とにかく 256 色に指定するには以下にすればいいのね。

echo -e "\e[38;5;numm***string***\e[0m"

色見本ではドレが tree コマンドの青なのかよくわからない。
自前でソレっぽいのをいくつか選んで出力して確かめてみよう。

#!/bin/bash

for cl in {31..33} {37..39} {73..75} ; do
	echo -e "\e[38;5;${cl}m_texts\e[0m"
done

sh_color

どうやら 33 で正解のようだ。

ところで下方に対応ターミナルの表がありますが。
macOS の Terminal.app でも printf にすればイケます。
おまけに指定は sh でも bash でも zsh でもオケ。

mac_sh

CRLF

何を今頃だけど JavaScript の replace について。

String.prototype.replace() – JavaScript | MDN

第一引数を正規表現にすればすべてのマッチした箇所を置換できるのか。
最初に一致した箇所だけだとずっと勘違いしていた筆者であった。

JXA: doShellScript Line feed code | Paepoi Blog

これを試しに書き換えしてみよう。

#!/usr/bin/osascript

let app = Application.currentApplication();
app.includeStandardAdditions = true;

res = app.doShellScript('ls -l');
console.log(res.replace(/\r/g, '\n'));

いけた。

ついでに。
よく考えたらコマンドの中で tr を使って変換すりゃいいじゃん。
と思ってやってみたら上手くいかなかった。

#!/usr/bin/osascript

let app = Application.currentApplication();
app.includeStandardAdditions = true;

// no...
//res = app.doShellScript('ls -l | tr "\r" "\n"');

// test
res = app.doShellScript('ls -l | tr "\n" "|"');
console.log(res);

となる。

つまりコマンド実行の時点では改行コードは LF のまま。
doShellScript が値を戻す時に CR へ変換しているようです。
LF のまま戻すオプションって無いのかな?

lf

#!/usr/bin/osascript

let app = Application.currentApplication();
app.includeStandardAdditions = true;

res = app.doShellScript('ls -l', {alteringLineEndings:false});
console.log(res);

あった、今後はコレで。

ついでに、doShellScript は bash の POSIX 互換モードです。
zsh やフル状態の bash ではないので注意、macOS って本当に色々面倒臭い。
プログラミングするならやっぱり Linux だよ、某サル専用を除く。

関係ないけど Macbook Air 2020 が出たね、かなり良さげ。
でも筆者はこんな使い方ばかりだから 2018 モデルで何の不満も無いのよね。
ペチペチキーボードにもすっかり慣れてしまったし、うるさいけど。
さて 10.15.4 にアップデートするか。

echo hyphen

ポータブルな echo 代替、reverb コマンド – 拡張 POSIX シェルスクリプト Advent Calendar 2013 – ダメ出し Blog

そうか、echo はオプションとまったく同じ文字列を出力できなかったのか。
でもそんなの — を使えばいいんでね?

先頭にハイフンが付くファイルを削除できない – ITmedia エンタープライズ

echo

だめジャン、これ echo には通用しないのか。
先頭にハイフンがあるだけなら普通に表示できるし関係なかったか。
でも何か手段が他にあるはず、と思って探してみた。

Bashで文字列をエスケープをする – Qiita

printf %q “$value”
こんな手段があるとは。

printf

イケた、オプションと同じ文字列は case 文で振り分けすれば使えそう。
って zsh だと \n を入れなくても強制改行してしまうんだね。
そんなことより gnome-terminal で zsh を使うと Home/End キーでカーソル移動ができないことのほうが気になるぞ!
こんな所でも bash と zsh の違いがあるのがなんとも。

macOS sh

macOS で man sh を初めて見てみたんだけど。

つまり /bin/sh は /private/var/select/sh を起動する。
その /private/var/select/sh は /bin/bash へのシンボリックリンク。

つまり macOS の sh も bash が本体ということみたい。
環境によってリンク先は変わるかもだが筆者の Air はこうなっていた。
なんでこんな面倒な仕組みになっているんじゃい。
Fedora みたいに直接 sh というリンクにすればいいのに。

でもまてよ、sh と bash は動作が違っていたよな。
(bash|zsh) read command 2 | PaePoi

色々探してみたらこんなのを見つけた。
/bin/sh と /bin/bash の違い – 双六工場日誌

あぁそういうことだったんだ。
Fedora 30 で試したらやはり posix のオプションが違っていたよ。
sh は bash を posix sh 互換で起動する呼び出し方で合っているかな。
でも Fedora の sh は \n 文字を文字として扱うのよね、まあいいか。

しかし何故 dash も選択肢に入っているのか?
Debian Almquist shell – Wikipedia
debian 系のコレと同じものだと思うけど、標準で入っている理由がワカンネ。

macOS 10.15 Catalina

macOS 10.15 Catalina を導入しました。
Macbook Air 2018 の Mojave からのアップグレードです。
さて、一番気になる所をチェック。

デフォルトシェルは初期状態では bash のまま。
ただし [zsh に自分で変更しろ] というメッセージが毎回出る。
.bashrc でカスタムしていた所は .zshenv に変換コピペ等の猶予がある。
一通り調べた後で筆者も zsh に変更します。

Python2 も実は残っている、同様なメッセージが出る。
でも Python3 ってあれ?

筆者は自分で Python3 を入れたけど、それは /usr/local/bin にある。
デフォルトで /usr/bin に入るようになったみたい、情報が無かったけど。
シンボリックリンク先は同じなので残しても問題ないけど local のは消すかな。

PyObjC は pip3 で自分で入れたのだけどコレも最初からあるのかいな?
他人の情報を待とう。

筆者自作の Comipoli はソースもビルド済みも問題なく動いた。
ただソースのまま起動するのが異様に遅くなったような気が。
macOS アプリケーション

何より気になる JXA での NSRect のバグ。

そのまんまヤン!
もう JXA はダメだ、GUI は PyObjC に完全移行しよう。

httpd.conf はやはりリセットされた。
変更点は特に無いようだ、とっとと元に戻す。
macOS httpd.conf | PaePoi
んで

sudo apachectl restart

そんなことより。
sips を使ったスクリーンショットの 72dpi 変換ができない!
macOS をクイックアクションで拡張 – L’Isola di Niente
シェル変更の影響か?

#!/usr/bin/env python3

# change72dpi *.png

import sys, os
from AppKit import *
from Quartz.CoreGraphics import *

args = sys.argv[1:]

for s in args:
    name = os.path.basename(s)
    src_image = NSImage.alloc().initWithContentsOfFile_(name)
    img = NSBitmapImageRep.imageRepWithData_(src_image.TIFFRepresentation()).CGImage()
    h = CGImageGetHeight(img) // 2
    w = CGImageGetWidth(img) // 2
    ctx = CGBitmapContextCreate(None, w, h, 8, 4 * w, CGColorSpaceCreateDeviceRGB(), kCGImageAlphaPremultipliedLast)
    CGContextDrawImage(ctx, CGRectMake(0, 0, w, h), img)
    imgref = CGBitmapContextCreateImage(ctx)
    out_image = NSImage.alloc().initWithCGImage_size_(imgref, (w, h))
    bmp = NSBitmapImageRep.imageRepWithData_(out_image.TIFFRepresentation())
    data = bmp.representationUsingType_properties_(NSBitmapImageFileTypePNG, {})
    data.writeToFile_atomically_(f'72dpi-{name}', True)

以前書いた使い捨てスクリプトでなんとか 72dpi 変換した。
しかし端末でこんなの出ていたっけ?

とりあえず気がついたのはそんなところ。
相変わらず mac らしい使い方をしていないなぁ。