【Bash】Windows Subsystem for Linux【WSL】8

ついにWSL2が登場したぜー。こりゃ完全にLinuxだ。ヒャッハー！WSL最高！開発にLinuxは使わねぇー。Windowsで開発してLinuxは動かすだけや！

WSL2アーキテクチャ
https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html

WSL 2では、仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。
このため、コマンドプロンプトなどからwsl.exeなどを使ってbashコマンドを処理する時間は、
現在のWSL 1とほとんど変わらない。また、本物のLinux実行環境であるため、
これまで正しく動作できなかったアプリケーション、例えばコンテナシステム（Dockerなど）や
ユーザーファイルシステム（FUSEなど）も動作させることができる。その上で、現在のWSL 1と同等の機能と使い勝手を実現するという。

WSL 2はWSL 1を置き換えずに併存する
　WSL 2が登場したからといって、WSL 1は廃止になるわけではなく、引き続き利用可能である。

ファイル共有プロトコル「9P」でWSL 1との互換性を確保
　このように、WSL 2とWin32環境の間のファイル共有は、どちらも9Pを使うことになる。
　また、WSLからWin32プログラムを起動する「Win32相互運用性」では、最初にWSL側で、
実行ファイルを判別する必要がある。具体的には、実行ファイル先頭のマジックナンバー
（Win32ではMZ）を見て、LinuxのELF64か、Win32の実行ファイルなのかを判断する。

【Bash】Windows Subsystem for Linux【WSL】7
https://mao.5ch.net/test/read.cgi/linux/1579395785/

画面のコントラストを下げる

まあWSLではなく、ターミナル(エミュレータ)の設定の問題だよね。
ここで聞かれても…

プロンプトの色変更はターミナル側の設定だけど
lsでディレクトリが青文字になってしまう問題はカラーテーマ変えてもしんどいからwsl側で設定したほうがいい
https://www.kwbtblog.com/entry/2019/04/27/023411

表示に関わらず一律に単色表示にしたい、という要望なのだから
プロンプトや各コマンドの表示設定ではなくターミナルエミュレータの設定だろう
WSLは関係ないし、ここで聴くことでもない。このようにピンボケした第三者がノコノコ現れるのも迷惑だ。

漏れは、Ubuntu 18.04 で、
ColorTool.exe で、Windows の色を変えているけど、
WSL が暗いので明るくしたら、PowerShell で明るすぎて見えない

例えば、コマンド入力時に、色を付けない事はできる
la -p --color=never

~/.bashrc の83行目移行で、色を付けている
alias ls='ls --color=auto'
alias grep='grep --color=auto'

test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

とあるから、~/.dircolors が読み取り可能なら、
そのファイルをdircolors コマンドで処理すると読めるから、
~/.dircolors で設定できるのかも

>>228
のサイトでは、ColorToolのバイナリ配布がなくなったと書いてあるけど、
下に、ColorTool.zip がある
https://github.com/microsoft/terminal/releases/tag/1904.29002

WSLでターミナルの文字色を変える(2019/8/10版)
https://qiita.com/ligun/items/0a63660e1d8b486232d9

漏れが試した中では、これがマシだけど、まだ見にくい
ColorTool.exe -d deuteranopia.itermcolors

コマンド画面の色はautoexec.batで指定するんだよ
config.sysでちみとにるとんと読ませるのも忘れずにな

色を付けない、la, ll のalias を、
~/.bashrc か、~/.bash_aliases に定義するのが簡単

alias lan='la -p --color=never'
alias lln='ll -p --color=never'

ただ、~/.bashrc では、grep などにも色を付けているけど

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

漏れは、Ubuntu 18.04 で、
ColorTool.exe で、Windows の色を変えているけど、

WSL が暗いので明るくしたら、
今度はVSCode で、PowerShell を起動したら、明るすぎて見えない

これらを両立させるのが難しいので、
色を付けない、--color=never の、la, ll のalias を定義している

gimpインストールしてgimp開いたと思ったとたんXサーバーが落ちた
何かとか弱いんだな

WSLって結局何に使ってる？
pythonもgitもWin側に入れてるから使いみちがないわ

>>225
\ls

ctags

>>236
emacs

>>236
究極的にはWindowsでLinuxと同じ環境ができてしまったら
WSLが必要ないのは当たり前

問題は同じ環境を作る手間
例えばPythonを複数のバージョンインストールして
切り替えたいと思ったらどうするかね？

そういう仕組みを作れば出来る。
その仕組みを作るまでが大変。
WSLは既存のLinuxの仕組みをそのまま使える

