Windows Terminal のプロンプト表示がとても綺麗だったので cmd.exe の代わりに使っていくことにしました。*1 GitHub - microsoft/terminal: The new Windows Terminal and the original Windows console host, all in the same place! https://github.com/microsoft/terminal Windows Terminal Windows Terminal を cmd.exe の代わりに使うために必要なこと 右クリックメニューに「Windows Terminal をここでひらく」を追加する アイコンを付けたい場合 Shift キーを押下したときのみ表示したい場合 Windows Terminal を起動したときのデフォルトシェルを変更する 参考
背景 Git for Windows には MSYS2 の bash が同梱されています。 Windows での開発に必要なソフトウェアはほとんど scoop で導入できるのであまり困ることはありません。 しかし、tree のように MSYS2 なら提供されてる けど Git for Windows には同梱されていないちょっとしたツールもあります。 重ねて、MSYS2 の提供するパッケージを導入するための pacman も Git for Windows では省略されています。 ソリューション Git for Windows の開発環境 Git for Windows SDK を導入する Git for Windows SDK から pacman に関連するファイルだけを取り出す 1. Git for Windows の開発環境 Git for Windows SDK を導入する リポジ
Git for Windows では改行コードが「レポジトリー上は LF」「ワーキング ディレクトリーは CR LF」となるように、git config の core.autocrlf が true となる状態でインストールされる (インストーラーでデフォルトの [Checkout Windows-style, commit Unix-style line endings] を選択した場合)。 Windows 以外の文化圏の人は CR LF を見ると CR がゴミに見えるので、妥当な設定だろう。 標準設定の autocrlf が true のときに、レポジトリー上に CR LF なファイルが紛れ込んでいないか調べたり、紛れ込んだ CR LF を LF に変換したかったのだけど、この手順が少しややこしかったので記事にまとめておく。 (autocrlf を false にして clone した
これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか?がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.
Windows標準フォントについて、かなり昔の情報が出回っており、かつMicrosoft公式のページが検索でトップヒットしないことから、この記事を書きました。 この記事の初版・更新日はタイトル下に表示されている通りです。 急いで書いたので、誤りがある場合はTwitterやマシュマロから指摘ください。直します。 Windows標準フォントに関するライセンス Microsoft公式がライセンスについて記載したドキュメントがあります。 案内部分は日本語になってますが、コンテンツ自体は未翻訳のままなので英語で表示されます。 現在は「2017/10/27」と記載があります。 https://docs.microsoft.com/ja-jp/typography/fonts/font-faq このドキュメントは「游明朝」「游ゴシック」の開発元である字游工房からリンクされています。 http://www
マルチブート環境(デュアルブート・トリプルブートなど)でBluetoothデバイスを使う際の話題です。 Bluetoothデバイスを利用する際は通常「ペアリング」という作業が必要です。これは、初回接続時に128bitのリンクキーを発行して両者で共有し、通信相手のBDアドレスに紐付けておく仕組みです。これにより、次回接続時は同じリンクキーを使ってお互いを認証することができますから、面倒な手続きなしに利用することができます。 ところで、この仕組みはマルチブート環境ではうまく働きません。マルチブート環境ではそれぞれのOSが同じBluetoothアダプタを共有するため、Bluetoothデバイスからは各OSを区別できないのです。 もう少し具体的に説明します。マルチブート環境で1つのOSからデバイスをペアリングしたあとで別のOSを起動した状況を考えてみましょう。このとき、デバイス側から見るとペアリン
今風のやり方でWindows10 Homeをプログラミング環境として使えるようセットアップしたログです。5,6年前とは大きく状況が変わりました。 高解像度ディスプレイ タッチパッドを複数本の指でタップして使う cygwinやMSYS2ではなく、WSLのubuntu環境でコンソールを使う GUIアプリケーションはインストーラをサイトからダウンロードせず、chocoコマンドから入れる 文字コードをUTF-8で統一し、SJISフリーになれる 対象マシン 2018年7月現在、一番安く入手できる4KノートPC(非タッチスクリーン) ASUS X570Uで行いました http://kakaku.com/item/K0001042167/ 1. PC初期起動でのWindowsの設定 起動させると、Windows10のセットアップ画面で音声ガイドによる入力が促される。 セットアップ後すぐにアップデートが必
長い間、Windowsにはネイティブに動作するOpenSSHの実装が存在しない状況が続いてきた。コンソールアプリケーションもかなりトリッキーな実装を行っている。UNIX系オペレーティングシステムでは当たり前に実現できていることが、Windowsでは実現されてこなかった。 Windowsでも結果的に同じように見える振る舞いを実現できるが、UNIX系のオペレーティングが提供している仕組みとあまりに違いすぎるため、これまでUNIX系オペレーティングで提供されてきたコンソールに関連するコマンドの移植は進んでこなかった。しかし、2018年秋のWinodws 10アップデートでこの状況が大きく変わる可能性がある。 Microsoftは現在開発を進めているWindows 10に「擬似端末(Pseudo Console)」の機能を実装するようだ。実装する機能の詳細は「Windows Command-Lin
どういうツール 簡易的な仮想環境を作り、アプリケーションの動作を現在の環境から切り離すサンドボックスツールです。 レジストリとCドライブへのアクセスを仮想化することによって、 アプリケーションからシステム環境に影響を与えない様にする アプリケーションを単独で持ち運び可能にする などなどが可能になります。このツール自体はもちろんレジストリを汚しません。 どうやって DLLインジェクションからのIAT書き換えによるWin32 APIのフックにより動作を書き換えています。 IATを経由しない動的呼び出しもLoadLibraryやGetProcAddressを書き換えることで対処しています。 あくまで公開API(※)に渡す値を書き換えているだけで、本質的にディスクアクセスに干渉しているわけではない、 例えばWindows APIが内部で呼び出す様なより低レベルな処理を直接呼ばれた場合などは対処出来
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く