概要 ctrl + hjklは公開されているルールを利用したが、Macのデフォルトのバックスペースショートカットctrl + hが右カーソルに割り当てられてしまった。 別途、Karabiner-Elementsに独自ルールを作成してバックスペースをでctrl + nにした。 公式ドキュメント いくつか典型的な設定例がサンプルとして載せられており助かった https://karabiner-elements.pqrs.org/docs/json/typical-complex-modifications-examples/#change-control-h-to-delete 設定ファイルの置き場 /Users/ユーザー名/.config/karabiner/assets/complex_modifications/ 作成 適当なファイル名でjsonファイルを作成する backspace_ctrl_n.json { "title": "俺のルール", "rules": [ { "description": "Ctrl + n = backspace", "manipulators": [ { "type": "basic", "from": { "key_code": "n", "modifiers": { "mandatory": ["control"], "optional": ["caps_lock", "option"] } }, "to": [ { "key_code": "delete_or_backspace" } ] } ] } ] } Karabiner-Elements で追加 complex modifications > + Add ruleボタンを押すと先程の独自ルールがいるので+ Enableする 以上
ctrl + hjkl
ctrl + h
Karabiner-Elements
ctrl + n
/Users/ユーザー名/.config/karabiner/assets/complex_modifications/
{ "title": "俺のルール", "rules": [ { "description": "Ctrl + n = backspace", "manipulators": [ { "type": "basic", "from": { "key_code": "n", "modifiers": { "mandatory": ["control"], "optional": ["caps_lock", "option"] } }, "to": [ { "key_code": "delete_or_backspace" } ] } ] } ] }
+ Add rule
+ Enable
以上
都度追加していきます。 単語選択 command + D
都度追加していきます。
command + D
結論 Mac端末内でユーザが入力して記憶させたパスワードはキーチェーンアクセスから取得できます。 経緯 PCの引っ越しを行った際に、古いMacで使用していたSSHの秘密鍵を、念のため新しい端末に残しておきたいことがありました。 秘密鍵は、鍵を作成した端末の外には持ち運びしないのが賢明だと思いますが、万一古い秘密鍵でしかログインできないサーバーなどがあると困るので、念の為新しいマシンに（安全な方法で）バックアップとして移動させました。 そこで、新しいPC上で古い秘密鍵でのSSHを試みたところ、鍵のパスワードが分からなくなり焦ってしまいました。 何年も前にPCを購入しセットアップした際に、ほんの出来心で念のために設定したたパスワードでしたが、入力を記憶させておりパスワード入力を何年も行わないままだったので、パスワードを設定していたことも含めてすっかり忘れてしまっていました。 解決方法 記憶させたパスワードはキーチェーンアクセスに残っています。 キーチェーンアクセスのサイドメニューから"分類" > "パスワード"の中にSSH鍵で入力を記憶させたパスワードを再確認できます。 右クリックのメニューから"クリップボードにコピー"が可能です。 感想 パスワード入力を省略できるということはどこかに平文として残っているはずなので当たり前なのですが、一瞬焦ってしまったので備忘録として残しておきます。
Mac端末内でユーザが入力して記憶させたパスワードはキーチェーンアクセスから取得できます。
PCの引っ越しを行った際に、古いMacで使用していたSSHの秘密鍵を、念のため新しい端末に残しておきたいことがありました。 秘密鍵は、鍵を作成した端末の外には持ち運びしないのが賢明だと思いますが、万一古い秘密鍵でしかログインできないサーバーなどがあると困るので、念の為新しいマシンに（安全な方法で）バックアップとして移動させました。 そこで、新しいPC上で古い秘密鍵でのSSHを試みたところ、鍵のパスワードが分からなくなり焦ってしまいました。 何年も前にPCを購入しセットアップした際に、ほんの出来心で念のために設定したたパスワードでしたが、入力を記憶させておりパスワード入力を何年も行わないままだったので、パスワードを設定していたことも含めてすっかり忘れてしまっていました。
記憶させたパスワードはキーチェーンアクセスに残っています。 キーチェーンアクセスのサイドメニューから"分類" > "パスワード"の中にSSH鍵で入力を記憶させたパスワードを再確認できます。 右クリックのメニューから"クリップボードにコピー"が可能です。
パスワード入力を省略できるということはどこかに平文として残っているはずなので当たり前なのですが、一瞬焦ってしまったので備忘録として残しておきます。
Motivation コンテナ管理基盤であるKubernetesには、Kubernetes Operatorという概念があり 任意のオブジェクトをKubernetes上で管理することができる。 このKubernetes Operatorを用いると和牛も管理することができるので給付してみる。 ここで、Kubernetes Operatorを開発するツールは、下記の通りいくつか存在しているが エコシステムが充実しているOperator SDKを採用した。 Operator SDK Kubebuilder Metacontroller QuickStart 環境 kind Docker Mac 和牛の配り方 Quay.ioのアカウント登録 https://github.com/operator-framework/operator-sdk#quick-start operator-sdkを用いて和牛Operatorの雛形を作成 TMPDIR=`mktemp -d` && cd $TMPDIR mkdir $TMPDIR && cd $TMPDIR operator-sdk new wagyu-operator --repo github.com/delicious/wagyu cd wagyu-operator operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=Wagyu operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=Wagyu 和牛コントローラの処理を一部書き換え 実際にはデプロイされるPodのImageを差し替えている sed 's|Image: "busybox"|Image: "quay.io/iaoiui727/wagyu:latest"|g' -i pkg/controller/wagyu/wagyu_controller.go 和牛OperatorのDockerイメージ作成 export USER=<quay.ioで作成したユーザ名> operator-sdk build quay.io/$USER/wagyu-operator docker login quay.io DockerイメージのPush docker push quay.io/$USER/wagyu-operator Quay.ioでリポジトリをpublicにする Kubernetesクラスタの構築 kind create cluster 和牛Operatorのマニフェスト内で、先ほどquayにアップロードしたDockerイメージを使うよう変更 sed -i "/Command/d" pkg/controller/wagyu/wagyu_controller.go sed -i "s|REPLACE_IMAGE|quay.io/$USER/wagyu-operator|g" deploy/operator.yaml Operator用のサービスアカウント、ロールを用意 kubectl create -f deploy/service_account.yaml kubectl create -f deploy/role.yaml kubectl create -f deploy/role_binding.yaml 和牛のCRD(Custom Resource Definition)を生成 和牛というCRDリソースがKubernetesに登録される kubectl create -f deploy/crds/app.example.com_wagyus_crd.yaml 和牛というCRDリソースの定義を確認できるようになる k get wagyu NAME AGE example-wagyu 1m 和牛Operatorを起動 kubectl create -f deploy/operator.yaml 和牛Operatorの起動を確認 kubectl get po NAME READY STATUS RESTARTS AGE wagyu-operator-7d87f94966-c7rbt 1/1 Running 0 18s 和牛インスタンスを起動 kubectl create -f deploy/crds/app.example.com_v1alpha1_wagyu_cr.yaml 正常に起動していることを確認 kubectl get pod -l app=example-wagyu kubectl describe appservice example-appservice 給付された和牛を確認 kubectl logs example-wagyu-pod ? Clean up kind delete cluster まとめ Operator SDKを用いてKubernetes上で和牛を給付できた 今回はGo言語で検証したが、Operator SDKではAnsible, Helmも対応しているので利用してみたい。
コンテナ管理基盤であるKubernetesには、Kubernetes Operatorという概念があり 任意のオブジェクトをKubernetes上で管理することができる。 このKubernetes Operatorを用いると和牛も管理することができるので給付してみる。
ここで、Kubernetes Operatorを開発するツールは、下記の通りいくつか存在しているが エコシステムが充実しているOperator SDKを採用した。
Operator SDK Kubebuilder Metacontroller
https://github.com/operator-framework/operator-sdk#quick-start
TMPDIR=`mktemp -d` && cd $TMPDIR mkdir $TMPDIR && cd $TMPDIR operator-sdk new wagyu-operator --repo github.com/delicious/wagyu cd wagyu-operator operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=Wagyu operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=Wagyu
実際にはデプロイされるPodのImageを差し替えている
sed 's|Image: "busybox"|Image: "quay.io/iaoiui727/wagyu:latest"|g' -i pkg/controller/wagyu/wagyu_controller.go
export USER=<quay.ioで作成したユーザ名> operator-sdk build quay.io/$USER/wagyu-operator docker login quay.io
DockerイメージのPush
docker push quay.io/$USER/wagyu-operator
Quay.ioでリポジトリをpublicにする
kind create cluster
sed -i "/Command/d" pkg/controller/wagyu/wagyu_controller.go sed -i "s|REPLACE_IMAGE|quay.io/$USER/wagyu-operator|g" deploy/operator.yaml
kubectl create -f deploy/service_account.yaml kubectl create -f deploy/role.yaml kubectl create -f deploy/role_binding.yaml
和牛というCRDリソースがKubernetesに登録される
kubectl create -f deploy/crds/app.example.com_wagyus_crd.yaml
和牛というCRDリソースの定義を確認できるようになる
k get wagyu NAME AGE example-wagyu 1m
kubectl create -f deploy/operator.yaml
和牛Operatorの起動を確認
kubectl get po NAME READY STATUS RESTARTS AGE wagyu-operator-7d87f94966-c7rbt 1/1 Running 0 18s
kubectl create -f deploy/crds/app.example.com_v1alpha1_wagyu_cr.yaml
正常に起動していることを確認
kubectl get pod -l app=example-wagyu kubectl describe appservice example-appservice
kubectl logs example-wagyu-pod ?
kind delete cluster
Operator SDKを用いてKubernetes上で和牛を給付できた 今回はGo言語で検証したが、Operator SDKではAnsible, Helmも対応しているので利用してみたい。
はじめに 本記事はRaspberry Piを使用し、家庭内でファイル共有サーバを構築する方法について記載しています。 リモートワークを行うために会社からWindowsのPCが配付されたとします。 デザイナーを例にすると、会社から配付されたWindowsにあるデータを自宅のMacにコピーして作業したい場合は、ファイル共有を行う手段として何らかの方法が必要になります。 Dropbox等オンラインストレージサービスでファイル共有を行うこともできますが、そんなときに便利なのが自宅で使えるファイル共有サーバです。 Raspberry PiにSambaを導入し、ファイル共有サーバを構築することでWindowsやMacなどで簡単にファイル共有ができます。 SMB SMB（Server Message Block）は、Windowsコンピュータの間でファイル共有やプリンタ共有などを行うためのプロトコルです。 下位のプロトコルとしてNetBIOSを使用します。また、SMBを拡張したCIFSというプロトコルも存在します。CIFSは直接、TCP/IPを利用します。 Sambaの構築 Sambaのインストール $ sudo apt-get install samba samba-common-bin 共有フォルダの作成 $ sudo mkdir /var/samba 共有フォルダへアクセスするユーザの作成 $ sudo useradd smbuser パスワードの設定 $ sudo passwd smbuser 権限変更 $ sudo chown smbuser:smbuser /var/samba/ Sambaのアクセス設定 $ sudo pdbedit -a smbuser 共有フォルダの公開設定 $ sudo cp -p /etc/samba/smb.conf /etc/samba/smb.conf.org $ sudo vi /etc/samba/smb.conf /etc/samba/smb.confファイルに以下を追記する。 [share] comment = Share Folder browseable = yes path = /var/samba writable = yes valid users = smbuser force user = smbuser Sambaの再起動 $ sudo /etc/init.d/samba restart pdbedit pdbeditコマンドは、SAM データベース (Samba ユーザーのデータベース) を管理します。 SAM データベース内に保持されるユーザーアカウントを管理するために利用され、 root だけが実行できます。 pdbeditを使用することで、ユーザーアカウントの追加、ユーザーアカウントの削除 、ユーザーアカウントの変更、ユーザーアカウントの一覧表示、ユーザーアカウントのインポートの操作が行えます。 データベースのユーザーアカウントを一覧表示 $ sudo pdbedit -L smbuser:1001: データベースのユーザーアカウントを一覧表示（詳細） $ sudo pdbedit -L -v --------------- Unix username: smbuser NT username: Account Flags: [U ] User SID: S-1-5-21-1950213270-485466186-3954191822-1000 Primary Group SID: S-1-5-21-1950213270-485466186-3954191822-513 Full Name: Home Directory: \\raspberrypi01\smbuser HomeDir Drive: Logon Script: Profile Path: \\raspberrypi01\smbuser\profile Domain: RASPBERRYPI01 Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: never Kickoff time: never Password last set: 水, 25 3月 2020 15:11:40 JST Password can change: 水, 25 3月 2020 15:11:40 JST Password must change: never Last bad password : 0 Bad password count : 0 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ファイル共有サーバのアクセス Raspberry Pi側でファイアウォールを有効にしている場合は、Sambaで使用する通信が許可されていることを前提とし、WindowsとMacそれぞれのアクセス方法について記載しています。 Windows Windows10でSambaにアクセスするためには、SMBのクライアントが必要になります。 Windows 10の場合はSMB 1.0 が無効になっているため、以下の手順でSMBのクライアントを有効にします。 コントロールパネルを開く プログラムから、［Windows の機能の有効化または無効化］を開く ［SMB 1.0/CIFS クライアント］をチェックを入れて、[OK]をクリックする。 SMBのクライアントを有効化後、エクスプローラーからネットワークで、¥¥＜Raspberry PiのIPアドレス＞:¥share¥にアクセスする。 先ほど作成したsmbuserの認証情報を入力するとファイル共有サーバにアクセスできる。 Mac Macの場合はFinderからアクセスします。 Finderの[移動]から、[サーバへ接続]を選択する。 [サーバアドレス]にsmb://<Raspberry PiのIPアドレス>を入力し、[接続]をクリックする。 登録ユーザを選択し、先ほど作成したsmbuserの認証情報を入力するとファイル共有サーバにアクセスできる。 おわりに Raspberry Piを有効活用し、リモートワークに役立てましょう。
本記事はRaspberry Piを使用し、家庭内でファイル共有サーバを構築する方法について記載しています。
リモートワークを行うために会社からWindowsのPCが配付されたとします。 デザイナーを例にすると、会社から配付されたWindowsにあるデータを自宅のMacにコピーして作業したい場合は、ファイル共有を行う手段として何らかの方法が必要になります。
Dropbox等オンラインストレージサービスでファイル共有を行うこともできますが、そんなときに便利なのが自宅で使えるファイル共有サーバです。
Raspberry PiにSambaを導入し、ファイル共有サーバを構築することでWindowsやMacなどで簡単にファイル共有ができます。
SMB（Server Message Block）は、Windowsコンピュータの間でファイル共有やプリンタ共有などを行うためのプロトコルです。
下位のプロトコルとしてNetBIOSを使用します。また、SMBを拡張したCIFSというプロトコルも存在します。CIFSは直接、TCP/IPを利用します。
$ sudo apt-get install samba samba-common-bin
$ sudo mkdir /var/samba
$ sudo useradd smbuser
$ sudo passwd smbuser
$ sudo chown smbuser:smbuser /var/samba/
$ sudo pdbedit -a smbuser
$ sudo cp -p /etc/samba/smb.conf /etc/samba/smb.conf.org
$ sudo vi /etc/samba/smb.conf
/etc/samba/smb.confファイルに以下を追記する。
/etc/samba/smb.conf
[share] comment = Share Folder browseable = yes path = /var/samba writable = yes valid users = smbuser force user = smbuser
$ sudo /etc/init.d/samba restart
pdbeditコマンドは、SAM データベース (Samba ユーザーのデータベース) を管理します。 SAM データベース内に保持されるユーザーアカウントを管理するために利用され、 root だけが実行できます。
pdbeditを使用することで、ユーザーアカウントの追加、ユーザーアカウントの削除 、ユーザーアカウントの変更、ユーザーアカウントの一覧表示、ユーザーアカウントのインポートの操作が行えます。
$ sudo pdbedit -L
smbuser:1001:
$ sudo pdbedit -L -v
--------------- Unix username: smbuser NT username: Account Flags: [U ] User SID: S-1-5-21-1950213270-485466186-3954191822-1000 Primary Group SID: S-1-5-21-1950213270-485466186-3954191822-513 Full Name: Home Directory: \\raspberrypi01\smbuser HomeDir Drive: Logon Script: Profile Path: \\raspberrypi01\smbuser\profile Domain: RASPBERRYPI01 Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: never Kickoff time: never Password last set: 水, 25 3月 2020 15:11:40 JST Password can change: 水, 25 3月 2020 15:11:40 JST Password must change: never Last bad password : 0 Bad password count : 0 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Raspberry Pi側でファイアウォールを有効にしている場合は、Sambaで使用する通信が許可されていることを前提とし、WindowsとMacそれぞれのアクセス方法について記載しています。
Windows10でSambaにアクセスするためには、SMBのクライアントが必要になります。 Windows 10の場合はSMB 1.0 が無効になっているため、以下の手順でSMBのクライアントを有効にします。
¥¥＜Raspberry PiのIPアドレス＞:¥share¥
Macの場合はFinderからアクセスします。
smb://<Raspberry PiのIPアドレス>
Raspberry Piを有効活用し、リモートワークに役立てましょう。
ある日、desktopでls実行した時に… ターミナル lancai@oja Desktop % ls -l total 23336 drwxr-xr-x@ 27 lancai staff 864 Feb 29 14:14 ajax_crud_sample drwxr-xr-x 4 lancai staff 128 Feb 27 23:57 git_sample drwxr-xr-x 4 lancai staff 128 Feb 27 23:05 hell drwxr-xr-x@ 4 lancai staff 128 Mar 1 13:25 hello drwxr-xr-x 3 lancai staff 96 Feb 29 14:08 helloHeroku drwxr-xr-x 13 lancai staff 416 Mar 12 22:27 joint_dev_task drwxr-xr-x 5 lancai staff 160 Mar 21 16:15 mosha drwxr-xr-x@ 9 lancai staff 288 Mar 26 22:19 npm_sample -rw-r--r--@ 1 lancai staff 4634176 Mar 26 22:23 ??????????????????????????? 2020-03-26 22.23.14.png -rw-r--r--@ 1 lancai staff 2202423 Mar 27 21:08 ??????????????????????????? 2020-03-27 21.07.57.png -rw-r--r--@ 1 lancai staff 5104788 Mar 27 21:58 ??????????????????????????? 2020-03-27 21.58.42.png 下３行のファイル名が文字化けしてて「?！？」 そういえばRubyか何かの環境構築する時に日本語打ったら文字化けしてたけど解決せずそのままだったなあ…と！！ ということでこれを機に色々ググった結果、解決したのでその方法を記録していきます。 ターミナルの設定 ターミナル＞環境設定＞プロファイル＞詳細 ↑赤色の丸印２箇所が画像の通りになっているかチェック ターミナル＞環境設定＞エンコーディング ↑画像の通りにUnicode(UTF-8)にチェック LANGの値を確認 ご自身のホームディレクトリにて以下を実行 ※ホームディレクトリ・・・ターミナルでcdを実行した時に移動できる。 ターミナル lancai@oja % echo $LANG C ※↑ここでja_JP.UTF-8と出ていたら解決とのことだが、Cと表示される。 現在使っているシェルを表示 lancai@oja ~ % echo $SHELL /bin/zsh /bin/zshが表示されたら~/.zshenv /bin/bashが表示されたら~/.bash_profile のいずれかのファイル内にexport LANG=ja_JP.UTF-8を追記する。(＝環境変数の設定が完了) 私の場合は/bin/zshが表示されたので~/.zshenvにexport LANG=ja_JP.UTF-8を追記することで 環境変数の設定が完了するということです。 ~/.zshenvと~/.bash_profileの場所 ホームディレクトリ内にあるらしい ホームディレクトリに移動 ターミナル lancai@oja desktop % cd lancai@oja ~ % ホームディレクトリ内にあるファイルなどを表示 lancai@oja ~ % ls -a . .nodebrew Library .. .npm Movies .CFUserTextEncoding .oracle_jre_usage Music .DS_Store .rbenv MyVagrant .Trash .ssh Pictures .atom .subversion Public .bash_profile .vagrant.d VirtualBox VMs .bash_profile.swp .viminfo afax_crud_sample .bash_profile.txt .vscode agametter_app .bashrc .yarnrc ajax_crud_sample .bundle .zsh_history demo .config .zshrc dq_like_app .gem .zshrc.swp es6_sample .gitconfig Applications gitwork .inputrc.txt Desktop hello .local Documents .netrc Downloads 本来上記の中に入ってるらしいのですが どうやら私の場合、~/.zshenvが無かったようなので 以下の方法で作りました。 ↓ touchでテキストファイル作成 ターミナル lancai@oja ~ % touch ~/.zshenv ↓作成できたはずなのでopenで開く（テキストエディタが開きます） lancai@oja ~ % open ~/.zshenv テキストエディタ内にexport LANG=ja_JP.UTF-8を入力し、保存 ターミナルに戻り、以下を実行 lancai@oja ~ % exec $SHELL -l LANGの値を確認 lancai@oja ~ % echo $LANG ja_JP.UTF-8 ja_JP.UTF-8に設定できたみたいなのでdesktopでls実行 lancai@oja ~ % cd desktop lancai@oja desktop % ls ajax_crud_sample git_sample hell hello helloHeroku joint_dev_task mosha npm_sample スクリーンショット 2020-03-26 22.23.14.png スクリーンショット 2020-03-27 21.07.57.png スクリーンショット 2020-03-27 21.58.42.png 日本語の文字化け部分が解消されました?
ある日、desktopでls実行した時に…
ls
lancai@oja Desktop % ls -l
total 23336 drwxr-xr-x@ 27 lancai staff 864 Feb 29 14:14 ajax_crud_sample drwxr-xr-x 4 lancai staff 128 Feb 27 23:57 git_sample drwxr-xr-x 4 lancai staff 128 Feb 27 23:05 hell drwxr-xr-x@ 4 lancai staff 128 Mar 1 13:25 hello drwxr-xr-x 3 lancai staff 96 Feb 29 14:08 helloHeroku drwxr-xr-x 13 lancai staff 416 Mar 12 22:27 joint_dev_task drwxr-xr-x 5 lancai staff 160 Mar 21 16:15 mosha drwxr-xr-x@ 9 lancai staff 288 Mar 26 22:19 npm_sample -rw-r--r--@ 1 lancai staff 4634176 Mar 26 22:23 ??????????????????????????? 2020-03-26 22.23.14.png -rw-r--r--@ 1 lancai staff 2202423 Mar 27 21:08 ??????????????????????????? 2020-03-27 21.07.57.png -rw-r--r--@ 1 lancai staff 5104788 Mar 27 21:58 ??????????????????????????? 2020-03-27 21.58.42.png
下３行のファイル名が文字化けしてて「?！？」
そういえばRubyか何かの環境構築する時に日本語打ったら文字化けしてたけど解決せずそのままだったなあ…と！！
ということでこれを機に色々ググった結果、解決したのでその方法を記録していきます。
↑赤色の丸印２箇所が画像の通りになっているかチェック
↑画像の通りにUnicode(UTF-8)にチェック
ご自身のホームディレクトリにて以下を実行 ※ホームディレクトリ・・・ターミナルでcdを実行した時に移動できる。
cd
lancai@oja % echo $LANG
C
※↑ここでja_JP.UTF-8と出ていたら解決とのことだが、Cと表示される。
ja_JP.UTF-8
lancai@oja ~ % echo $SHELL
/bin/zsh
~/.zshenv
/bin/bash
~/.bash_profile
のいずれかのファイル内にexport LANG=ja_JP.UTF-8を追記する。(＝環境変数の設定が完了)
export LANG=ja_JP.UTF-8
私の場合は/bin/zshが表示されたので~/.zshenvにexport LANG=ja_JP.UTF-8を追記することで 環境変数の設定が完了するということです。
ホームディレクトリ内にあるらしい
lancai@oja desktop % cd
lancai@oja ~ %
lancai@oja ~ % ls -a
. .nodebrew Library .. .npm Movies .CFUserTextEncoding .oracle_jre_usage Music .DS_Store .rbenv MyVagrant .Trash .ssh Pictures .atom .subversion Public .bash_profile .vagrant.d VirtualBox VMs .bash_profile.swp .viminfo afax_crud_sample .bash_profile.txt .vscode agametter_app .bashrc .yarnrc ajax_crud_sample .bundle .zsh_history demo .config .zshrc dq_like_app .gem .zshrc.swp es6_sample .gitconfig Applications gitwork .inputrc.txt Desktop hello .local Documents .netrc Downloads
本来上記の中に入ってるらしいのですが どうやら私の場合、~/.zshenvが無かったようなので 以下の方法で作りました。 ↓
touch
lancai@oja ~ % touch ~/.zshenv
↓作成できたはずなのでopenで開く（テキストエディタが開きます）
open
lancai@oja ~ % open ~/.zshenv
テキストエディタ内にexport LANG=ja_JP.UTF-8を入力し、保存
lancai@oja ~ % exec $SHELL -l
lancai@oja ~ % echo $LANG
ja_JP.UTF-8に設定できたみたいなのでdesktopでls実行
lancai@oja ~ % cd desktop
lancai@oja desktop % ls
ajax_crud_sample git_sample hell hello helloHeroku joint_dev_task mosha npm_sample スクリーンショット 2020-03-26 22.23.14.png スクリーンショット 2020-03-27 21.07.57.png スクリーンショット 2020-03-27 21.58.42.png
日本語の文字化け部分が解消されました?
目的 Node.jsをHomebrewを使用してインストール後にバージョンを有効化する際に「vX.X.X is not installed」と出力され、それを解決した話をまとめる。 実施環境 ハードウェア環境 項目 情報 備考 OS macOS Catalina(10.15.3) ハードウェア MacBook Air (11-inch ,2012) プロセッサ 1.7 GHz デュアルコアIntel Core i5 メモリ 8 GB 1600 MHz DDR3 グラフィックス Intel HD Graphics 4000 1536 MB エラー内容 インストール後に下記コマンドを実行してバージョンの有効化を行った。(インストールは正常に完了、X.X.Xはバージョン名) $ nodebrew install-binary stable $ nodebrew use vX.X.X >vX.X.X is not installed 解決方法 下記コマンドを実行する。 $ nodebrew --version コマンドの出力の下部にある「# install」に記載されているコマンド$ nodebrew install vX.X.Xを実行する。 $ nodebrew install vX.X.X 再度、バージョンを有効化するコマンドを実行する。 $ nodebrew use vX.X.X 下記コマンドを実行して有効化したバージョンが正しい物になっている事を確認する。 $ nodebrew ls ・ ・ ・ >current: vX.X.X
インストール後に下記コマンドを実行してバージョンの有効化を行った。(インストールは正常に完了、X.X.Xはバージョン名)
$ nodebrew install-binary stable $ nodebrew use vX.X.X >vX.X.X is not installed
下記コマンドを実行する。
$ nodebrew --version
コマンドの出力の下部にある「# install」に記載されているコマンド$ nodebrew install vX.X.Xを実行する。
$ nodebrew install vX.X.X
再度、バージョンを有効化するコマンドを実行する。
$ nodebrew use vX.X.X
下記コマンドを実行して有効化したバージョンが正しい物になっている事を確認する。
$ nodebrew ls ・ ・ ・ >current: vX.X.X
