オススメ

How to Multi/Dual boot :: Windows and Linux の実際

3つ以上のOSを破綻なくブート可能にする::MBR & UEFI

さまざまなディストリビューションを試し最後に決めるのが一番です

Windows10+Linuxのマルチブートの実例です。今回は以前に書いた原稿をもとに、MBRの場合を改稿しました。

Windowsはないと困るけれど、Linuxも使ってみたい。Windows7とWindows10の併存のような誰でもできるカンタンなDualBootはできるけれど、Linuxが絡むと難しいと考えるような方向けにまとめてみました。

まだMBRの方も多いと思いますので、実例を報告しておきます。2-3年かそこらの断面です。 現在の当方は、EFIブートで、全ディスクがGPT です。MBRと違い制約がないので楽ちんですね。 機会をみて入れ替えるとよいかと思いますよ。 また、VirtualBoxなどの仮想マシンではどうしても遅くなりますから、RAW=つまり本物を使ってOSは評価するのがやはりよいと考えています。速度は印象を変えますから。


SSD容量とパーティション計画

MBR時代の実例、512GB以下を利用した頃

分割容量適用
/20Gいろいろ入れて8GB。12GB空き。*1
/home50GB40GB。不足気味。/homeは長く使うなら分けるべきかも。
swap9GBメモリ容量プラスアルファで全9GBくらい確保しています。
古いSSDの空きに。
/tmptmpfs最初はデフォルトで良い。fstabは慣れるまで触らないを推奨
*1=2年前、25GBで作成しましたが、gpartedで20GBに減らしたところです。到底使いそうにないので。

最近のある日の例

m.2 1TB NVMe gpt -- Windows10 LinuxMint ManjaroLinux 



SSD1号 /dev/sda MBR/ブートローダ/GRUBはここに

DISK/PART用途適用
sda1Win7/Win10ローダNTFS チェインロードでWindowsのどれかを起動
sda2mint CinnamonEXT4
sda3ubuntu MATEEXT4
ex1HOMEEXT4 /home どのlinuxでも共通に。
ユーザー名を変えると楽。
ex2DATANTFS
ex3ディストロ評価完全実験用、ときどき起動しなくなる。

SWAP は必ずしもパーティションを必要としない

Linuxをいくついれようがswapはひとつで困らないと思います。また、最近のカーネルではファイルをSWAPとして設定できますから、SWAP専用パーティションは必ずしも必要ではありません。覚えておくとハッピーになれるかも。こちらにまとめました。
Linux SWAPをパーテションでなくファイルで設定する[3分クッキング]

転ばぬ先の杖 GRUBのMBRへの書き込み

MBRを利用していた頃の話です。SSD2=/dev/sdb に時々予備的にGRUBを書き込んでいます。いろんなディストロをいれて「お試し」するためにおもに使っています。
メインGRUBが壊れてしまったときでも、インストールUSBメモリなどなしですんなり復旧作業に入れます。即時復旧作業ができますから快適。そういう機会に遭遇することもなくなりましたが。

その他のおせっかい

ちょっと使ってみたいならライブISOでもいいです。SSDでも15GBとっておけばだいじょうぶです。本格的に使う可能性があるなら最初からディストリビューションの推奨どおりに割り当てたほうがよいです。めんどくさいです。

/tmpが少なすぎると困ることがありますので、運用次第ですが注意してください。RAMに割り当てると小さいわけで。

メモリ合計8GBあれば通常余裕です。現在4000円位でしょうか。 4GBあればライトなデスクトップ用途は十分かなと。VirtualBoxなどを常時起動するのであれば、8GBほしいところですね。めんどくさいので16GBです。

Cinnamonに比較してMATEはメモリ消費は少ないです。ですが、Windowsに比べると他のフレイバーも少ないです。あんまり気にかける必要はないです。8GB積んでいる場合、起動状態で1GBとすこし消費ってのを目安に考えてください。軽いブラウジング程度では4GBを超えることはまったくないです。SWAPも発生していないのと同じです。
無精者のバックアップ:: /homeをスライスしておいたほうが長期視点ではベストチョイス

マルチブートで、パーテションスライスを分けすぎると、バックアップ計画や2年に一度のLTSアップグレードなどがめんどうになります。/home を独立させるぐらいが楽でいいと思います。 ざくっとな!!です。とにかくバックアップさえ取得して戻せるならご自由にです。

死守している/home は分割していますので当方は12年以上引き継いて使っています。細かい設定ファイルもそのまま軽い調整で継続できます。考え方次第です。

/homeも含めて1パーテでも良いかもしれませんが、アップグレード時によりめんどうな作業が発生しますので、ゼロから環境を構築するのが苦にならない人、レストアしながらでいいやと思える人以外にはあまりおすすめしません。Linuxを一時的なお試しとして使うなら別ですね。お手軽にどうぞ。

おまけ::今日の私のメインNVMe SSDの構成/UEFIブート、GPT

上記のMRRではありません。gpt/uefi 、NVMe 1TBでの例です。

UEFIになってWindowsの大先生(匿名掲示板によれば自称パワーユーザーの意味ですか)でしくじっている、勘違いしているのはだいたい図で示す2番目のFAT・efi 置き場の設定や仕組みがわかってないケースですね。ほぼコレかも。

2番目::/boot/efi Windows10と共用 FAT
8番目::/home 各Linuxで共通のEXT4
自分の結論:: UEFIブートがもっともシンプルに構成できていい。
BIOSでの uefi bootのセレクター"も"使いやすいので、なんとでもなる。

/boot/efi の秘密



慣れている人なら、このリストを見ただけでおわかりいただけるでしょう。抜粋です。