てすと

>>236
僕もemacs

あと、clojureでの開発・キーボードのファームウェアのビルド
pythonの開発も何かとlinuxの方がやりやすかったり

>>236
w3m, vim, less, sed, awk, zip, translate-shell, html2text, wget, zsh, tmux, ssh, gsl, gmp, gprof, make, GNU R, Julia, GNU coreutils

>>234
わざわざそこまでするなら別のターミナル使えばいいのに

日本語辞書mecab-ipadic-neologdをMecab用から検索エンジンlucene用に変換するのにWSLを使ってる。
https://github.com/neologd/mecab-ipadic-neologd

おれはlynxをファイルエクスプローラとして使いファイルを書いたり変更したりしてる
lynxにemacsを設定してるから使い易い

>>236
漏れは、自分のPC 内のWindows 10, WSL, Ubuntu 18.04 で、
VSCode の拡張機能、Remote WSL を使って、
Linux側に、プロジェクトを作っている

Windows側からのブラウザアクセスは、
VSCodeの拡張機能・open in browser ではローカルファイルアクセスとなるので制限されるが、
VSCodeの拡張機能・Live Server では、サーバーを立ててのアクセスとなるので制限されない

Linux側には、日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv を使って、
ruby 2.6.6, node 12.16.2 を入れた

yarn は、Windows側に入れて、WSL から、拡張子なしのyarn コマンドを呼べる。
これは、#!/bin/sh で始まるシェルスクリプト

anyenv は多言語向きで、rbenv, nodenv, pyenv, phpenv などを同じ使い方で、統一的に扱える。
同様のツールに、asdf もある

>>225
WindowsストアからWindowsターミナルをインストールしてWSL使うといいよ

>>236だけど遅くなったサンクス
個人的には.batを完全にシェルスクリプトで代替できるようになったら楽なんだが無理なのかな
バッチファイルは書き辛い

>>249
普通にできると思うが？

>>249
簡単に出来るじゃん

簡単ではないでしょ。
バッチファイルをシェルスクリプトに置き換えるプログラミング技術が必要になる。
バッチとシェルでは引数展開の仕様やシングルクォート・ダブルクォートの解釈も違う。

bashとzshでさえ引数展開で違うところがあって困ることがある。
シェルスクリプトで頑張るをあきらめてPython使うのが無難だとは思う。
PerlもGit for Windowsに標準で付属されているので悪くない選択肢だけど、
プログラミング言語初心者に保守してもらうのを想定するならPythonかねぇ。

シェルスクリプトはshで動作するコマンドのみで書くべき、というのは大前提だが
Linuxが蔓延して、shの実体なんてどうせbashなんだからスクリプトなんてもうbash基準でいいじゃん…てなってしまったのが現実ではある
…が、zsh依存とか自前でゴチャゴチャ書くだけなら勝手にすればいいが、外に出したら叩かれるわ。悩む要素ないだろ

>>252
シェルスクリプトは引数展開の仕様がバッチファイルよりもわかりやすい

バッチファイルで空白が入るパスを扱おうと思ったら
とんでもないコードが必要になる

>>253
Pythonに限らないがシェルスクリプト以外だと
コマンドの入力を受け取るのが大変
シェルスクリプトだとプロセスを複製して
パイプの入力と出力を並列で動かすことが出来るが
Pythonなどでは難しい

>>254
> Linuxが蔓延して、shの実体なんてどうせbashなんだから
UbuntuとDebianでLinuxのシェアの半分以上を締めてる
つまりshの実態はbashではない

釣り大会でもやってんのか

先生、獲物が絶滅危惧種のようです

ここでいうshは、Bourne Shellのことなんだろ。
bashはオープンソースな上位互換シェル

釣りなら fish でしょ。

>>259
うまいねえ〜

fish とは上手いけど、本当は dash だろ。

長いことzsh使ってきたけどfishの素晴らしさを知って完全に乗り換えたわ。
bashはスクリプト用にしか使わない。

dashを知らない人がいるのかｗ
今どき/bin/shがbashって頭わいとんのかｗ

>>258
Bourne Shellなんてもう生き残ってないよ
Solaris8？ぐらいが最後やろ

dash dash dash
fish and bash

そんときーおーれがー
Super Heroさ

略してSH
H ero

H x EROS

オープニングの最後に出てくるドクロみてえな奇怪な物体にいつもビビってたわ

Linuxが蔓延して、shの実体はPOSIX準拠に近いdashになってしまったな
bashこれからどうなるの？

