Umi Uyuraのブログ

プログラミング関連の作業ログ

Cygwinの$PS1で関数を使うと構文エラーが発生した

個人Mac環境では、Bashプロンプトの表示をカスタマイズしています。

※これ自体はどなたかの設定をほぼ丸パクリさせていただいたものですが、入手元を失念してしまいました

dotfiles/bash_prompt

で、同じものをgnupackのCygwinでも使おうとしたところ、何やらエラーが発生。

command substitution: 行 1: 予期しないトークン `)' 周辺に構文エラーがあります
command substitution: 行 1: `prompt_git)'

f:id:umi-uyura:20170824234735p:plain

どうやらカレントディレクトリのGitステータスをプロンプトに表示する関数でエラーが発生しているもよう。

調べていると、同じ現象に対処された方を発見。

この記事を参考に、「 $''エスケープシーケンスを評価する」の方法を使い、

PS1+="\n" # Newline

となっていた箇所を

PS1+=$'\n' # Newline

に変更したところ、動くようになりました。

変更後のgnupack用の設定は以下のような感じ。

dotfiles-gnupack/bash_prompt

新しいLinuxの教科書

新しいLinuxの教科書

Windows 10デビューしたのでgnupackとChocoletyで環境構築してみた

去年の夏に転職したのですが、気付いたらあっという間に一年経っていました。

今の会社では、仕事で使うPCをひさびさにWindowsにしたので、そのときにやった環境構築について、当時のメモを振り返りつつまとめておくことにしました。

Windowsを使うことにした理由