$ sudo find /boot/efi/EFI -type f | perl -lnE '/\A.*efi$/ and s/[^-][^\/]*\// |/g;s/|\([^ ]\)/|-\1/ and print' #tree

綺麗でないので、やっぱ tree コマンド導入。sudo apt install tree


/boot/efi/EFI
├── Boot
│   ├── bkpbootx64.efi
│   ├── bootx64.efi
│   ├── fbx64.efi
│   └── mmx64.efi
├── MX18.1
│   └── grubx64.efi
├── MX18.3
│   └── grubx64.efi
├── Manjaro
│   └── grubx64.efi
├── Microsoft
│   ├── Boot
│   │   ├── BCD
│   │   ├── BCD.LOG
│   │   ├── BCD.LOG1
│   │   ├── BCD.LOG2
│   │   ├── BOOTSTAT.DAT
│   │   ├── Fonts
│   │   │   ├── chs_boot.ttf
│   │   │   ├── cht_boot.ttf
│   │   │   ├── jpn_boot.ttf
│   │   │   ├── kor_boot.ttf
│   │   │   ├── malgun_boot.ttf
│   │   │   ├── malgunn_boot.ttf
│   │   │   ├── meiryo_boot.ttf
│   │   │   ├── meiryon_boot.ttf
│   │   │   ├── msjh_boot.ttf
│   │   │   ├── msjhn_boot.ttf
│   │   │   ├── msyh_boot.ttf
│   │   │   ├── msyhn_boot.ttf
│   │   │   ├── segmono_boot.ttf
│   │   │   ├── segoe_slboot.ttf
│   │   │   ├── segoen_slboot.ttf
│   │   │   └── wgl4_boot.ttf
│   │   ├── Resources
│   │   │   ├── bootres.dll
│   │   │   ├── en-US
│   │   │   │   └── bootres.dll.mui
│   │   │   └── ja-JP
│   │   │       └── bootres.dll.mui
│   │   ├── bg-BG
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── boot.stl
│   │   ├── bootmgfw.efi
│   │   ├── bootmgr.efi
│   │   ├── cs-CZ
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── da-DK
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── de-DE
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── el-GR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── en-GB
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── en-US
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── es-ES
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── es-MX
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── et-EE
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── fi-FI
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── fr-CA
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── fr-FR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── hr-HR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── hu-HU
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── it-IT
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── ja-JP
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── kd_02_10df.dll
│   │   ├── kd_02_10ec.dll
│   │   ├── kd_02_1137.dll
│   │   ├── kd_02_14e4.dll
│   │   ├── kd_02_15b3.dll
│   │   ├── kd_02_1969.dll
│   │   ├── kd_02_19a2.dll
│   │   ├── kd_02_1af4.dll
│   │   ├── kd_02_8086.dll
│   │   ├── kd_07_1415.dll
│   │   ├── kd_0C_8086.dll
│   │   ├── kdnet_uart16550.dll
│   │   ├── kdstub.dll
│   │   ├── ko-KR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── lt-LT
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── lv-LV
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── memtest.efi
│   │   ├── nb-NO
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── nl-NL
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── pl-PL
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── pt-BR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── pt-PT
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── qps-ploc
│   │   │   └── memtest.efi.mui
│   │   ├── ro-RO
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── ru-RU
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── sk-SK
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── sl-SI
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── sr-Latn-RS
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── sv-SE
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── tr-TR
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   ├── uk-UA
│   │   │   ├── bootmgfw.efi.mui
│   │   │   └── bootmgr.efi.mui
│   │   ├── winsipolicy.p7b
│   │   ├── zh-CN
│   │   │   ├── bootmgfw.efi.mui
│   │   │   ├── bootmgr.efi.mui
│   │   │   └── memtest.efi.mui
│   │   └── zh-TW
│   │       ├── bootmgfw.efi.mui
│   │       ├── bootmgr.efi.mui
│   │       └── memtest.efi.mui
│   └── Recovery
│       ├── BCD
│       ├── BCD.LOG
│       ├── BCD.LOG1
│       └── BCD.LOG2
├── feren
│   ├── BOOTX64.CSV
│   ├── grub.cfg
│   ├── grubx64.efi
│   ├── mmx64.efi
│   └── shimx64.efi
├── memtest86
│   ├── MemTest86.log
│   ├── blacklist.cfg
│   ├── memtestx64.efi
│   ├── mt86.png
│   └── unifont.bin
└── ubuntu
    ├── BOOTX64.CSV
    ├── grub.cfg
    ├── grubx64.efi
    ├── mmx64.efi
    └── shimx64.efi

50 directories, 161 files









サンプルコードを一括改訂:: 退屈なことはPythonにやらせよう

退屈なことはPythonにやらせよう::準備レビュー

せっかくのサンプルの改行コードがDOSだったり、シェバンが何だったりします。そこをまず治します。

退屈なことはPythonにやらせよう ――ノンプログラマーにもできる自動化処理プログラミング」のレビューの前に

これではちょっとLinux環境(やたぶんMAC OS Xでも?!)並びにWSLではいささか扱いにくいので、

  • 改行コードを変更します。DOS改行をUnix改行に。
  • シェバンをLinux環境に合わせて書き直します。

するといいかもしれません。失敗してもまた展開すればいいです。
Windows向けの本だったのかぁ。そういえばドライブレターの記述が……。

以下、一括の呪文。配下のpyをぜんぶ書き換えて、オリジナルは残します。PerlのOneLinerってこういうがさらっとできるので大好きです。配下には書き換えたいファイルが47個ありますね。

新規端末 CTRL+ALT+T

#zip展開したディレクトリで、次のperl行を発行します。

~/Programming/py/Python_practice_projects <<ここに展開したとします。

