Cygwinの$PS1で関数を使うと構文エラーが発生した
個人Mac環境では、Bashプロンプトの表示をカスタマイズしています。
※これ自体はどなたかの設定をほぼ丸パクリさせていただいたものですが、入手元を失念してしまいました
で、同じものをgnupackのCygwinでも使おうとしたところ、何やらエラーが発生。
command substitution: 行 1: 予期しないトークン `)' 周辺に構文エラーがあります command substitution: 行 1: `prompt_git)'
どうやらカレントディレクトリのGitステータスをプロンプトに表示する関数でエラーが発生しているもよう。
調べていると、同じ現象に対処された方を発見。
この記事を参考に、「 $''
でエスケープシーケンスを評価する」の方法を使い、
PS1+="\n" # Newline
となっていた箇所を
PS1+=$'\n' # Newline
に変更したところ、動くようになりました。
変更後のgnupack用の設定は以下のような感じ。
- 作者: 三宅英明,大角祐介
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2017/06/08
- メディア: Kindle版
- この商品を含むブログを見る
Windows 10デビューしたのでgnupackとChocoletyで環境構築してみた
去年の夏に転職したのですが、気付いたらあっという間に一年経っていました。
今の会社では、仕事で使うPCをひさびさにWindowsにしたので、そのときにやった環境構築について、当時のメモを振り返りつつまとめておくことにしました。
Windowsを使うことにした理由
スマートフォンアプリ系の開発に携わるようになってからは公私共にMacに切り替えていたので、まともにWindowsを使うのは7~8年ぶりくらいです。(最後に使っていたのはWindows XP)
特に開発目的ということで考えると、Unix系ツールとの親和性などもあり、使い慣れているMacの方がすぐにパフォーマンスを発揮できると思う一方で、最近のMicrosoftが提供する開発向けのサービスやツール類の充実具合も気になっていたり、さらにBash(Ubuntu) on Windowsも来るということで、ここいらで触っておくのも良いかなと思い、スイッチすることにしました。
最初に欲しいもの
新しい会社に行って、いざPCをセットアップすることになったのですが、久しぶりのWindowsということもあり、さて何を入れたら良いものかと途方にくれることに。
そこで、個人的に環境を作る際に最初に欲しいものを考えてみたところ、以下の3つでした。
Macであれば、標準で2.はある程度サポートされていますし、3.はHomebrew & Homebrew Caskがあります。1.もHomebrewから導入できるので、かんたんに揃います。
そこで、Windowsで似たような環境を作るにはどうしたら良いのかを調べてみました。
なにはともあれEmacs、ついでにUnix系コマンドラインツール=gnupack
言うほど使いこなしているわけではないのですが、かれこれ10年以上はテキスト編集をEmacs中心でやっていることもあり、個人的にこのキーバインドが使えないと作業効率が落ちるのです。
過去にWindowsを使っていた際は、Windows向けEmacsクローンであるMeadowを使っていたのですが、残念ながらMeadowは数年前に開発が止まってしまっていたので、今回改めてWindows用のEmacsを探すことに。
すると、これも昔使っていたCygwinと、Emacsの環境を一括で作ってくれる gnupack というものを発見したので、これを使ってみることにしました。
ソフトウェア管理ツール=Chocolatey
Windows系のソフトウェア類の導入ですが、Macで言うところのHomebrew Caskのようなものとして、 Chocolatey というものがあるというのを耳にしていたので、これを使ってみることにしました。
gnupackでCygwin + Emacs環境を作る
まずは、gnupackの環境を作ります。
基本的にアーカイブをダウンロードして任意の場所に展開し、いくつか必要なPATHなどを通せばそれで導入完了なので、非常に簡単でした。
以下、いくつか個人的にポイントだったところをメモ。
gnupackでCaskは扱えるのか
導入にあたり気になったのは、最近Emacsのパッケージ管理に使っている Cask が、gnupack環境でも使えるかどうか。
Caskのサイトを見たところ、WindowsでCaskを使う場合、Pythonを別途インストールする必要があるとのこと。
Windows Installation and Setup
幸い、gnupackは用途に応じて選べるように「basic」と「devel」の2種類のパッケージで提供されており、その「devel」にはPythonが含まれているので、こちらを選択すれば問題ありませんでした。
gnupack環境構築後、Cygwin上で Manual installation の手順を実施すればOK。
1点だけ、gnupackには curl
が含まれていなかったので、それは apt-cyg install curl
で追加しておきました。
PythonへのPATH関係も通っているので、あとはCaskでダウンロードされるファイル類を保存する場所を追加しておけば、大丈夫でした。
HOMEをどこにするか
gnupackパッケージのダウンロードとインストールは gnupack Users Guide の「使い方」に記載されているとおり。私が導入したのは 13.06-2015.11.08
というバージョンでした。
とりあえずgnupackは C:\gnupack_devel
に展開。
その場合、gnupackのデフォルトでは C:\gnupack_devel\home
が HOME
になります。(これは設定ファイルで変更できます)
一般的に考えると、Windowsのユーザーフォルダ C:\User\<USER NAME>
をHOMEにした方が違和感が少ないのかな、と思いつつ、何か副作用があるかもしれないので、まずはデフォルトの設定で運用してみることにしました。
.emacsか、customizeか
gnupack Emacsの初期設定は <gnupack root>\home\.emacs.d
にあります。
個人Macで使っている、 これまで丹念に育ててきた.emacsもGitHubにある のですが、gnupackはある程度設定をしてくれているようだったので、それとは別に管理することにしました。
別にしたのは、MacとWindowsで細部の設定が変わりそうという点と、今まであまり使っていなかったcustomizeを積極的に使ってみようと思ったからです。(正直に言えば、gnupackのinit.elに欲しい設定をひとつひとつ移植していくのが面倒だったからですが…)
また、gnupackはpackage.elも導入済なので、 list-packages
で必要なライブラリもすぐに追加することができました。
小指対策
Emacs使いと言えば左手小指を駆使することになるので、これも昔お世話になったCtrl2capを導入して、Caps LockキーをControlに置き換えておきます。
Sysinternalsとか使うの、超ひさびさ。昔はMicrosoft管轄ではなかったんですよねー。
Process ExplorerとかProcess Monitorとか、お世話になっていました。
Chocolatey
次は、Macで言うところのHomebrew Cask的なものであるChocolatey。
Windowsにもこんなのができていたのかーと思いつつ使ってみています。
若干不安定(インストールに失敗するものがある)だったり、なかなか更新されないパッケージがあったりする点がありますが、ある程度は欲しいソフトウェアが自動で入れられるので、これも便利ですね。
Chocotetyにあっても、バージョンが最新かどうか確認してみて、新しいものに追従できていなそうなものは手動で導入するようにしました。
キーバインド
Macに移行したときは半角/全角切り替えキーがなくて戸惑いましたが、Macから返ってくると、もはやそんなキーがあったことを忘れているくらい、変換/無変換キーに指が慣れてしまっていました。
Windowsの変換・無変換キーでIMEの有効無効をMac風に操作する | karakaram-blog
おわり
と、(もう一年くらい前ですけど)最初の環境構築はこんな感じでした。
今のところベースはほとんど変わっていないので、再セットアップをすることになっても、とりあえずこのやり方でいけそう。
Xperia Z3の機種変更でタップ&ゴーを使ってデータ移行してみた
メインで使っているスマートフォンであるXperia Z3、2014年の秋ごろに機種変更したものですが、1年くらいたったころからタッチディスプレイの反応が悪くなってきていたのですが、いよいよ操作もおぼつかない状態になってきたので、先日とうとう修理に出すことに。
修理に出している間は代替機を借りていたのですが、そのときに現端末のデータを移行するにあたり、Android 5.0から搭載されたタップ&ゴーという機能を初めて使ってみたところ、かなり便利だったので、感動を記しておくことにしました。
タップ&ゴー
タップ&ゴーを使うには、移行先の端末がAndroid 5.0以降である必要はありますが、移行元はNFCが搭載されていれば4.0以降の端末で使えるそうです。
そう言えばXperia Z3も最初に機種変更した当初は4.4だったので、その前に使っていたGALAXY S3から移行するときには、タップ&ゴーは使えなかったのでした。
移行できる情報
タップ&ゴーで移行できる情報は以下のようなもの。
このうち、アプリのデータというのはどこまで復元されているのかはよくわかりませんでした。
移行のやり方
移行先端末のセットアップを始めるとタップ&ゴーの案内が出てくるので、移行元端末のNFCを有効にした状態で2つの端末を背中合わせにすると、確認音が鳴って、移行先端末で処理が開始されます。
うまくいかないときは、設定→その他の設定→NFC/おサイフケータイ設定へ進んで、 Reader/Writer,P2P と Androidビーム がONになっているか確認すると良いようです。
あとは画面の処理に従っていくだけですが、ここで移行元で使っていたGoogleアカウントを移行すると、その後、インストールしていたアプリが自動的に移行先の端末でもインストールされ始めました。
※なお、自動的にインストールが開始されてしまうので、モバイル通信ではなく、Wi-Fi環境下で実施するのが良いと思います。
また、端末セットアップを開始した直後は(まだ移行していないので)自宅Wi-Fiに明示的に接続しましたが、タップ&ゴーで移行が終わったあとは、会社のWi-Fiなど、以前に使ったことがあるアクセスポイントには、パスワードを入れなおすこともなく繋がりました。
そういえば、アカウントには2段階認証をつけていましたが、認証コードは要求されませんでした。
注意点
私の場合、プライベート用や開発用などでGoogleアカウントを複数使っているのですが、初めそれらを一括して移行しようとしたところ、アプリの復元などがうまく動きませんでした。
おそらく、タップ&ゴーでアカウントを移行するときに、最初に出てきたアカウントがメインということで扱われてしまうようですが、それが普段アプリのインストールなどに使っているのが別のアカウントであった場合、アプリの復元がおこなわれないようです。
移行対象のアカウントを選択するときにアルファベット順に出てくるのですが、そのせいでサブのアカウントが最初に出てきてしまい、そのまま進めてしまうと、このような状況になります。
そこで、タップ&ゴーで移行するアカウントはメインで使っているもののみにして、他のアカウントはセットアップ完了後に追加するようにしたところ、うまくアプリも復元されました。
感想
修理に出す前は、初めは移行が1回で済むリフレッシュ品へ交換しようと思っていました。というのも、その場合は修理している間に貸し出される代替機へアカウントを移行して、修理が終わったらまた元の端末に移行しなければならないので、二度手間だなーと思ったからです。
ただリフレッシュ品を申し込もうとしたところ、Xperia Z3の在庫がないため、Z4になってしまうとのことでした。
機種としては新しいし、スペック自体は上がるものの、逆に高性能なCPUの影響なのか、発熱問題があったりバッテリー駆動時間が短いらしいという噂を聞いていたので、悩んだ末に修理に出すことにしたのですが、この場合は代替機との間でデータ移行を2回もやらなければいけないのが非常に面倒に思っていました。
ですがタップ&ゴーのおかげで、一番面倒くさい必要なアプリの一括インストールが自動化されたので、移行が非常に楽になりました。
個々のアプリの設定をやりなおすのも面倒ですが、まあ必要になったときに随時やるようにしていけば、なんとかなりそうです。
参考
LINE BOT事始め&倍返しBotを作ってみた
初回分には乗り遅れてしまったのですが、追加募集が始まったようなので応募してみました。
【LINE】「LINE BOT API Trial Account」の追加募集を開始 | LINE Corporation | ニュース
2016/6/9現在、追加募集分枠はまだ終了していないようです。
とりあえずどんなものか動かしてみようと思い、手軽そうなHeroku環境に構築してみました。
制限事項
事前準備
LINEアカウント
- メールアドレスが登録されていること
BOT用に用意する情報
後で変更できますが、あらかじめ用意しておくと迷わなくて良いかと。
Herokuアカウント
- アドオンを使うため、クレジットカードが登録済みであること(無料範囲内で利用可能)
利用登録の流れ
ざっと流れだけメモ。
- LINE Business Center へアクセス
- BOT API Trial Accountのページヘ行き、ページ下部に設置されている「利用開始」ボタンをクリック
- 認証画面へ遷移するので、自分のLINEアカウントでログインする
- 初回はLINEアプリ側で認証コードの確認が必要
- LINE Business Centerで使うメールアドレスの入力
- 入力したメールアドレス宛に登録用URLが届く
- URLをたどるとアカウントのプロフィール・会社/事業者情報入力画面になる
- 入力が終わるとBusiness Centerの管理画面になるので、「ビジネスアカウントを作成する」へ進む
- アカウント名とアイコン画像をアップロードして完了
- ビジネスアカウントの詳細画面になるので、あらためてBOT API Trial Accountを「始める」へ進む
- BOT API Trial Accountの説明画面になるので、画面下部の「利用開始」へ進む
- Terms and Conditions of Use(英語)を確認して問題がなければ「AGREE」へ進む
- Create BOT API Trial Account画面になるので、名前とアイコン、Providerを確認後、「Create」
- BOTのBasic information画面になるので、以下の情報をメモ
- Channel ID
- Channel Secret
- MID
Basic information画面にフレンド追加用のQRコードもあるので、必要なら保存しておきます。
アカウントの作成とBOTの登録はここまで。
サーバーの準備ができた後、同じ画面内にある「Callback URL」と左側のメニューにある「Server IP Whitelist」の登録をおこなうことになります。
基本的にドキュメントと画面のとおりに進めば、特に迷わずに登録できます。
サーバー(Heroku)準備
Heroku上に新しいアプリを作成し、そのリポジトリをクローンしておきます。
$ heroku create $ heroku git:clone -a <app name> $ cd <app name>
既存のBOTサーバーが実装済かつGit管理している場合は、そのローカルリポジトリで heroku git:remote -a <app name>
でremoteを追加しておきます。
固定IPの取得
LINE BOT APIを叩くサーバーは、そのIPアドレスをあらかじめWhitelistに登録しておく必要があります。
通常Herokuは固定IPになっていないようですが、Fixieというアドオンを使うことで固定IPを得られるよう。
$ heroku addons:create fixie:tricycle Creating fixie-hogehoge-99999... done, (free) Adding fixie-hogehoge-99999 to fugafuga-piyopiyo-9999... done Setting FIXIE_URL and restarting fugafuga-piyopiyo-9999... done, v3 Your IP addresses are xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx Use `heroku addons:docs fixie` to view documentation.
上記の xxx.xxx.xxx.xxx
に表示されたIPアドレスを、先ほどのServer IP Whitelistに登録します。
BOT実装時は、 FIXIE_URL
という環境変数にFixieが提供するプロキシのURLが登録されているので、これを経由して通信します。
Bot実装、サーバー登録
APIドキュメントはこれ。
LINE Developers - BOT API - Overview
いい加減ただのオウム返しだけではつまらないので、とりあえずメッセージを倍にして返すというBotにしてみました。(たいして変わらないじゃん…と思ったわけですが、multiple messagesの送り方で少しハマったりしました)
ソースはこんな感じです。
umi-uyura/node-linebot-doublethapayback
これをクローンしたHerokuのリポジトリにコピーして、追加&コミット後、Herokuへプッシュします。
$ git add . $ git commit -m 'Initial commit' $ git push -u heroku master
環境変数の登録
今回は以下のような環境変数を用意しました。
$ heroku config:set LINEBOT_CHANNEL_ID=<Channel ID> $ heroku config:set LINEBOT_CHANNEL_SECRET=<Channel Secret> $ heroku config:set LINEBOT_MID=<MID>
Callback URLの登録
サーバーの準備ができたところで、Callback URLをBOTに登録します。
Herokuを使う場合、 https://<app name>.herokuapp.com
というようなURLになりますが、そこにHTTPSのポート番号を明示的にしているするのと、LINEサーバーからの通信を受け付けるパスを追加します。
自分の場合は、 /callback
というパスにしたので、以下のようなURLになりました。
https://<app name>.herokuapp.com:443/callback
これを管理画面に登録して、「VERIFY」を押し、Successと表示されれば問題なさそうです。
友だち登録
アカウント作成時に入手していたQRコードをLINEアプリで読み取って友だち登録すれば、BOTにメッセージを送れるようになります。
少し気になったのは、「個人を選択した際は本名を入力してください。」と書いてあったので一応本名入れたのですが。
友だち登録時に、それが出てしまうんですよね。
トライアルですし、一般公開しない範囲なら良いのですが、不特定多数に公開するとなると、少し気が引けるかも。
いちおう、ビジネスアカウントに登録しているプロダクトが全て使われていないときであれば、名前を変更できるようです。
倍返しの様子
倍返しBOTは、送ったメッセージを倍にして(要するに2回)送ってきます。
調べながら書いていたらソースが長くなってきたので、現状はテキストとスタンプのみの対応。
BOTからは公式のスタンプしか使えないので、それ以外を送られた場合は「タイオウシテイマセン……」と返し、テキストとスタンプ以外のメッセージを受けると「カイドクフノウデス……」と返すというだけです。
まとめ
とりあえず基本的な仕組みはなんとなくわかったので、実戦の機会があれば、もっと深掘りしてみたい。
参考
- BOT API Trial Accountのご紹介 | LINE BUSINESS CENTER
- とりあえずLINE BOT APIでオウムを作ってみた - Qiita
- LINE BOT をとりあえずタダで Heroku で動かす - Qiita
- 【LINE BOT】 アカウント設定の仕方 〜アカウントを取ってみた!〜 - Qiita
現場のプロが教えるWeb制作の最新常識[アップデート版] (知らないと困るWebの新ルール)
- 作者: 久保知己,酒井優,塚口祐司,前川昌幸
- 出版社/メーカー: エムディエヌコーポレーション
- 発売日: 2016/06/01
- メディア: 単行本
- この商品を含むブログを見る
Asana用BitBarプラグインをPythonで書きなおした
先日作った、Macのメニューバーに色々な情報を表示するBitBarに、プロジェクト管理サービスのAsanaのタスクを表示するためのプラグイン。
慣れているNode.jsベースで作ってみたものの、 他のBitBarプラグイン を見てみると、基本的に1スクリプトに収めている感じ。
Node版はnpmで事前のインストールが必要だったり、設定ファイルを切り出しているし、そもそもNode.jsはMac標準で入っていないしと、なんとなくBitBarの思想と合わない感じがしたので、OS標準で搭載されていて最近触ってみているPythonで書きなおしてみました。
作るにあたって、Pythonにも Asana公式のクライアントライブラリ があったのですが、依存関係は少ない方が良いだろうということで、これは使いませんでした。
できたもの
とりあえずGitHubにアップ。
もう少し使ってみて問題なさそうなら、本家に掲載をお願いしてみようかと画策中。
使い方
動作確認環境
項目 | バージョン | 備考 |
---|---|---|
Mac OS | 10.11.5 (El Capitan) | |
Python | 2.7.11 | Homebrew版 |
BitBar | 1.9.1 | - |
インストール
GitHubリポジトリ から bitbar-tasks.py をダウンロードして、BitBarプラグインフォルダへコピーします。
実行間隔を含めたファイル名に変更し、実行権限も付与します。
詳細は Installing plugins を参照。
設定
設定項目は、 import
がたくさん並んだ下のあたりにある以下の変数です。
Key | Value |
---|---|
PERSONAL_ACCESS_TOKEN |
Personal Access Token Asanaのサイトから取得します(後述) |
WORKSPACE_ID |
ワークスペースID はじめはブランクでOK |
DISPLAY_RANGE_MONTH |
(optional) 表示範囲 月単位で、◯ヶ月先までの締め切りが設定されているタスクを表示します。 未指定の場合は 2 としています |
LOCALE |
(optional) 日付フォーマットを決めるロケール指定ja_JP を指定すれば YYYY/MM/DD(曜日) 形式で表示します |
MENUBAR_IMAGE |
(optional) メニューバーに表示するアイコンイメージ Base64エンコードした画像データ |
前回設定していたAssignee ID(担当者ID)はPersona Access Tokenがわかれば取得できるので、今回は設定は不要としました。
Persona Access Tokenの取得
これについては 前回の記事 参照。
ワークスペースIDの取得
Node版は別コマンドを用意していましたが、単独のスクリプトなるとそうもいかないので、どうしようかと他のプラグインなどを見ていたところ、メニュー選択時に外部スクリプトを呼び出す機能を使って自分自身をを再度呼び出すことで追加の処理を行うような仕組みを使っていたので、それを利用してみることにしました。
というわけで、初回にスクリプトのワークスペースIDをブランクで実行すると、Persona Access Tokenに紐付いたワークスペース情報が表示されます。
表示したいワークスペースを選択すると、そのワークスペースIDがクリップボードにコピーされます。
コピーされたワークスペースIDを、上記のスクリプト内の WORKSPACE_ID
にセットしてください。
タスク一覧の表示
ワークスペースIDをセットして再実行すると、タスクが表示されると思います。
Node版と少しだけ変更したのは、ワークスペース名の横に表示タスクの担当者(Assignee)を出してみたのと、当日のタスクは緑色で表示するようにしたこと。自分がAsanaを複数アカウント使うようになったので、パッと見でどのアカウントのワークスペースだったかを知りたかったからというのがあります。
それ以外の表示内容については、Node版 と同じです。
複数のワークスペースを扱う
1スクリプトにしたおかげで、この点もシンプルになりました。
複数のワークスペース分のタスク表示が必要な場合は、別ファイル名でコピーして、表示したいワークスペースIDをセットすればOKです。
感想
Asana APIとはUTF-8でやりとりしますが、Pythonの文字列はUnicodeとなるということで、その文字列エンコーディングの扱いに少しハマりました。
結局、日本語が入る可能性がある担当者やワークスペース名前関連を扱うところで .encode("utf-8")
をしまくっているのですが、もう少しスマートな方法がありそう。
- 作者: Guido van Rossum,鴨澤眞夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/03/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
GitHub/Bitbucketなどで使うSSHキーを複数アカウントで使い分ける
個人でもGitHubやBitbucketのアカウントを持っている場合に、会社や別の会社のリポジトリにも同じサービスのアカウントを作ることになると、SSHキーをそれぞれに用意する必要がでてきます。
その際のconfigの書き方を毎回調べているので、自分用にメモ。
なお、環境はMacです。
SSHキーの生成
ssh-keygen
コマンドを使ってSSHキーを生成します。
$ ssh-keygen -t rsa -C '<アカウント名やメールアドレスなど>' -f ~/.ssh/<ファイル名>
実行するとパスフレーズを求められるので、設定します。
ファイル名を分けておくことで、同一サービスに複数のファイル(アカウント)で利用することができます。
SSH公開鍵をサービスへ登録
SSH公開鍵をクリップボードへコピー
$ pbcopy < ~/.ssh/<ファイル名>.pub
GitHubへの登録
Bitbucketへの登録
SSH configの設定
同一サービスを複数のアカウントで利用する場合、 github.com
や bitbucket.org
へのリクエストがどのアカウント(つまりどのSSHキー)のものか区別できなくなってしまいます。
そこでSSHの設定ファイルで、複数アカウント用にエイリアスを作成します。
個人用のSSH configは ~/.ssh/config に作成します。
Host github.com HostName github.com IdentityFile ~/.ssh/github_rsa IdentitiesOnly yes Host hoge-github.com HostName github.com IdentityFile ~/.ssh/hoge_github_rsa IdentitiesOnly yes Host bitbucket.org HostName bitbucket.org IdentityFile ~/.ssh/bitbucket_rsa IdentitiesOnly yes Host fuga-bitbucket.org HostName bitbucket.org IdentityFile ~/.ssh/fuga_bitbucket_rsa IdentitiesOnly yes
IdentitiesOnly
は、その Host
へ接続する際に指定した IdentityFile
だけを使うという設定です。
これを付けておかないと、後述する接続確認の際、すでに同一の HostName
へ接続したアカウントがあった場合、そのSSHキーを利用してしまうようなので、厳密にするために付けています。
接続確認
SSH configが正しく設定できたかどうか、各サービスへSSHで接続できるか確認します。
GitHubの場合
$ ssh -T git@hoge-github.com Hi <ユーザー名>! You've successfully authenticated, but GitHub does not provide shell access.
Bitbucketの場合
$ ssh -T git@fuga-bitbucket.org logged in as <ユーザー名>. You can use git or hg to connect to Bitbucket. Shell access is disabled.
上記 ユーザー名 の部分に、保有している別のアカウント名が表示された場合は、すでに認証した別のアカウントのSSHキーが使われている状態です。
上記のSSH configの設定を見なおして、該当 Host
の設定に IdentitiesOnly
を付けて再実行することで、本来のアカウントで接続確認することができます。
cloneの方法 / 既存リポジトリの変更
~/.ssh/config の Host
を元ドメイン以外にしたものをcloneする場合は、通常であれば以下のように実行するところを、
$ git clone git@github.com:hoge/hoge-example.git $ git clone git@bitbucket.org:fuga/fuga-example.git
ホスト名部分を設定した Host
に合わせて変更して実行します。
$ git clone git@hoge-github.com:hoge/hoge-example.git $ git clone git@fuga-bitbucket.org:fuga/fuga-example.git
既存リポジトリ
<プロジェクト>/.git/config を編集します。
... [remote "origin"] url = git@github.com:hoge/hoge-example.git ...
を、
... [remote "origin"] url = git@hoge-github.com:hoge/hoge-example.git ...
のように書き換えることで対応できるもよう。(試していない)
参考
- Generating an SSH key - User Documentation
- Add an SSH key to an account - Atlassian Documentation
- SSH_CONFIG (5)
- [mac]ssh-agentの鍵情報をキーチェーンに保存する – hello-world.jp.net
小悪魔女子大生のサーバエンジニア日記 ― インターネットやサーバのしくみが楽しくわかる
- 作者: aico,株式会社ディレクターズ
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/18
- メディア: Kindle版
- この商品を含むブログを見る
Flycheckのエラーリストのフォーマットが変わっていた
Emacsの静的解析にはFlycheckを使っていますが、発生しているエラーの一覧を表示する flycheck-list-errors
の各フィールドの幅が微妙に見難かったので、ちょっとフォーマットを変更して使っていました。
最近Pythonを触り始めてから、どうもFlycheckのエラーリストが1行しか出ないなーと思ったら、いつの間にかエラー一覧のフォーマットが若干変わっていました。
当初は以下のようなフォーマットにしていましたが、
(defconst flycheck-error-list-format [("Line" 4 flycheck-error-list-entry-< :right-align t) ("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<) ("ID" 20 t) ("Message" 0 t) (" (Checker)" 8 t)])
この時点の最新版では、最後の "Message"
と "(Checker)"
が1フィールドにまとめられた形になっていましたので、それに合わせて設定も変更。
(defconst flycheck-error-list-format [("Line" 4 flycheck-error-list-entry-< :right-align t) ("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<) ("ID" 20 t) ("Message (Checker)" 0 t)])
デフォルトの感じから、
こんな感じで、 "ID"
の部分を読み取れる程度に広げています。
ふだん書いているJavaScript + ESLintでチェックしているときは大丈夫だったので、チェッカーの実装の違いによるものでしょうか。
そんな感じで、タプルなる存在に翻弄されている今日このごろです。
仕事ですぐ役立つ Vim&Emacsエキスパート活用術 (SoftwareDesign別冊)
- 作者: Software Design編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2016/04/09
- メディア: 大型本
- この商品を含むブログ (2件) を見る