>>255
subprocess使え
シェルスクリプトに比べれば面倒だけど難しいと言う程ではない

>>269
俺もミイラの頭蓋骨だと思ってたw

シェルスクリプトの代わりは、可読性が高い、Ruby

>>271
難しいかどうかの話はしてないよ

シェルスクリプトには「得意なこと」があって
その「得意なこと」は他の言語よりもシンプルに書ける
という事実があるってことだよ

シェルスクリプトは低機能な言語じゃなくて
特定の用途に特化した言語だってこと
その特定の用途を他の言語でやると面倒になる

だからシェルスクリプトの代わりになる言語なんて無いよ

腰を据えてやりたいときは、今はほとんどpythonだけど、
ちょっとしたことをしたいときに、いちいちモジュールのインポートをしなければならないのは面倒くさい
普段使ってるコマンドをそのまま呼び出せるのは、シェルで解釈する系のスクリプト（バッチファイル含む）のいいところ
ワンライナーの簡単なperlは、呼び出されるコマンドの一つになってる

まぁ、おそらくこのスレの住人はだいたい同じように考えてるとは思うけど

>>275
同意。
適当にシェルスクリプトで作って、シェルスクリプトだと面倒な所はperlとかで。パフォーマンスとか考える必要がない場合なら十分だと思ってる。

バイナリー扱うんじゃなければ、awkで十分

シェルスクリプトでしのごうとする癖を改めて、最初からPython,Perl,Rubyで書く習慣をつけたほうがいい。

>>278
何で？