$ perl -i.4Windows -lpe 's/\r// ; s|^#\! python3$|#! /usr/bin/env python3| if 1 ' **/*.py  Enter

一瞬で終わらなければ、切り貼りミスかも。

--
そのまま続けて::
実行属性を付与
$ chmod +x **/*.py Enter


$ grep -r '#! /usr/bin/env python3'  Enter
書き換わっていることが確認できます。

$ ./ch03/collatz.py  Enter

整数を入力してください:


何がおきるか。シェバンは1行目、改行はDOSという前提です。それを一括で書き換えます。


  • シェバンが、#! /usr/bin/env python3 に変更される。Linuxフレンドリー
  • 改行コードは、LFに変更されているはず。Linuxフレンドリー
  • オリジナルファイルは、.4Windows という拡張子付きで残る。安心です。




レビュー::
いまのところベッドでの寝酒代わりなので、そのうちちゃんと。



2配信チャンネル同時に。見逃さない、fujirock2018 automaton。timeshift 、ondemand で鑑賞するシンプルハック[改稿]

フジロック2018(fujirock2018)などストリーミング、ライブ配信を安定画質、タイムシフトで鑑賞する。パーフェクトらくらく技法

いうなれば、ライブ配信に関わるオートマトンを稼働させるということ。オンデマンドっぽくというか。ubuntuでうまくないので、manjaro での稼働にしました。

らくらくなのは結果であって試行錯誤は涙付きかもしれません。技術レベルは初心者より少しぐらい慣れたPC中級者でしょうか。
まったくの初心者でもじっくり読んで数行のコマンドを発行すれば使えるようには配慮したつもりであります。

ubuntuではうまくいかない場合があったため、テストを繰り返したmanjaroに戻しました。結果、非常にうまく動作しています。満足です。

エキスパート向け要約::本質はたったの1行です。オートマトンっぽくするためには2行です。

   $ at -t 201807281250
   timeout 4000 mpv  https://youtu.be/Rjrgz-lfcdQ -o 'The Birthday.mkv'
熟練ユーザーにはこの2行だけでご理解いただけるかと思いますので、ここまで読めばだいじょうぶです。
さて、本論です。

Linuxに含まれるコマンド、アプリでいろいろ試してみた結果::次の観点から選びました

  • 回線が不安定な環境でも可能な限り高画質でライブ一時保存しつつ鑑賞する。中断や停止がほとんど起きない。
  • タイムシフトで鑑賞できる。但し、生成ファイルは巨大になっていくので、ストレージに余裕がないとつらい。不要になったらどんどん削除していくほうがいい。
  • フジロックライブ配信タイムスケージュルを勘案して、時刻指定自動起動、自動終了させる。放置しておくとストレージ圧迫です。ジョブを停止するのを忘れないでください。

技術的おおざっぱ(結果だけ得たい場合は知らなくてもいいこと)

  • 結果的に mpvとyoutube_dl の機能を組み合わせている。当然だがプレイヤーはデコードしながら動いている。これはWMPでも同じである。ブラウザ内動画再生エンジンでも同じである。それをインターセプトしている。 
  • 都合、 atコマンドで自動化。リアルタイムでH.264/MKVにして自動的にキャッシュ保存する。
  • ちょっと期待していたWindowsW10のゲームモードではうまくいかない(マイクロソフトが悪いわけではありません。そういう用途です)。このLinuxオートマトンなら稼働中に何をしてもだいじょうぶ。タイムシフトでキャッシュファイルで観ることができる。
  • チャンネルを切り替えたりしてもOK。他のアプリも起動できる。ブラウザでニュース読んだりしてもだいじょうぶ。
  • 2ライブチャンネル同時でもだいじょうぶ。速いマシンが必要です。
この一連の流れは「オートマトン」録画マシン構築に見える人もいるかもしれませんが、キャッシュを明示的に指定して生成していける動画再生エンジンであるmpvの機能の応用です。不安定な回線でライブ配信に限らずyoutubeコンテンツを綺麗に、遅延や中断なく視聴する冴えた方法かと思います。

所要コマンド:: ubuntu でうまくないので、manjaroに戻しました(だいじなことなので繰り返します)

このライブ配信タイムシフト視聴技法が使える可能性のある人

  • UNIX系の仲間。Linux,MAC OS X,及び最近ではWindows10にWSLを導入している人。
  • (必要コマンドがインストールできる人なら、事実上世界の誰でもいける)
※LinuxでManjaro と ubuntu で実証実験を行ってみました。他の環境では深入りして試していません。WindowsNative に移植されたWinバイナリではうまく動作しませんでしたのでさくっと中断。WSLなら可能性はあると思います。ubuntuでうまくないので、ManjaroLinuxに戻しました。

実際に仕込んだコマンド例::Linuxではこうする。

以下はもちろん未来のことなので、何が起きるかわかりません。テストした範囲では、とてもうまく動作しました。タイムスケジュール は後ろめにずれがちみたいです。
たとえば、今日土曜日、The Birthday が12:50からライブ配信予定です。 Linuxのターミナルで、

土曜日の見本

   $ at -t 201807281250
   ついで、次の1行を貼り付けます。

   timeout 4000 mpv  https://youtu.be/Rjrgz-lfcdQ -o 'The Birthday.mkv'
そして、CTRL+D とします。最後のファイル名は必ず変えてください。上書きされますからね。
以上で、12:50から4000秒ライブ配信をキャッシュします。タイムシフトでみることができると思います。観る際は、VLC、TOTEMなどが良いかもしれません。 以下でも構いませんが、当方環境では多少不具合がでます。
$  mpv ./tmp/cache.mkv
$  vlc ./tmp/cache.mkv
でもいいし、たいていのひとはマウスクリックでしょうね。

確認します。atコマンドに登録されているjobをリスト表示します。

