「Cygwin 3.5」が公開、Windows 7/8、Windows Server 2008 R2/2012への対応を終了／Windows上に擬似的なUNIX環境を構築する互換レイヤー
tmux/screen上でのnvimのescapeレスポンスを早くする - ymizushi のブログ
概要 tmux/screen 上で nvim を使用した際に、 escape/Ctrl-[ 入力に対するレスポンスが遅いため、これを解決する方法について記述します。 tmux/screen 上で nvim のescapeレスポンスを早くする $HOME/.tmux.conf 上で 以下の設定を追記する set -s escape-time 10 screen の場合は、以下の設定を $HOME/.screenrc に追記します。 maptimeout 10 vimなどで、 escape-time を 0 にしている例をよくみかけますが、nvimの場合0だとうまくいかず、 10程度のdelayを必要とします。 なぜこのような挙動になるのか tmuxではEscape入力があった際に、500msec のディレイの後にバックグラウンドのターミナルにコマンドを送信している。 上記の設定ではこのディレ
本の虫: Vimconf 2018のスタッフをしてきた
VimconfとはテキストエディターVimに関する発表をするカンファレンスだ。国際カンファレンスを意識し、発表の多くは英語で行われている。今年は他ならぬVimの作者であるBram Moolenaar本人を招待している。 去年のVimconf 2017には、雇用主のドワンゴがスポンサーをしていたので、スポンサーチケットで参加をした。 今年のVimconf 2018もドワンゴはスポンサーをしていたが、去年は私がスポンサーチケットを使ったので遠慮をして今年は別の同僚に譲った。自腹で行こうかと思ったが、チケット販売サイトはクレジットカードからの入金しか受け付けなかったので、購入を断念した。 残念、今年は参加できないか、と思っていたところ、運営スタッフから人手不足で当日のスタッフが足りないので来てくれと言われ、急遽スタッフとして受付のチケットもぎりをすることになったので、結果的に今年も参加することに
常用エディタをVisual Studio Codeに変えようかな(挫折する予感はある) - ただのにっき(2018-07-20)
■ 常用エディタをVisual Studio Codeに変えようかな(挫折する予感はある) 普段はさほどカスタマイズしていないvimでコード(やコード以外のなんでも)を書いていて、sshで乗り込んだ先でもローカルといっさい違いのない環境でものが書けるのはとてもいいし、困ったことは特にない。とはいえ、いろんな支援技術が入っている最近のエディタも使ってみたいんだよなぁ……とはもう何年も考えてるんだけど、ここらでえいやっと取り組んでみることに。とりあえず勢いのあるVS CODEがいいんじゃないの。 目標は、職場(Ubuntu Desktop)と自宅(Windows 10)で同じ環境にすること。WindowsではWSLを使っているから、基本的にLinuxに合わせるのがいい。ということで、まずはUbuntu 18に導入。これはらくちん。 ちゃんとハード3タブにできるんだ。えらいぞ、Microsoft
Systemd、ログアウト時にバックグラウンドプロセスをkillするよう既定値を変更へ | スラド Linux
Debianのバグトラッカによると、/etc/systemd/logind.confで設定できる「KillUserProcesses」の既定値が「no」から「yes」に変更されたようだ（Slashdot）。 たとえばsshで接続してscreenやtmuxで作業し、デタッチ・ログアウトしてしばらく経ってから作業結果を確認、といった作業で悲劇が起こる可能性が。 なぜこうなった……。 KillUserProcessesの値が「yes」に設定されていると、ログアウト時にsystemdが自動的にユーザーのバックグラウンドプロセスを削除するようになる。それによってこのような問題が発生するようになるという。
「Windows 10」で動作するUbuntuのBashシェル--その実現方法
「Windows 10」の次期大型アップデート「Redstone」では「Ubuntu」が動作することになりそうだ。 Microsoftと、Ubuntuの開発元であるCanonicalは、コンテナ内や仮想マシン（VM）上のLinuxではなく、「Windows Subsystem for Linux」（WSL）という、Windowsネイティブなライブラリとプログラムを使ってUbuntuを稼働させようとしている。 WSLは、1月にリリースされたWindows 10のプレビュービルド「Build 14251」でひっそりと追加された。そのリリースから数日後、lxcore.sysとlxss.sysという2つの新しいサブシステムが、WindowsプログラマーによるLinuxアプリケーション開発のためのブリッジなのではないかという指摘が、ある開発者によってなされた。その指摘は半分当たっていた。 WSLはそ
【Mac】zshをサブシェルで起動するとPATHがおかしくなる - よんちゅBlog
どういう状態かというと。 ★サブシェル起動前 $ printpath ← $PATHを表示 /Users/yonchu/.pythonbrew/bin /Users/yonchu/.rvm/gems/ruby-1.9.3-p286/bin /Users/yonchu/.rvm/gems/ruby-1.9.3-p286@global/bin /Users/yonchu/.rvm/rubies/ruby-1.9.3-p286/bin /Users/yonchu/.rvm/bin /usr/local/share/python /usr/local/mysql/bin /Library/Java/Home/bin /Users/yonchu/bin /Users/yonchu/dotfiles/bin /usr/local/bin /usr/local/sbin /usr/local/share
tmuxに慣れてみる: tmuxとGNU screenの違いなど
B! 216 0 1 0 ターミナルマルチプレクサとして GNU Screen を普段使っていますが、 tmux の方が活発に開発されてる様に見えたり 乗り移ってく人も沢山居るみたいなので気になって何度か試してみましたが、 イマイチ違いを吸収出来ずにScreenに戻ってきてました。 無理に移行する理由もそれ程無いですが、また試してみたので 取り敢えず違いなどのメモ。 設定ファイル Prefix (Escape) コマンドモード キー設定一覧 デタッチ/アタッチ キーバインド コピーモード/履歴スクロールバック Session/Layout/Window/Pane split 全Paneに同時入力 swap-paneの問題 Status表示 .bashrcなどでの判断方法 違いが理解できたら 設定ファイル screen tmux ファイル名 ~/.screenrc ~/.tmux.conf
GNU Screenバージョン4.2がリリースされました
2014年4月17日に待望の GNU Screen の新バージョン 4.2 がリリースされました。 [screen-devel] GNU Screen v.4.2.0Hello everyone, it is my pleasure to announce release of GNU Screen v.4.2.0 available at http://download.savannah.gnu.org/releases/screen/ (I will also upload to ftp.gnu.org as soon as my access is authorized) Many are probably using it due to their distributions packaging development versions, so they know at least
仙石浩明の日記: ssh-agent を screen の中から使う方法
GNU screen の バグ報告を行なう ついでに screen-devel ML に参加したら、 次のようなメールが ML に流れてきた: There is a much simpler solution http://www.2701.org/archive/200406150000.html The key is that SSH_AGENT need not point to a socket, it can point to a symbolic link to a socket. なるほど～ ssh-agent と通信するための UNIX ドメイン ソケット を指す (パス名固定の) シンボリック リンクを作るようにしておけば、 環境変数 SSH_AUTH_SOCK には、そのシンボリック リンクのパス名を 設定しておけば済むので screen の中で ssh を使うとき便利
OSXでのzshにおけるPATH設定
普段からログインシェルを zsh にして.zprofileでPATH設定をしているのですが、OSXでscreenを起動した際にPATHの順番がおかしくります。 どうやら/etc/zshenvで実行されるpath_helperが変なことやっているようです。 「/etc/pathsおよび/etc/paths.dからPATHを作り出し、元からあったPATHから重複を除いたものを後ろにつける」 というのが path_helper の動きらしいですが、このせいでscreen実行時（サブシェル起動時。zshenvが実行されるタイミング）にPATHの順番が入れ替わってしまいます。 というわけでこれを回避するために.zprofileでのPATH設定から.zshenvでの設定に変更し、サブシェルでも（比較的）綺麗なPATHとなるよう以下のように定義しました。 （zshの設定はOSXとdebianで共通のもの
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
byobu をはじめよう « blog.udzura.jp
ずっと GNU screen を使ってギ～クを気取りたかったんですが、複雑怪奇な .screenrc などに関するバッドノウハウが怖くて（この辺 zsh 移行とかでも同じようなことが言えそう）何度か挑戦しては挫折していたんです。 でも、ここ数か月ぐらい byobu を導入していて、普通に長いこと使えているし大変快適なので、今回ざっくり紹介してみようかな～とか思います。 byobu とは Ubuntu Manpage: byobu byobu in Launchpad Byobu is a Japanese term for decorative, multi-panel screens that serve as folding room dividers. As an open source project, Byobu is an elegant enhancement of the
screenに関するtips - Linuxとかプログラミングの覚え書き -
unix使いには、便利なscreenですが、トラブルもあります。 トラブル毎に原因と解決方法を整理してみました。 以下、screen の コマンドキーは、 デフォルトの "C-a" であるとします。設定で別のキーにしている場合は適宜読み替えてください。 時々フリーズする 症状: screen 経由で emacs を使っていると端末がかたまる場合がある。C-x C-s や C-s を押すと固まる。 症状: 時々フリーズする。キーを受け付けなくなる。C-q や C-a C-q を押すと復帰する。 原因: "C-a f"を押すなどして、フロー制御が有効なモードに切り替わったため。 解決方法: "C-a f"を押し、フロー制御をOffにすれば良い 参考URL: http://kyoto.cool.ne.jp/kinoka/pc/screen.html http://uragoya.com/2007
screen(だけ)の時代は終わり。tmuxでリモートコンソールを便利に使うTips
でサクっとインストールできます。tmuxコマンドをタイプすると、コンソールが表示されると思います。 ○ よく使うtmuxコマンド 私は下記のコマンドをよく使います： tmux attach - すでに開いたセッションにアタッチする tmux list-windows (C-b w) - ウィンドウの一覧を取得する tmux new-window (C-b n) - 新しいウィンドウを作る tmux detach-client (C-b d) - クライアントをデタッチする tmux list-keys (C-b ?) - キーバインドの一覧を表示する tmux next-window (C-b n) - 次のウィンドウを表示する tmux previous-window (C-b p) - 前のウィンドウを表示する tmux kill-window (C-b k) - ウィンドウを強制的に
ログアウトしてもバックグラウンド ジョブを継続する方法
はじめに SSH 接続で時間の掛かるシェルスクリプトをバックグラウンドで走らせて帰りたいのに、SSH 接続を切るとジョブが死んでしまいます。SSH 接続に限らず目の前の OS からログアウトしたりターミナル エミュレータを終了しても同じ現象が起こります。 この症状は正常です。なぜなら、バックグラウンド ジョブを起動したプロセス(ログイン シェル)が子プロセスである該当のバックグラウンドジョブをハングアップ シグナル( HUP )によって終了させるからです。 シェルスクリプトを起動した親プロセスは子プロセスの終了状態を監視しています。ですからログアウトして親プロセスであるシェルが終了すると子プロセスはゾンビ プロセスとなってしまうので親プロセスとなるシェル(ログインシェル)は子プロセスであるバックグラウンド ジョブを kill ( kill -HUP ) するのです。 nohup コマンド
高密度小池 ／ zsh の謎の挙動に悩まされていました
zsh の謎の挙動に悩まされていました nohup unko としてプログラムを起動した場合、端末を閉じたり exit コマンドを発行した場合にもそのまま動いていて欲しいものですが、 zsh 上ではこれも終了されてしまう。 しかし、シェルスクリプトを書いてその中で nohup していた場合は端末や zsh を殺しても大丈夫。 ちょっと調べたら答えがあった。 端末を殺した場合のフロー 端末が殺される→中で実行しているシェルに SIGHUP が送られる→シェルがよろくやる んでこれが bash の場合は SIGHUP を送らない のだけど zsh の場合は 子プロセス全部に問答無用で SIGHUP を送る ので、 nohup していても殺されてしまう。 シェルスクリプトの中で nohup していて死なないのは、 端末の死→ zsh にSIGHUP が来る → zsh
zshとSIGHUPとその設定 - 技術メモ帳
shell と SIGHUP - odz buffer 関連: 一度 tty から起動したプロセス (csh/ksh 版) - にぽたん研究所 なるほど。zshではデフォルトだと 終了時にSIGHUPが送信されるらしい。 手元のbash2.0で試してみたら終了時にSIGHUPが送信されなかった。 zshで終了時に警告を出さないようにするには、 setopt nocheckjobs とすればよいようだ。 あと、zshにはいきなりdisownの状態(job tableに加わらない状態)で バックグラウンド実行する &! という記法がある。 SIGHUP送られない。 % perl nohup.pl &! % exit % pgrep -fl nohup.pl 524 perl nohup.pl -- 余談だが、zshではsetoptに指定するオプション名に 好きなだけアンダーバーをつける事が出来
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jondruse/screeninator: Manage complex screen sessions easily.
