【Bash】Windows Subsystem for Linux【WSL】6
レス数が950を超えています。1000を超えると書き込みができなくなります。
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】5
https://mao.5ch.net/test/read.cgi/linux/1553100855/ うちの環境だと重くないぞ
あとjsonの何が悪いんだ
共有しやすくていいだろ jsonは配列の末尾要素のあとに続くカンマがエラーになるのが気に食わない。
以下の例だと"foobar1"でエラー。
{
"foo1",
"bar2",
"foobar1",
} >>850
知らない人、あとから見た人にために、
Windows Terminal Preview v0.8はプレビュー版って書いとけ
正式版は4月予定だ 既に、Ubuntu 16.04 を入れているけど、18.04 も入れてみた！
最初に、/etc/apt/sources.list を空(0 バイト)ファイルにして、
/etc/apt/sources.list.d/ に、iij.list, jaist.list の2つのファイルを置いて、
ミラーサーバーから、大量のパッケージを更新した！
大阪だけど、1MB/s 以上と、IIJ の方が速いためか、すべてIIJからダウンロードされた
perl: Setting locale failed. の警告が出たので、
sudo vim /etc/locale.gen
として、en_US.UTF-8 UTF-8 以外の値がコメントアウトされているので、
ja_JP.UTF-8 UTF-8 のコメントを解除して、
sudo locale-gen
を実行した 日本語関係なんて特にいじった記憶ないんだけどな
language-pack-jaでも入れれば勝手に日本語化されるんじゃね？ sudo apt install language-pack-ja
で、日本語ロケールをインストールすると、
locale -a
で、ja_JP.utf8 が表示される
.bash_aliases に、
export LANG=ja_JP.UTF-8
と書いて、日本語ロケールに設定しているけど、これはいらないのかな？
他に、manpages-ja, manpages-ja-dev もインストールする なんで.bash_aliasesなんかに書くんだ？ .bashrc使えよ
ユーザーのロケール設定はいるだろ
OSは複数のロケールに対応する、ユーザーごとにロケールを切り替える
デフォルト設定じゃなくて、ユーザーごとに決めるものだから おや？俺は/etc/default/localeで設定されてた。
こんな所いじった記憶ないし、やっぱり勝手にされてたんじゃないかねぇ >>856
自己レス
.bash_aliases に、
export LANG=ja_JP.UTF-8
と書いて、日本語ロケールに設定する必要がある
これが無いと、C.UTF-8 になってしまう！
echo $LANG
C.UTF-8
>>857
.bashrc は既に大量に書いてあって、ややこしいから、
別のファイルに書くことにしてる if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
.bashrc の最後の方に、上のように書いてある。
.bash_aliases が存在すれば、それを読み込むようになっているので、
そこに設定を書いている
別のファイルに分けておく方が、わかりやすいから if [ -f ~/.bash_おれおれ ]; then
. ~/.bash_おれおれ
fi
とか付け足せよ >>858
漏れのは今も、日本語言語パックを入れた後でも、C.UTF-8 になってる！
cat /etc/default/locale
LANG=C.UTF-8
だから、環境変数のexport が必要。
export LANG=ja_JP.UTF-8 入れたのずっと前だから知らん。
自分でやったかもしれないし、勝手になってたのかもしれん
ぶっちゃけどうでもいいやｗ デフォルトロケール変更するのは
sudo update-locale LANG=ja_JP.utf8
とかじゃね？
言語パック入れただけだと変わらないと思ったけど >>860
エイリアスでないものを.bash_aliasesに書くのは混乱のもとでは？
自分で追記するものは、.bashrcの最後にまとめて書いてるよ。
そういえば、自分も実際にどのようにやったかは思い出せないな。
langパックを入れたのは確かだけど。 でも、デフォルトロケールを変えても良いの？
皆さん、ja_JP.utf8 に変えてるの？ wsl環境でもdo-releaae-updateで行けるって話じゃねえの？
なんでそんな外法に出るんだ…何の参考書にもならないし、絶対真似すんなとしか言えない
チラシの裏にでも書いてママに見せて誉めてもらえ、余所様に見せるな、ってクソ話 >>866
漏れの、.bash_aliases の内容は、数行しかない
export LANG=ja_JP.UTF-8
export EDITOR=vim
shopt -s expand_aliases
で、少しエイリアスを書いてるだけだから >>868
Ubuntu 16.04 を、18.04 に変える、簡単な方法があったの？
ただ、もし動かなかった時に、元に戻したいから、
18.04を別にインストールした方が安全かなと思って
16.04も、パッケージの更新を続けていたので、1GB 以上になってるから、
18.04の動作を確認するまで、しばらく消さずに置いておきたい LXDを削除してdo-release-upgradeでいけたけどな 口では18.04が信頼できないので16.04を残しておきたいと言いつつ、非正規な手段で16.04環境を自分で壊している自覚すら無いアホか…
まあお前の環境がどうなろうと俺らの知ったことではないし、自分でぶっ壊した環境の尻拭いの救済を他人に求めるのも筋違いだ 自分自身のスタイルが固まっていて、ディストリのお仕着せ環境なんか向こうに回してオレ環境をバリバリ整備していくような話かと思ったら、言語ロケール設定をbashaliasに書くようなトンチキだし
無知なアホが自分で環境ぶっ壊して行くのは止めるつもりも謂われもないが、それをいちいちこんな所に書くなよ
誰も助けないし、助けるべきでもないアホだこういうのは 18.04 の最初の大量のパッケージ更新で、
下のようなログが、10ぐらい出てるけど、異常は無いの？
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory wsl環境ではubuntuはwindowsストアに16.04と18.04が別のアプリとして存在していて、別個のアプリ扱いなので両方を平行して導入できるし
導入済みの16.04からdo-release-upgradeで18.04化した16.04はストア上では16.04扱いになるので、18.04環境を２つ平行で存在させることもできる
逆に言えば16.04から18.04にアップグレードした環境はストア上では18.04としては扱われない訳だが
将来的にはwindowsストア上でリリース毎に別扱いという状態はなくなって、ubuntuはLTSとその間の個別リリースにする予定だとは聞いてるけど、現時点ではそのようになっている やっぱり、do-release-upgrade をやらずに、16.04/18.04 を別々に持っておきます
ところで、16.04のファイルを、18.04へコピーするには、どうやれば良いですか？
漏れのやり方は、一々、16.04のファイルをvim で開いて、
Windows 側のファイルに内容をコピーして、改行コードをLF に変える
次に、18.04を起動して、Windows側から、そのファイルをUbuntu側へコピーするという、
非常に面倒くさい事をしていますw 今、思いついたけど、
Linux 側から、Windows 側には、アクセスできるので、
16.04 から、コピーしたいフォルダー以下を再帰的に、Windows側へコピーして、
そのフォルダー以下のすべてのファイルの改行コードを、LF に変えてから、
18.04 を起動して、Windows側から、
そのフォルダー以下のすべてのファイルを、Ubuntu 側へコピーすると良さそう ICUというunicode関連のライブラリがあるんだが、gitレポジトリをGit for Windowsでクローンすると改行問題に遭遇する。
WSLのgitを使うことで回避可能。こういう時に、WSLのちょっとしたありがたみを感じる。 >>876
改行コード変える意味がわからんけど
sshでいいだろ つーか普通にWSLからWindowsのディレクトリ見えてるんだから
コピーすればいいだけの話 >>876 >>877
エクスプローラーでコピペするだけ バージョンアップのとき移行処理用のスクリプトが用意されておらず手作業でリポジトリを入れ替えてアップデート強行、発生した諸問題を逐一で泥縄対応…って、古いBSDのやり方だな
doreleaseupgradeはdebian系の作法、wsl環境では通用しないと勝手に思い込むユーザーは居たかもしれないが、ubuntuを含めdebian系を扱うなら存在自体は半ば常識かと思っていたが。
指摘後に環境を戻して再試行したとは到底思えないレスポンスタイム、自分で環境を壊しては直しもせず、やらかす手前に戻りもせずに次々と時代遅れの環境依存ネタを振り出すという時代錯誤な態度。
20年くらい昔に時折見かけたような、わざわざ喧嘩売りに来ておいて速攻で泣かされて逃げていくBSDキチガイを思い出す。
大方、仮想PCに突っ込んだWin10とwsl環境をデタラメに貶しながらぶっ壊してlinuxとwindowsを叩き、ひとしきりあざ笑った後でBSDに戻りますと言い出すような猿芝居じゃないのかこれ。
いずれにしても、自分で勝手に18.04のリポジトリに書き換えてapt updateしてしまった16.04環境なんて、もはや16.04環境ではないし、18.04にも移行し切れていない、半端にぶっ壊されたゴミ環境。
ここから叩き直して18.04に仕立てるくらいなら18.04を新規で入れた方が手間がないだろうし、残しておく意味もない。 ファイルコピーではなくファイル編集でテキストのコピーペーストを延々やってるってことかね
linuxユーザーって意識高い系のイメージ強いけどここまでトンチキなのもいるのか
読んでて頭痛くなってきた >とん‐ちき【頓痴気】
>
>《「ちき」は接尾語。「頓痴気」は当て字》とんま。まぬけ。人をからかい、ののしっていう語。「またへまをしたな、この頓痴気め」 WSL では、Linux 側からは、Windows 側にアクセスできるけど、
Windows側からはアクセスできない！
だから、Windows側から触れない
改行コードが変わってしまうのは、クリップボード経由でコピーしたからw
cp コマンドを使ってみます Windows側からWSLのディレクトリにアクセスできるだろ
何年前の話をしてるんだ？ wsl1ならば、アクセス自体はできるが、ファイルの変更すると
パーミッションを改めて与えないとファイルが認識できない >>893
複数のディストリを起動していてもエクスプローラーでそれぞれのホームディレクトリとか参照できるし操作もできるぞ
無知で頑固なやつだなぁ wsl$経由なら大丈夫じゃない？
オフラインで大量ファイルの引っ越しならtar使うかなぁ 俺は/mnt/c/Users/名前/directoryを~/以下に作ったシンボリックリンクからアクセスしてる
つまりほぼすべてのデータはWindows側にあるから、複数ディストリがあったとしても
同じようにアクセスできる いまはwindows側にファイル置いてlinux側からアクセスしても全く問題ないんだっけ？ ところでWSL2で他のディストロのファイルシステムをクロスマウントできるって本当？ >>901
全部じゃないみたいだね
リリースノートにはあるけど具体的な手順が見つからん、と思ったら/mnt/wslがデフォで共有されてた
tmpfsだからインスタンスが全部落ちると中身は消える >>893
https://docs.microsoft.com/ja-jp/windows/wsl/release-notes#build-18342
ユーザーが Windows から WSL ディストリビューションの Linux ファイルにアクセスできるようにする機能を追加しました。
これらのファイルには、コマンド ラインを使用してアクセスできます。また、ファイル エクスプローラーや VSCode などの Windows アプリもこれらのファイルと対話できます。
\\wsl$\<distro_name> に移動してファイルにアクセスするか、\\wsl$ に移動して実行中のディストリビューションの一覧を表示します。 \\wsl$ 経由でコピーすると実行権限が落ちるな
ユーザー名とかは、一般的なパターンでは変わらないだろうし、
むしろコピー先のユーザー名になってほしいぐらいだけど
実行権限がつくようなスクリプトはプログラムなわけで
どっちみちgit管理して、githubにアップしてるので実はどうでもいい
落ちたら落ちたでつければいいかな >>905
実行権は落ちるが、コピー先のユーザー名にはなってくれるよ。 ~/.bash_history をメモ帳などWindows向けテキストエディタで手動編集したい場合は、
\\wsl$経由じゃないとファイルのアクセス権限を正常に維持したまま保存できない。 Macでよくね？ｗ
それか普通にLinuxインストールした方がいいよ wslのスレまで来て、Macで良くね？とかLinux入れろよって人って、的はずれなことも分かってないんだろうな >>907
それはエディタによる
まともなエディタであれば\\wsl$経由じゃなくても
アクセス権というかファイルのメタ情報が消えることはない 今年Office2016のサポートが切れる。
windowsより5年早い。
Apple&AdobeだけじゃなくMSにまで食い物
にされる信者乙w OSSとやらは旧バージョンを半永久的にサポートしてくれるの？ 永久ではないけど商用よりは長いね
4.3倍くらい長い >>913
人が居なくなれば自然にサポから外れてしまいますね >>908
macである時点で論外。
finderがexplorerよりマシになってからの話だな。 >>910
~/ 以下はlinuxアカウントのディレクトリなので通常のWindowsパスによる操作ではlinuxアカウントの権限情報が失われる。 >>911
LinuxとBSDなんて実質的に変わらないだろ…
カーネル読んだりメンテナーやってる人かな？ｗ 似たような動きするし、似たような作りになってるな。
カーネルソースはLinuxもBSDもディレクトリ構造がそっくりというか大元からパクってるな。 >>907 >>910
\\wsl$ 経由ではないアクセスってどうやるの？
MSのページにそんなの載ってたっけ？ linuxの大元と言うとAmebaなのか、Minixなのか？
哲学的やな UNIXのユーザーランドは正統のSysV系と傍流のBSDでAPIから違うし、コマンドのオプションや主流シェル等も分断してる
GNUはSysVのクローンでSysVの方言とみなすこともできるが、まあ実際はGNU/SysV/BSDで分断されてると言っていい
Linuxはほぼ全てのディストリでGNUを採用しているのでマイナーなBSDとは環境的にも互換性が無い
というかマカーの人はGNU由来のツールとか導入したらBSD由来の環境と断絶してるものがシステムに混在することになるけど、どうやって棲み分けてるんだろうね
設計思想的に異なるものが無節操に混在したグチャグチャの環境になってつらそう >>912
Office2016の延長サポートは2025年10月14日まで
あと5年 >>920
/mnt/cからアクセスできるだろ
Windows上にファイルを置いてLinuxから
使うという使い方が最初の使い方なんだよ >>918
> LinuxとBSDなんて実質的に変わらないだろ…
機能的に Linux（GNU）> BSD なので
BSDしか使ってない人は、GNUと変わらないように見えるかもしれんが
普段GNUを使ってるとBSDのコマンドは不便すぎて苦痛 あとMacはCLIコマンドがOS標準だと基本的なものしか無い。
Homebrewなどのサードパーティの
パッケージ管理システムに頼らないといけないのもいや >>923
windowsはな。Mac用は今年で延長サポート無し >>922
普通にMacでgcc使ってて一度も問題になったことなどないが… >>924
.bash_history編集するのにわざわざ/mnt/c？
それって効率悪いよね >>926
Homebrewが面倒ってもう宗教的ないちゃもんでしかないよ、あんた ID:6Fy97RgUはマイクロソフトの信者さんなんだろうな、、
大人しくWindowsだけ使ってればいいのに
こういう人にLinuxを騙って欲しくないわ… >>927
Mac版Office延長サポートなしワロスｗ
>>929
.bash_historyなんか編集してはいけません
そもそも実行権限の有無が関係ないファイルなんてどうでもいい
>>930
Homebrewが面倒なんて言ってないぞ
cygwinなどと同じで、サードパーティのパッケージ管理システムだって言ってるの >>929
あと効率とかシンボリックリンクはるだけだろ >>932
参考として.bash_historyを引き合いに出したけど実機でも編集しないし編集するもんじゃないとは思ってる、チョイスミス、悪い。
単にアクセス方法を聞いてみたかっただけ。 だからディストリ間で共有したいなら、Windows側の
/mnt/c/Users/ユーザー名/以下に置いて
シンボリックリンクでも貼ればいいだけだって言ってる >>934
そんな化石記事を引っ張り出してドヤられても・・・ >>935
普段WSLからWindowsのファイルはさわらず、WSL内かWindowsからアクセスするのでWSL内へのショートカットを張ってるよ。
WSLは実機に落とし込むための仮環境的な使い方なので。 >>937
コピーや移動はするがディストリ間共有はしないよ >>932
> .bash_historyなんか編集してはいけません
おやおや精神勝利法を使いましたか。 /mnt/cからだとwslのrootfsは触れないと思うが…
(例えば1909だとパーミッションが無い)
ホームディレクトリが/mnt/c配下にあるって事？ .bash_history を見たら、同じコマンドばっかりw
これは面倒。
重複排除した方がよい
>>939
漏れはいつも、Linux 側から、Windows 側を、grep してる Windows 10のWindows Subsystem for Linux（WSL）を日常的に活用する
https://www.clear-code.com/blog/2017/11/8.html
この記事は、2019/4/10 に追記もしてるから、わりと新しい >>941
お前はスタートラインにも立ってないから>>936よめな
> 参考として.bash_historyを引き合いに出したけど実機でも編集しないし編集するもんじゃないとは思ってる、チョイスミス、悪い。 「できないこと」を「してはいけないこと」として甘受する奴隷精神。そこに進歩やビジネスチャンスはない。 鍋奉行やマナー奉行みたいなのがしゃしゃり出てきて、あれはするな、これはするな、と言い出したら、そのコミュニティは終わり。 「それは今はできないがいずれできるようにすべき」と考えることができない人は、開発や品質向上プログラムに参加しないほうがいい。
「それはするな」と勝手なルールを作る奉行気質の人は、コミュニティから出ていくべき。進歩が止まる。 土曜日も出勤してくれ
「それは今はできないがいずれできるようにすべき」と考えることができない人は、開発や品質向上プログラムに参加しないほうがいい。 レス数が950を超えています。1000を超えると書き込みができなくなります。