$ atq
1 Sat Jul 28 12:50:00 2018 a your_name

これでもむつかしいとお嘆きの貴兄に

$ mpv  https://youtu.be/Rjrgz-lfcdQ -o 'The Birthday.mkv'

$ mpv  https://youtu.be/Rjrgz-lfcdQ -o ./tmp/cache.mkv

とPCの前で時間になったら手動で起動してください。そして、1時間ぐらいしたらCTRL+C で終了します。これなら誰でもできそうです。スマホでアラームを 設定しておくなり、人間が頑張るのです。1行だけですけどね。苦にならない人はこれでもだいじょうぶですが、PCは自動化して使うものかと存じます。
保存ファイルは場所を指定できますが、/tmpなどストレージ残り容量には注意です。
キャッシュされるライブ配信のサイズ、概算で1時間あたり2GiBです。

間違えて登録した場合

$ at -l    #登録ジョブリストを表示、番号がわかります。
$ at -d 2  #間違えて登録した、不要になったジョブを番号2で削除します。

あまり遅い環境では安定した動作は見込めない可能性があります。

  • 検証している暇はないですが、おおむねメモリーは8GBはあったほうがいい。当方の環境では1セッションあたり1GiBを超えてますから、もっとあったほうがいいかもしれません。16GiB搭載しているシステムです。
  • 保存するストレージ空きは、1時間2GB程度の生成と見積もると良いです。
なお、日曜日はこんなかんじの例です。

例::日曜日 Sunday 7/29 Channel 1

11:30 - King Gnu
at -t 201807291130
timeout 3600 mpv https://youtu.be/0hjO3bCxUgE -o 'King Gnu.mkv'
13:20 - Suchmos
at -t 201807291320
timeout 3600 mpv https://youtu.be/0hjO3bCxUgE -o Suchmos.mkv

トラブルシューティング

  • atでスケジュールしたら電源管理でPCが勝手に眠らないようにします。
  • Windows10+WSL でうまく行かない場合は、Linuxをインストールしてもいいかも。
  • MAC OS X でうまく行かない場合は、Linuxをインストールしてもいいかも。
当方の感覚では、カジュアルに3日間だけOS変えるってのもありです。
ubuntu18.04LTSが、今現在のオススメ。当方のmanjaroでは負荷が高いです。HW支援が効いてないのか、全般にCPUが全力で働いてしまってます。ubuntuではCPU負荷は低いままです。mpv.confで HWアクセルを有効にしています。
ふたつのLinuxのmpv設定ファイルはハードリンクなので全く同じです(あまりこういうことはしないと思いますが)。
バージョンはもちろん違います。gitも追ってみたのですがmanjaroでは負荷が高いままですから、今回は時間の都合 ubuntuで済ませます。mesa絡みかも。


キャッシュディレクトリでのファイル生成状況を監視するコマンド行 以下の($は不要)、端末に貼り付けてリターン。5秒毎にファイルが増えていればたぶん成功しているっぽいと思いましょう。
$ cd /tmp
$ while true; do ls -l *.mkv| perl -alnE'say "$F[4]  \t $F[8]" ' ; sleep 5s ; clear ; done

余談::「今々変数」を使う、またはシェルのコマンド展開

$ TODAY_IMAIMA=`date +%Y-%m%d_%H%M` #今々変数

$ echo $TODAY_IMA
2018-0728_0124

なので、

$ TODAY_IMAIMA=`date +%Y-%m%d_%H%M` #今々変数

と打っておいて、

$  mpv  https://youtu.be/Rjrgz-lfcdQ -o ./tmp/$TODAY_IMAIMA.mkv

とすると、その都度の「年月日時刻」.mkv になりますから、

$  mpv  https://youtu.be/Rjrgz-lfcdQ -o $(date +%Y-%m%d_%H%M).mkv

より安全を期するなら

$  mpv  https://youtu.be/Rjrgz-lfcdQ -o /tmp/アーティスト名_$(date +%Y-%m%d_%H%M).mkv

とするとファイル名の競合は1分以内に同じコマンドを発行しない限り起きません。問い合わせなしで上書きされますから、注意してくださいね。空白はクォートしてください。忘れないでください。同じキャッシュファイル名を指定するとまるっと消えますよ。
今回の場合でいけば、アーティスト名がわかっているので、既述のようにバンドなどの名前を指定しておけば大丈夫です。コンテナ名(この場合、拡張子)を付けるのは忘れないでください。とても大事です。


動作確認環境 ➡ manjaroに変更しました。


System: Host: manjaro Kernel: 4.14.57-1-MANJARO x86_64 bits: 64 gcc: 8.1.1

System:    Host: ubuntu Kernel: 4.17.10-041710-generic x86_64 bits: 64 gcc: 8.1.0
           Desktop: Cinnamon 3.8.7 (Gtk 3.22.30-1ubuntu1) Distro: Ubuntu 18.04.1 LTS
Machine:   Device: desktop Mobo: ASUSTeK model: ROG STRIX B350-F GAMING v: Rev X.0x serial: N/A
           UEFI: American Megatrends v: 4011 date: 04/19/2018
CPU:       8 core AMD Ryzen 7 1700 Eight-Core (-MT-MCP-) arch: Zen
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Tobago PRO [Radeon R7 360 / R9 360 OEM] bus-ID: 08:00.0
           

2セッションのリソース状況(びしばし食ってます)


プロセスの状況(片方はテストです)



キャッシュのVideo情報の例

カンタンにいうと当方の設定で、いわゆる H.264、コンテナMKVです。 FHDです。 早い話がこの動画コーデックに対応していない環境は事実上ありません。 標準です。Androidでも、iPhoneでも、なんでもOK。
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L6.2
Format settings                          : CABAC / 4 Ref Frames
Codec ID                                 : V_MPEG4/ISO/AVC
Bit rate                                 : 5 305 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Stream size                              : 591 MiB (96%)