>>279
シェルスクリプトよりも機能追加しやすい。
シェルスクリプトよりもコンパイル言語(C、Java、C#等)に移植しやすい。

WSH

そんなことするなら、GoとかRustの方がいいんじゃね？

>>278
質問に答えよ

シェルスクリプトからPython,Perl,Rubyへ移植するのは簡単か否か


簡単ならシェルスクリプトで書けばいいし
難しいならなんでそんな難しいことするんだよって話になる

>>281
JScriptで書いたものがNode.jsでそのまま（ないし少しの修正）動かせるなら、
WSHを使うのも吝かではない

シェルスクリプトは機能追加しにくいってのは意味不明だけど、何を使って実装するかは、対象によって変えるのが普通で、シェルで作った物をコンパイル言語で書き換えることになったりしないよ

>>280
先人の知恵を使う方が速いし楽だ。先ずはcoreutilsとsed,awkで。それでできなかったら、pythonでもjuliaでも好きなの使えばよろし

シェルスクリプトの複雑怪奇なワンライナーとかじゃなくて
2〜3個コマンドつなげただけの単純なワンライナーでも
それを他の言語にするとバグあるんじゃねーかこれ？レベルの
テストが必要なコードになるからね

シェルスクリプトで書くと後で他の言語に書き直したくなるっていうのは
そもそも最初にシェルスクリプトを選んだのが間違いってだけ

LLで書くまでもないと思ってシェルスクリプトで書いてもあとからやっぱりLLにしておけばよかったてのはよくある

そういうのはそもそもシェルスクリプトで書くべきではなかっただけ
なぜ用途で使う言語を選ぶことができないのか？

つ「馬鹿の一つ覚え」

つ「一知半解」

結局どっちで書くべきだったのかは実際書いてみないとわからない時もある
一見コマンドの組み合わせで何とかなりそうに見えたからシェルスクリプトで組んでみたものの思いの外処理が複雑でawk,sedでは辛かったり

(以前そういう処理書いてたときは複雑な部分だけpythonで書いて
シェルスクリプト内でpythonをパイプで挟んだ)

> の思いの外処理が複雑でawk,sedでは辛かったり

？

awkは行と列単位の処理
sedは行単位の置換

変にGNUの拡張使うのがいかんのやろ
できるからやるんじゃなくて、それぞれのコマンドに適した問題を
そのコマンドでやればいいだけだよ。適してるかなんてすぐわかるじゃん。
問題が適していないとわかった時点で、別の方法を使えばいい。

それにさ、awkやsedでつらいっていうけど、それシェルスクリプトじゃないから。
awkがつらい、sedがつらい。ならあんたが言うように
awkやsedの部分だけをpythonに置き換えればいいだけ

それはawkやsedを置き換えてるのであって、シェルスクリプトを置き換えてはいない

<<を使えば良いのに

sedが辛ければ、普通はperlを使うだろ

素直に最初からperlで組んどけばよかったんじゃ

つまりsedじゃなくてperlを使うという話で
シェルスクリプトとは関係ないわけだ

perlがこの先生きのこるうえでシェルスクリプトっぽく見えるperlの言語仕様が長所になるかもね。

Perlで foo | bar | baz と同じことをするものを作る場合どうするの？

echo HOGE | perl -pe "s/O/A/"
とやればOをAに置換できる

>>299

単に実行するだけなら
system("foo | bar | baz");
ただしsystem()は標準出力される文字列を再利用やリダイレクトできない。

出力結果を変数$hogeに格納するなら
my $hoge = `foo | bar | baz`;


出力を一行ずつ処理したいなどの要求があるなら、素直にパイプ処理のコードを書く必要がある。

>>300
"文字列"ではなく"文字"の一対一の置換、及び削除は tr コマンドを使うか、Perlを使いたいのなら
s 演算子ではなく tr 演算子を使えば、(原理的に)速い。

この板に来る奴の多くはシェルスクリプトしか(それも少しだけしか)できなくて他に選択の余地ない奴が多いだろ

>>302
それはsedやawkじゃあかんのか？

>>303
そういうやつがわざわざここに来るとは思えんけどなぁ...

>>304
基本的にはsedではperlで使う（といっても、もう一般的な）正規表現の記法が使えない
\w、\dあたりは使えたほうが便利

>>305
この板に来る奴の多くは一般的なプログラムをつくらないだろ
(作るのは簡単なシェルスクリプト)
そんな奴は、Ruby、Python、Perlのような言語を学ぶなんてしない

簡単だからこそ、用途に応じて使い分けるということは理解できないかな？

fzf などのインクリメンタルサーチで選択した文字列をそのまま端末の出力バッファに送り込みたい場合、bash環境ではPerlが使われる。
以下に端末の出力バッファに文字列を送る例を示す。0x5412は、bash環境におけるTIOCSTIの実値。

$ perl -e 'ioctl STDOUT, 0x5412, $_ for split //, do{ "echo hello\necho world\necho foobar" };'

訂正。
0x5412は、Linux環境におけるTIOCSTIの実値。

決まった処理させるのにコマンド羅列で済むから最初はbatにするんだけど
扱う対象が増えたりで少し便利にしたいと思ったら途端に面倒になるので
Perlに組み込むなんてことは普通によくある

Ubuntuの初心者ですが
皆さんはデスクトップは何を使用しているのでしょうか
良かったらお勧めのデスクトップを教えてください

Xfce4 というか Xubuntu
インストール後 Japanese team の追加パッケージをインストール
http://ubuntulinux.jp/japanese

書き込んでから気づいたがWSLスレだった。すまん

可読性の高い、Ruby が確実。
漏れは、パッケージの更新も、Ruby スクリプトでやってる

#!/usr/bin/env ruby

# sudo のパスワードを自動入力する
puts `echo パスワード | sudo -S apt-get update`

puts `sudo apt-get upgrade -yV`

パスワードをファイルにベタ書きしたらだめでしょ。
visudo でパスワードなし実行するユーザとコマンドを設定したほうがい。

パッケージの更新とかならMakefileがお手軽じゃない？

>>304
AWKには"文字"の置換はない("文字列"の置換はある)。Sedは内部に tr コマンドがない代わりに y コマ
ンドで"文字"の置換を行え、原理的に速いが、trコマンドやPerlの tr 演算子のように、文字の範囲指定
([0-9]で数字を構成する文字全て、等)ができないので、使い勝手で劣る。

>>315
パスワードをそのままスクリプトに書くのがまずやばいし
そういう簡単な実行頻度の高いやつは
Ctrl+R で履歴検索からでええのでは、、

>>301
それperlからシェル呼んでるだけだろ

コマンドを関数と同じように使える言語があってもいいと思うんですけどね
それがシェルなんだろうけど、言語なんでインタラクティブシェル機能ははなくていいｗ
なぜかみんなPOSIXシェルの代替を目指す。
そんなん無理だろうに

シェルを介さずに外部コマンド呼ぶ方法なんてperlにもpythonにも普通にあるだろ

シェルを介さずに外部コマンド呼ぶことはできるが
パイプのように出力側と入力側でブロックせずに並列で処理を実行できる機能がない

>>323
>>パイプのように出力側と入力側でブロックせずに並列で処理を実行できる機能がない
どういう意味？

>>324
これを実行してみればわかる

for i in $(seq 100); do sleep 1; echo $i; done | grep -E "3|5|8"

>>325
子プロセス作ればいいだけじゃん