スマートフォンアプリ系の開発に携わるようになってからは公私共にMacに切り替えていたので、まともにWindowsを使うのは7~8年ぶりくらいです。(最後に使っていたのはWindows XP

特に開発目的ということで考えると、Unix系ツールとの親和性などもあり、使い慣れているMacの方がすぐにパフォーマンスを発揮できると思う一方で、最近のMicrosoftが提供する開発向けのサービスやツール類の充実具合も気になっていたり、さらにBash(Ubuntu) on Windowsも来るということで、ここいらで触っておくのも良いかなと思い、スイッチすることにしました。

最初に欲しいもの

新しい会社に行って、いざPCをセットアップすることになったのですが、久しぶりのWindowsということもあり、さて何を入れたら良いものかと途方にくれることに。

そこで、個人的に環境を作る際に最初に欲しいものを考えてみたところ、以下の3つでした。

  1. なにはともあれEmacs
  2. Unixコマンドラインツール
  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\homeHOME になります。(これは設定ファイルで変更できます)

一般的に考えると、Windowsのユーザーフォルダ C:\User\<USER NAME> をHOMEにした方が違和感が少ないのかな、と思いつつ、何か副作用があるかもしれないので、まずはデフォルトの設定で運用してみることにしました。

.emacsか、customizeか

gnupack Emacsの初期設定は <gnupack root>\home\.emacs.d にあります。

個人Macで使っている、 これまで丹念に育ててきた.emacsもGitHubにある のですが、gnupackはある程度設定をしてくれているようだったので、それとは別に管理することにしました。

umi-uyura/dot.emacs.d_gnupack

別にしたのは、MacWindowsで細部の設定が変わりそうという点と、今まであまり使っていなかったcustomizeを積極的に使ってみようと思ったからです。(正直に言えば、gnupackのinit.elに欲しい設定をひとつひとつ移植していくのが面倒だったからですが…)

また、gnupackはpackage.elも導入済なので、 list-packages で必要なライブラリもすぐに追加することができました。

小指対策

Emacs使いと言えば左手小指を駆使することになるので、これも昔お世話になったCtrl2capを導入して、Caps LockキーをControlに置き換えておきます。

Ctrl2cap

Sysinternalsとか使うの、超ひさびさ。昔はMicrosoft管轄ではなかったんですよねー。

Process ExplorerとかProcess Monitorとか、お世話になっていました。

Chocolatey

次は、Macで言うところのHomebrew Cask的なものであるChocolatey。

Windowsにもこんなのができていたのかーと思いつつ使ってみています。

若干不安定(インストールに失敗するものがある)だったり、なかなか更新されないパッケージがあったりする点がありますが、ある程度は欲しいソフトウェアが自動で入れられるので、これも便利ですね。

Chocotetyにあっても、バージョンが最新かどうか確認してみて、新しいものに追従できていなそうなものは手動で導入するようにしました。

キーバインド

Macに移行したときは半角/全角切り替えキーがなくて戸惑いましたが、Macから返ってくると、もはやそんなキーがあったことを忘れているくらい、変換/無変換キーに指が慣れてしまっていました。

そこで以下の記事を参考に、Macキーバインドに変更。

Windowsの変換・無変換キーでIMEの有効無効をMac風に操作する | karakaram-blog

おわり

と、(もう一年くらい前ですけど)最初の環境構築はこんな感じでした。

今のところベースはほとんど変わっていないので、再セットアップをすることになっても、とりあえずこのやり方でいけそう。

まあ、次はできればBash on Windows中心に切り替えたいところですが。

Xperia Z3の機種変更でタップ&ゴーを使ってデータ移行してみた

メインで使っているスマートフォンであるXperia Z3、2014年の秋ごろに機種変更したものですが、1年くらいたったころからタッチディスプレイの反応が悪くなってきていたのですが、いよいよ操作もおぼつかない状態になってきたので、先日とうとう修理に出すことに。

修理に出している間は代替機を借りていたのですが、そのときに現端末のデータを移行するにあたり、Android 5.0から搭載されたタップ&ゴーという機能を初めて使ってみたところ、かなり便利だったので、感動を記しておくことにしました。

タップ&ゴー

タップ&ゴーを使うには、移行先の端末がAndroid 5.0以降である必要はありますが、移行元はNFCが搭載されていれば4.0以降の端末で使えるそうです。

そう言えばXperia Z3も最初に機種変更した当初は4.4だったので、その前に使っていたGALAXY S3から移行するときには、タップ&ゴーは使えなかったのでした。

移行できる情報

タップ&ゴーで移行できる情報は以下のようなもの。

  • Googleアカウント
  • インストールしていたアプリ
  • アプリのデータ
  • Wi-Fiパスワード

このうち、アプリのデータというのはどこまで復元されているのかはよくわかりませんでした。

移行のやり方

移行先端末のセットアップを始めるとタップ&ゴーの案内が出てくるので、移行元端末のNFCを有効にした状態で2つの端末を背中合わせにすると、確認音が鳴って、移行先端末で処理が開始されます。

うまくいかないときは、設定→その他の設定→NFC/おサイフケータイ設定へ進んで、 Reader/Writer,P2PAndroidビーム が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環境に構築してみました。

制限事項

  • 料金は無料
  • BOT API Trial Accountは1人1つまで
  • 友だち数は50人まで
    • BOT API Trial Accountの制限解除プログラムが開始され、最大5,000人まで拡張可能(ただし、今のところ法人向けのもよう)

事前準備

LINEアカウント

  • メールアドレスが登録されていること

BOT用に用意する情報

  • BOTの名前
  • 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コードもあるので、必要なら保存しておきます。

f:id:umi-uyura:20160609235021p:plain

アカウントの作成と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に登録します。

f:id:umi-uyura:20160609235035p:plain

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

環境変数の登録

BOT情報を環境変数に登録しておきます。

今回は以下のような環境変数を用意しました。

$ 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と表示されれば問題なさそうです。

f:id:umi-uyura:20160609235047p:plain

友だち登録

アカウント作成時に入手していたQRコードをLINEアプリで読み取って友だち登録すれば、BOTにメッセージを送れるようになります。

少し気になったのは、「個人を選択した際は本名を入力してください。」と書いてあったので一応本名入れたのですが。

f:id:umi-uyura:20160609235058p:plain

友だち登録時に、それが出てしまうんですよね。

トライアルですし、一般公開しない範囲なら良いのですが、不特定多数に公開するとなると、少し気が引けるかも。

f:id:umi-uyura:20160609235107p:plain

いちおう、ビジネスアカウントに登録しているプロダクトが全て使われていないときであれば、名前を変更できるようです。

倍返しの様子

倍返しBOTは、送ったメッセージを倍にして(要するに2回)送ってきます。

f:id:umi-uyura:20160609235118p:plain f:id:umi-uyura:20160609235126p:plain

調べながら書いていたらソースが長くなってきたので、現状はテキストとスタンプのみの対応。

BOTからは公式のスタンプしか使えないので、それ以外を送られた場合は「タイオウシテイマセン……」と返し、テキストとスタンプ以外のメッセージを受けると「カイドクフノウデス……」と返すというだけです。

まとめ

とりあえず基本的な仕組みはなんとなくわかったので、実戦の機会があれば、もっと深掘りしてみたい。

参考

Asana用BitBarプラグインをPythonで書きなおした

先日作った、Macのメニューバーに色々な情報を表示するBitBarに、プロジェクト管理サービスのAsanaのタスクを表示するためのプラグイン

umi-uyura.hatenablog.com

慣れているNode.jsベースで作ってみたものの、 他のBitBarプラグイン を見てみると、基本的に1スクリプトに収めている感じ。

Node版はnpmで事前のインストールが必要だったり、設定ファイルを切り出しているし、そもそもNode.jsはMac標準で入っていないしと、なんとなくBitBarの思想と合わない感じがしたので、OS標準で搭載されていて最近触ってみているPythonで書きなおしてみました。

作るにあたって、Pythonにも Asana公式のクライアントライブラリ があったのですが、依存関係は少ない方が良いだろうということで、これは使いませんでした。

できたもの

とりあえずGitHubにアップ。

umi-uyura/py-bitbar-asana

もう少し使ってみて問題なさそうなら、本家に掲載をお願いしてみようかと画策中。

使い方

動作確認環境

項目 バージョン 備考
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に紐付いたワークスペース情報が表示されます。

f:id:umi-uyura:20160524234338p:plain

表示したいワークスペースを選択すると、そのワークスペースIDがクリップボードにコピーされます。

f:id:umi-uyura:20160524234347p:plain

コピーされたワークスペースIDを、上記のスクリプト内の WORKSPACE_ID にセットしてください。

タスク一覧の表示

ワークスペースIDをセットして再実行すると、タスクが表示されると思います。

f:id:umi-uyura:20160524234357p:plain

Node版と少しだけ変更したのは、ワークスペース名の横に表示タスクの担当者(Assignee)を出してみたのと、当日のタスクは緑色で表示するようにしたこと。自分がAsanaを複数アカウント使うようになったので、パッと見でどのアカウントのワークスペースだったかを知りたかったからというのがあります。

それ以外の表示内容については、Node版 と同じです。

複数ワークスペースを扱う

1スクリプトにしたおかげで、この点もシンプルになりました。

複数ワークスペース分のタスク表示が必要な場合は、別ファイル名でコピーして、表示したいワークスペースIDをセットすればOKです。

感想

Asana APIとはUTF-8でやりとりしますが、Pythonの文字列はUnicodeとなるということで、その文字列エンコーディングの扱いに少しハマりました。

結局、日本語が入る可能性がある担当者やワークスペース名前関連を扱うところで .encode("utf-8") をしまくっているのですが、もう少しスマートな方法がありそう。

Pythonチュートリアル 第3版

Pythonチュートリアル 第3版

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.combitbucket.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/configHost を元ドメイン以外にしたものを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

...

のように書き換えることで対応できるもよう。(試していない)

参考

Flycheckのエラーリストのフォーマットが変わっていた

Emacsの静的解析にはFlycheckを使っていますが、発生しているエラーの一覧を表示する flycheck-list-errors の各フィールドの幅が微妙に見難かったので、ちょっとフォーマットを変更して使っていました。

umi-uyura.hatenablog.com

最近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)])

デフォルトの感じから、

f:id:umi-uyura:20160514234740p:plain

こんな感じで、 "ID" の部分を読み取れる程度に広げています。

f:id:umi-uyura:20160514234754p:plain

ふだん書いているJavaScript + ESLintでチェックしているときは大丈夫だったので、チェッカーの実装の違いによるものでしょうか。

そんな感じで、タプルなる存在に翻弄されている今日このごろです。