所要コマンド:: ubuntu でうまくないので、manjaroに戻しました。

※ubuntu系18.04LTSは、atコマンドが標準では導入されていません。 次のコマンドを発行してください。arch系Manjaroは標準で導入済みかと思います。もし不足していれば導入してください。manjaroも素に近いインストールで試してみたところ、atコマンドは追加導入ですね。pamac でatと検索、追加コミットしてください。そしてデーモン起動です。systemctl start atd

ubuntu系になぜか親切なメモ

#入ってなければ、at mpv youtube-dl をインストールします。導入済みなら何も起きませんので発行しても問題はありません。

$ sudo apt install at mpv youtube-dl


ファイル名の最大長を求める。UTF-8におけるNTFSとEXT4の運用 ちょっぴりZFS

ファイルシステムの限界を探る::
ファイル名長のバイト数を求める。

4年位まえに書いて公開するのを忘れていました。NTFSとEXT4で長い長いファイル名をどう扱っていけばいいのか?! についての調査研究です。

●ファイルシステム NTFS/EXT4でのファイル名最大数を実際に試して計測した。
●EXT4が意外に少ない結果になった。NTFSの勝ち?! 留意すべき事項。
●ファイル名長大化推進委員会としては由々しきこと。

ファイル名バイト数を求める呪文/Perl OneLiner

$ ls | perl -pe '{ chomp $_ ; my $FILELENGTH=(length) ; print "\n$FILELENGTH\t" }' | sort -n


$ ls | perl -wnE '{ chomp  ; my $FILELENGTH=(length) ; say "\n$FILELENGTH\t$_" }' | sort -n


適当なディレクトリで実行するとバイト数でソートされた結果が出力されます。

たとえば、以下1行を端末にコピペ。

$ cd ; ls | perl -pe '{ chomp ; my $FILELENGTH=(length) ; print "\n$FILELENGTH\t" }' | sort -n

6 公開
9 ビデオ
12 ピクチャ
18 ダウンロード
18 テンプレート
18 デスクトップ
18 ドキュメント
18 ミュージック

インストール直後のubuntu系ホームディレクトリは日本語ディレクトリなので、このようにカウントされます。ロケール LANG=ja_JP.UTF-8 が基本的にどのディストリビューションでもデフォルトの時代ですからね。とりあえずはそれに合わせると。

UTF-8ではワイドキャラクターは3バイト(大半)ですので、日本語文字列が入っている場合でもこれで正解です。いわゆる「全角2文字はx3で、6バイト」です。

但し、ほとんどの人は使いませんが日本人が使う可能性のある文字は4バイトのものもありますので、単純に勘では計算できません。だいたいx3で目安にはなります。追加文字は4バイト以上に割り当てられているというわけです。そこを記憶しておくと暗算できるようになります。(誰がするか)

バイト値で返ってくるのはいろいろと便利です。但し、原稿用紙換算の制限のある文書ではShift_JISの考え方で「文字数カウント」しないと経済社会に対応できませんのでご注意を。縦書き原稿と横書きでは組版の考え方も違いますからね。

無駄な検証::
相互運用を考慮すれば85文字以内に収めるように習慣づける。


さて、ベタに検証してみました::常に数えるわけではないし、ながければ怒られますが、スクリプトなどで処理する場合は注意です。

fuse経由NTFSは、どんな文字(アスキー領域でも、日本語でも)でも255文字分のファイルが作成できます。バイト値で755です。(RAW OSを絡めていえば「最近のWindowsでは」と条件付きになるようです。サポート切れXPなどは関係ないのでどうでもいいです)

以下のファイルはNTFSに作成できます。限界の765バイトにチャレンジしてみました。(三木清先生、青空文庫)すばらしい論考です。ぜひどうぞ。

touch してみるとすぐにわかります。仕様を超えた場合は、怒られますから。

哲學はどう學んでゆくかといふ問は、私のしばしば出會ふ問である。今またここに同じ題が私に與へられた。然るにこの問に答へることは容易ではないのである。これがもし數學や自然科學の場合であるなら、どういふものから入り、どういふ本を、どういふ順序で勉強してゆくべきかを示すことは、或ひはそんなに困難ではないかも知れない。それが哲學においては殆ど不可能に近いところに、哲學の特色があるともいへるであらう。哲學は何であるかの定義さへ、立場によつて異つてゐる。立場の異るに從つて、入口も異る筈である。しかも哲學的知識には、端初

EXT4では以下の例で限界近くになります。253バイトにしかなりませんでした。(夏目漱石、草枕、青空文庫)ちなみに私はこの「草枕」が大好きなんです。

住みにくき世から、住みにくき煩わずらいを引き抜いて、ありがたい世界をまのあたりに写すのが詩である、画えである。あるは音楽と彫刻である。こまかに云いえば写さないでもよい.txt

EXT4では、英数字なら255文字のファイルが作成できますが、「日本語」では不可能です=中国語も同じです。カナダ先住民族文字も不可能ですし、シュメール楔形文字もだめでした。めんどくさいのでファイル名は85文字以内と考えておくのが得策です。85x3は255です。安全な範囲が85文字です。ZFSでも同じようですが現在は仕様拡大したかもしれません。

ですから、バイト数で250以上を危険水域としてファイル名長をチェックしたほうがいいかもしれません。少なくともGnomeでは255バイトぎりぎりのファイルはゴミ箱には入れられません(なんてこったい!!)。拡張子付加とかそれ以上できないためなのかもしれません。リネームは促されません。端末で地味に作業しましょう。

※おまけ、または結論


