グラフィックまわりの微調整らしいけどbetaが16
homebrew pwgen
- 今日の時点で2.08
- ソースの管理はsourceforge https://pwgen.sourceforge.io/
homebrew-core/pwgen.rb at master · Homebrew/homebrew-core · GitHub
APFS ファイル名文字コード
MacOS High Sierra以降では、ファイルシステムはAPFSを使っている。
What's New in Apple File System - WWDC 2017 - Videos - Apple Developer
FAQのページがいつなくなるかわからないので引用する。
How does Apple File System handle filenames? APFS accepts only valid UTF-8 encoded filenames for creation, and preserves both case and normalization of the filename on disk in all variants. APFS, like HFS+, is case-sensitive on iOS and is available in case-sensitive and case-insensitive variants on macOS, with case-insensitive being the default. In macOS High Sierra, APFS is normalization-insensitive in both the case-insensitive and case-sensitive variants, using a hash-based native normalization scheme. In iOS 11, APFS is normalization-insensitive as well, using either a native normalization scheme (erase restores only) or runtime normalization scheme (upgrades from previous versions). Runtime normalization will also be available in iOS 10.3.3 and macOS Sierra 10.12.6. Being normalization-insensitive ensures that normalization variants of a filename cannot be created in the same directory, and that a filename can be found with any of its normalization variants. This means that you don’t need to do any additional work to ensure correct normalization behavior in these versions of macOS and iOS. Some differences between how APFS and HFS+ handle filenames include the following: APFS implements normalization and case insensitivity according to the Unicode 9.0 standard; this enables APFS to support a wider range of languages for these features than HFS+, which is based on Unicode 3.2. APFS preserves the normalization of the filename and uses hashes of the normalized form of the filename to provide normalization insensitivity, whereas HFS+ stores the normalized form of the filename on disk to provide normalization insensitivity. Calling readdir(2) on a directory in APFS returns filenames in hash order, whereas HFS+ returns filenames in lexicographical order. While both filesystems expect filenames to be encoded in UTF-8, APFS stores filenames on disk in UTF-8 encoding, whereas HFS stores filenames on disk in UTF-16 encoding. APFS doesn’t allow files to be created with filenames that contain unassigned codepoints in the Unicode 9.0 standard, whereas HFS+ does. In iOS 10.3 and in the case-sensitive variant of the developer preview of APFS in macOS Sierra, APFS is normalization-sensitive. For these versions, developers should be aware of behavior differences between normalization sensitivity and insensitivity that may arise when a device upgrades macOS or iOS and migrates the filesystem from HFS+ to APFS. For example, attempting to create a file using one normalization behavior and then opening that file using another normalization behavior may result in ENOENT, or “File Not Found” errors. Additionally, storing filenames externally, such as in the defaults database, Core Data, or iCloud storage may cause problems if the normalization scheme of the filename being stored is different from what exists on disk. To avoid introducing bugs in your code with mismatched Unicode normalization (for iOS 10.3.0, 10.3.1 and 10.3.2) in filenames, do the following: Use high-level Foundation APIs such as NSFileManager and NSURL when interacting with the filesystem. Use the fileSystemRepresentation property of NSURL objects when creating and opening files with lower-level filesystem APIs such as POSIX open(2), or when storing filenames externally from the filesystem.
WWDC2017のスライド資料と合わせて読むと、APFSでは正規化されていないUTF-8としてファイル名が保存される。そして、MacOS High Sierra上で日本語の含まれた名前のファイルを作成し、Windowsで見ようとすると、文字化けする。
ソースコードを完全に追っかけられてはいないが、以下のようにSHIFT_JIS文字列のファイル名のファイルを作成しようとすると失敗するし
$ touch $(echo "かばん" | nkf -Ls).csv # 失敗 touch: cannot touch ''$'\202\251\202\316\202\361''.csv': Illegal byte sequence $ touch $(echo "かばん").csv # 成功
SHIFT_JISな文字列にファイル名をリネームしても、その場では成功するが、結局ファイル名のリネームはうまくいってない
$ convmv -t shift_jis -f utf-8 * .... No changes to your files done. Would have converted X files in 0 seconds.
なお、サーバーからSHIFT_JISなファイル名のファイルをダウンロードしてFinderで開いてみたりしてもファイル名の文字コードは変わらない
スクリーンショットの保存先を変更する 2018
2018年も全く変わってなかった
$ defaults write com.apple.screencapture location ~/(保存先) $ killall SystemUIServer
Terminalで`alt + b` `alt + f`でキーワードジャンプしたい(Emacsみたいに)
- Terminal(iTerm2は最近使わなくなった)で
alt + b
alt + f
でキーワードジャンプしたい(Emacsみたいに) - 設定→キーボード→メタキーとしてOptionキーを使用にチェック
open excel from csv with cui
open -a "Microsoft Excel" test.csv
Macのuuidgenを小文字で
- Macのuuidgenを小文字で
- 単体のオプションでは小文字にするオプションはなく、英字は基本すべて大文字出力。
- MacはBSD系だけどFreeBSDのuuidgenともオプションが違ってた
$ uuidgen | tr "[:upper:]" "[:lower:]"
split BSD vs GNU
-d
の有無が主な違い。
coreutilsをmacportsだかhomebrewだかでいれてgsplit
ってすれば、GNU版のsplitがつかえる(-dオプションがつかえる)
apple.stackexchange.com
removeコマンド mac
brew install removeで入る。removeはBSD系ではデフォルトでは入っていない。
Macでスクリーンセーバーをすぐに
「設定」→「スクリーンセーバー」→「ホットキー」→で、左上か左下に「スクリーンセーバーを開始する」って設定して、マウスポインタを設定したとこに移動すると、スクリーンセーバーが発動する。
gzファイルの件数(Mac)
BSD系だからね、ちょっと確認しないとね。
gzcat -f test.log.gz | wc -l