NTFS上に作成した長大な名前のファイルは、仮想マシン(Windows)では見えませんでした。もちろんWineでは見えています。ファイル名長大化推進委員会の私としては、Linux EXT4の日本語で扱える文字数の少なさにがっかりです。笑)

一律に閾値255バイトで制限したほうがいいのでしょうね。ファイルシステムをまたがる場合、異機種間ネットワークを組む場合、可搬性を考慮した場合など。あー、コンピュータってめんどくさい。

追試::2018年7月24日、同じ結果でした。85文字以内にしないとうまくないのでしょう。

touch: `アル・ジャロウ,ウィリー・ネルソン,ウェイロン・ジェニングス,キム・カーンズ,クインシー・ジョーンズ(プロデューサー及び指揮),ケニー・ロギンス,ケニー・ロジャース,ジェフリー・オズボーン,ジェームス・イングラム,ジャッキー・ジャクソン,シンディ・ローパー,シーラ・E,スティーヴィー・ワンダー,スティーブ・ペリー,スモーキー・ロビンソン,ダイアナ・ロス,ダリル・ホール&ジョン・オーツ,ダン・エイクロイド,ディオンヌ・ワーウィック,ティト・ジャクソン,ティナ・ターナー,ハリー・ベラフォンテ,ヒューイ・ルイス&ザ・ニュース,ビリー・ジョエル,ブルース・スプリングスティーン,ベット・ミドラー,ポインター・シスターズ,ボブ・ゲルドフ,ボブ・ディラン,ポール・サイモン,マイケル・ジャクソン,マーロン・ジャクソン,ライオネル・リッチー,ラトーヤ・ジャクソン,ランディ・ジャクソン,リンジー・バッキンガム,レイ・チャールズ' に touch できません: ファイル名が長すぎます

なので、~/Music/アルバム名/演者/We Are The World.flac の演者の部分がつくれません。いや、作んなくていいから。^^; U.S.A. For Africa でいいんです。

コーラスなどの楽曲で演者を編集、全参加アーティストを列記するという野望が潰えた瞬間です。

Linux音楽プレイヤーを比較。 楽曲管理と手軽な再生と。2020夏改訂

Linux音楽プレイヤー比較 楽曲管理視点と再生と。

2020夏の気分、評価としては、DeaDBeefLollypopがお気に入り

あらたに、DeaDBeefLollypopを追加しました。

音楽プレイヤーというよりも、マルチメディアプレイヤーという方が適切かもしれません。youtube music などをみても、単独の楽曲とMusic Video の垣根がなくなってきています。無理にわけるほうがおかしな時代なのかもしれません。

いろいろな角度から、再生が使いやすいという観点だけではなく、楽曲管理ツールとしてどうなのだろうか?! という観点でも検討したものです。どれかひとつに絞る必要はありません。シーンに応じてお好きなものを選べば良いと思います。

シーンに応じてお好きなものを選べば良いのです。私の好みですね。高頻度、低頻度は投稿時点で今はおおきく変わっています。

  • すんごく大きな楽曲ライブラリを扱いつつ、好みを検索しながら、みたいな使い方➡lollypop
  • 瞬間、あれ聴いてみよなら。ターミナルから起動するのが好みなら                    ➡mpv
  • 音質重視なら。またわりと決まったアルバムをヘビーに聴くタイプなら               ➡deadbeef 

Linux 主な音楽プレイヤー比較、評価。偏見含む。2020年改訂

プレイヤー名称 評点 好感ポイント ケース Cue
mpv 95 軽い。高機能。 さくっと再生。コマンドラインからさっと再生、さっと終了。なんでもできるかも。再生エンジンそのもの。Terminal で一日過ごす人も、マウスで操作する人にもシンプルさで応えます。 OK
audacious 80 軽い。地味。 クリックして再生。デフォルトに設定してもいい。JACK設定で初見者が悩むところがほぼ皆無になった。 OK
DeaDbeef 90 簡潔で素敵 JACKと相性よし。音質重視派向け。 OK
Lollypop 85 現代的 現在評価中。日本語翻訳しましたので悩むところが少ないと思います。
再生に割り切ると素敵。発展途上。
NA
celluloid 70 軽い mpvのノウハウがあれば活かせる。今後急成長しそうな気配もある。動画も楽曲もひとつでいいやという方には向いている。mpv のフロントエンドなのでフロントエンドを選ぶという観点です。 OK
以下、自分の圏外の一部
VLC audio CD Player 50 それなり それなり。ほんとそれなり。 NA
Rythmbox
banshee
50 特になし 総合的だが好みに左右されるかも。好きではない。過去のヒーロー。 NA
クレメンタイン
開発停止か
20 見通しがよい ライブラリ単位で再生などよかった点もあった。管理も任せる。現在、起動しない。インストールはできる。 OK

DeaDbeefLollypop おきにいりかも 

DeaDbeefLollypopの起動頻度が当方では多くなってきています。
また、mpvのフロントエンドであるcelluloid(gnome mpvの後継)も使うときがありますが、mpv をほぼ満足のいくところまでカスタマイズしたので、mpv のUXでことたりてます。
celluloidは、ここ2年ほどグイグイきたアプリケーションです。mpv で再生できるものは動画でもなんでも再生しますから、マルチメディアプレイヤーですね。
当方の場合、拡張子別ではロスレス形式のflac は mpv に関連づけています。
3年前と比べて。現在とはかなり違いますね。単発の場合 mpv も多いです。むしろ mpv が自分の中では標準かもしれません。

インストール全般


いずれもほぼ標準ですから、インストールはデフォルトのリポジトリからの導入がよいでしょう。

ArchLinux系も GUI/ pamac で検索してインストールできます。ターミナルでももちろん導入できます。

※その他の音楽プレイヤーもありますが、当方の環境で起動すらしないものは除外されています。Linuxの音楽プレイヤーは「ぜんぶ」使ってきました。

以下過去のスタンスを含む記事ですが、いまでもだいたい同じかと。

Linux音楽プレイヤーについて考察

WINEで、有名アプリを動かしたいですか

WINEでiTunesはバージョンも古い上、実用に耐えません。せめてVitualboxでしょうね。それでも何をしたところでオーバーヘッドはあるわけです。WineでWindowsアプリケーションを再生用に使うのはばかげています。もうね、意味はないと思われるのです。

VirtualBoxでお気にいりのWindowsアプリケーションはどうですか

仮想的な環境では「だめ」。そう思っていたのは過去のこと。だめと思っていたのは、VirtualBox5.x まで。どういうわけか、6.1系では実用に耐える気がします。BGMなら問題まったくない。Virtualboxでもだめです。いや使えるし悪くはないのです。カジュアルに流しっぱなし用途などには素敵だと思います。

楽曲管理と再生は別として考えると新しい活用視点が見えてくる

管理(リッピングやタグ付け、アルバムアート管理等)と再生は別物なので、そこはわけて考えてよいかと思います。最近だと、購入や取り込みと管理と再生って区切ってもいいかもしれません。楽曲ファイルへの埋め込みアートワークを好みに変えたり、歌詞を埋め込んだり、タグを付け直したり、そういうのがここでいう楽曲管理です。

CDDBにもこだわる

さらに凝っていくなら、楽曲毎にアートワークを変えるとか、gracenoteを参照して、ファイル化された名称は一部気にいらないのでぜんぶ付け替えたいとか (ファイルリネーム)など管理作業は、(本末転倒という意味では)やまほどあります。笑)  CDDBの違いも大きいですよね。ビリー・ジョエルのアルバムはアルファベットでタグ付けしたいとか。※最近は日本語アーティスト名のほうが良い気がしてきました。

慣れでアプリを決めるのは海馬の萎縮かも

全体には再生に関していえば、好みを除外すれば Nativeアプリで十分ではないかなと思います。音質重視の人はNativeを使うべきでしょう。いくらWindowsで好きなアプリでも、Wineでもありえないです。音質重視の人はです。

実際、遅延計測もしてみましたがBGMでは使えても鑑賞には無理があります。気にならない方もいると思うのですが、楽曲再生に関してはNativeアプリで使ってみてください。仮想環境+JACKについての当方の意見でした。JACKまで導入する人のにもったいないです。せっかくなのでがんばりましょう。

Windows礼賛――隣の芝生問題

欲をいえば、Linuxにも Windows10の(もう使ってませんが)MusicBee並の管理と再生ソフトウェアがあれば\(^o^)/ですね。
Windows環境では、MusicBeeが最強じゃないかと思っていました。ほとんど iTunesを凌駕しているといっても過言ではないのではないかな、と。私の好みは、ディスコンになってしまったSONY MediaGO なのですが。悲しい。

Windows10はめったに起動しないので恩恵に預かれませんが。そういえば、MusicBee(Windows)はインターフェイスを変える検討をはじめた模様ですね。どうなるんだろう。ほぼひとりで開発している様子なので、すごいなぁ、です。(このパラグフフは数年前に書いたものです。現在まったく使っていませんので、当時の作者からの情報です)

オススメリンク/EACのLinux活用をまとめました。たぶんとても丁寧に。Windowsユーザーも参考になるかと思います。

可逆圧縮完全マニュアル(への道) カバー率99.6%レベルで、FLACからTAK、APEまで様々な可逆圧縮フォーマットの取扱についてまとめました。OS問わず参考にしていただけると思います。2020年のいまとなってはflac が標準。ape が少し。それ以上に、DSD がマニア向けになってきていますね。
EACやそのケーススタディ(1) EACの実際とWindowsとの共存、文字コードの解決 
  • 数年前に書いた原稿です。公開するのを忘れておりましたので、音楽再生アプリケーションの注目株の2アプリ追加して加筆。

MusicBee は良いのは確か。エミュレートはどこまで行ってもエミュレート。しっかしMusicBeeがここまで素晴らしく化けるとは思ってもなかったですね。すばらしいアプリケーションですよね

図は、VirtualBox6.1です。なお、WINEでもまともでないけれど動作しました。バギーですね。使えればいいという方向け。BGMオンリーでもWINEでは厳しいかな。いいかんじな人もいるようですから、トライしてみればどうでしょうか。

MusicBeeをWINEに導入したい人は、次の
 ガイド  がとても参考になります。いや、これを見ないと私も無理ですし、一般人は導入できません。https://getmusicbee.com/forum/index.php?topic=30205.0


余談::タグの問題

――個人的には、アプリ名はあげませんが、文字化けするソフトウェアは日本語ユーザーには時間の無駄です。とさえ思います。
TAGも直しましたがちゃんと読み取れないのは現状の仕様(利用者像の設定)だと思います。Latinな世界の人中心の開発なので仕方ないですね。2.4でUTF-8で書き込んで、古い機材(昔のwalkmanなど)のことは忘れてしまうってのがいいかもしれません。
結局、過去との互換性を考えるからいろいろ不都合も生じるわけでして。過去の機材に縛られる本人責任もあります。古いバージョンのID3タグは削除する派です。

ちなみにライブラリはCDから取り込みで、FLACにしています。基本的にはgracenoteです。

オススメ関連記事

ハイレゾや自分の耳性能に興味のある方向け>>僕の耳に棲まう妖精。可聴音の限界 幽霊音、幻聴、可聴音、または、僕の耳に棲まう妖精 もぜひどうぞ。ずっと非公開にしてきた記事です。

The backup GPT table is corrupt, but the primary appears OK, so that will be used.

"The backup GPT table is corrupt, but the primary appears OK, so that will be used."

自分向け再現とメモ

新規にターミナル(端末)を開きます。ubuntu系は以下を同時押し。CTRL+ALT+T

sudo gparted /dev/sdd

sudo gparted /dev/sdd
======================
libparted : 3.2
======================
The backup GPT table is corrupt, but the primary appears OK, so that will be used.

パーテーションの名前/partition
今まで           TOSHIBA_etcs
書き換えた。   TOSHIBA_E

結果エラーが収まった。 

この現象のメカニズム

GPTになって、ディスクはテーブルの予備を持つようになった。
TABLEが壊れていてもどちらかのTABLEから読み出すため、動作する。

ユーザーが名前を変更するなどディスク操作を行えば、
壊れたテーブル(The backup GPT table)が正常に更新される。

よって、ディスクは正常になった。めでたいことである。

という次第です。

パーセントエンコードをさくっと処理 percentencode URI_Encode

さくっと、パーセントエンコード percentencode 3分クッキング 🐪

「はたらく細胞」がいまマイブームです。コミック原作のアニメです。AmazonVideoでも配信されていますね。さて、Perlコマンドですからほとんどの環境(MACとLinux)では事実上標準ではいっています。
貼り付けるだけ。すぐにそのまま使えます。Windows 10でLinuxを利用できるWSL(Windows Subsystem for Linux)のユーザが増えてきたと仮定すると同じくそのまま使えます。

●🐪モジュールは、https://metacpan.org/pod/URI::Escape 標準モジュールです。インストール不要です。入ってます。
●あまりにカンタンすぎるのでWEB上サービスはありますが、ローカルで処理できるとシェルスクリプトをはじめとするプログラムに組み込めるので便利かと思います。
●定義(RFC 3986)されるまでは用語が確立されていなかったので、先行したこのモジュールではURIエスケープと呼んでいるみたいですね。

はたらく細胞  ⇄  %E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E

%エンコード(percentencode)は16進ですからふつうの人間には読めない並びになります。空白なら覚えていますが。人間には全部おぼえるのは通常無理かと。

新規端末 CTRL+ALT+T

OneLiner で文字列を埋め込む

$ perl -MURI::Escape -E 'say uri_escape("はたらく細胞");'Enter
%E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E

OneLiner で文字列を引数の配列@ARGVで

$ perl -MURI::Escape -E 'say uri_escape("@ARGV");' "はたらく細胞"Enter
%E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E

OneLiner で文字列を引数の番号$ARGV[0]で。コマンド置換の例

$ perl -MURI::Escape -E 'say uri_escape($ARGV[0]);' "はたらく細胞"Enter
%E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E



シェルでコマンド置換する例です。
1) 変数 hatarakusaibou に格納。
2) そして変数が有効になっているか調べる。

$ hatarakusaibou=$(perl -MURI::Escape -E 'say uri_escape("@ARGV");' はたらく細胞)Enter

$ echo $hatarakusaibouEn ter

%E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E

上の結果と一致しているのでOK。




引数を「+」で連続させる文字列を一発で取得するには

$ perl -MURI::Escape -E '$escape=uri_escape("@ARGV"); $escape =~ s/%20/+/g ;say $escape' はたらく細胞 公式 アニメEnter

%E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E+%E5%85%AC%E5%BC%8F+%E3%82%A2%E3%83%8B%E3%83%A1


完成かなと思います。bash関数にするなり、バッチファイルにするなりしておくと便利かも。bash履歴から呼び出すってのも王道のひとつです。

以上の雛型があれば、スクリプトにするのは容易です。というか動いていればそれで完成なので、以上で、既にできていますね。
  • Python3 + BeautifulSoap さんで、グーグル様にちょっと投げてみる時などに使えますし、そもそもPythonなのだから標準ライブラリで処理せよという話。
  • [Python3] 
    percentencode=urllib.parse.quote('はたらく細胞') ⬅ これでも解決します。
  • -E で、say を使っています(改行が自動でつくと困る場合はprintでどうぞ)。
  • 標準モジュールURI::ESCAPEをワンライナーでも使えるように組み込む。
    -MURI::Escape 
uri_escape_utf8($ string)という使い方のほうが、UTF-8を扱う場合はよいのかもしれません。特に長い文字列を扱う場合。

OneLiner 上記のリバース(戻し方)

$ perl -MURI::Escape -E '$unescape=uri_unescape("@ARGV"); ;say $unescape' %E3%81%AF%E3%81%9F%E3%82%89%E3%81%8F%E7%B4%B0%E8%83%9E+%E5%85%AC%E5%BC%8F+%E3%82%A2%E3%83%8B%E3%83%A1
はたらく細胞+公式+アニメ ⬅戻りました。

bash 関数に組み込む:: たとえば .bashrcなどの末尾に貼り付け(これだけもっていけばだいじょうぶ!!) 

function URIESCAPE () {
  #引数を「+」で連続させる文字列取得
  perl -MURI::Escape -E '$escape=uri_escape("@ARGV"); $escape =~ s/%20/+/g ;say $escape' $@
}


その後は、次のコマンドで呼び出せるようになります。source .bashrc や .bash関数定義をまとめたファイル。わからない場合は、再起動すればいいです。


そうすると、次のように呼び出せば、便利になるかと思います。


$ URIESCAPE はたらく細胞 

こうして出力された文字列をコピーして使います。背後で誰がはたらいていようが、それがPerlだろうが、AWKだろうが、使う側からみれば関係ないですよね。「はたらく細胞」の世界と同じで、白血球の働きを知らなくても、私たちは生きていけるのです。がんばれ、血小板のナンバー2。