Windowsの最近のブログ記事

A5:SQL Mk-2 で Oracle Database に接続しようとしたところ、

NET: Network error (Cannot connect to server on host 'localhost':
対象のコンピューターによって拒否されたため、接続できませんでした。.
Socket Error Code: 10061($274D))
<Host = localhost:1521>

というエラーになってつながらない。

タスクマネージャーで見てみたら、確かに Oracle 関係が全然起動していない。

そこで、タスクマネージャーからサービス管理ツールを開き、「OracleOraDB21Home1TNSListener」を実行しようとすると、

ローカルコンピューターの OracleOraDB21Home1TNSListener サービスを開始できません。

エラー 1069: ログオンに失敗したため、サービスを開始できませんでした。

とエラーが出て起動できず・・・

20260703_taskmane4.jpg

Oracle の SYSTEM と SYS アカウントのパスワードを変更したのでそのせいかと思い(「Oracle Database 21c Express Edition (XE) をインストール」参照)OracleOraDB21Home1TNSListener のプロパティを開いて「ログオン」タブ選択。そこで新しいパスワード 'testpass01' をパスワードに入力したら、うまく起動するようになった。

20260703_taskmane7.jpg

・・・が、パスワードを変更したのは一昨日であり、昨日は正常に起動したぞ?

そもそも、「ログオン」タブの「アカウント」に入ってる「NT SERVICE\OracleOraDB21Home1TNSListener」って何?これ、アカウント???

Gemini君によるとこれは「仮想アカウント(Virtual Account)」と呼ばれる、Windowsがサービス専用に自動で管理してくれる特殊なアカウントで、通常 Windowsが裏側でパスワードを自動管理しているため、人間が手動でパスワードを入力する必要がなく、プロパティの画面ではパスワード欄は空にしとけばいいらしい。

なるほど。パスワードの確認欄があったのはそのせいね(^^;;; 俺は、単に NT SERVICE\OracleOraDB21Home1TNSListener アカウントの「新しいパスワード」を 'testpass01' にしただけの話か・・・(^^;;;

今度同様の状況になったら、その時にはパスワードには空値を設定しよう(笑)
あと、Windowsバッチ(.BAT)の書き方で違和感があるのが、ダブルクォーテーションの扱いである。

エスケープしない限り、ダブルクォーテーションは文字としてそのまま使われることはなく、文字列の範囲指定、つまり引用符(ダブルクォーテーションで囲んだ中身が有効)として使われる・・・という認識なんだけど Windowsバッチでは違う。

例えば Perl で

my $a = "ABC";
if ("$a" eq "ABC") { print "ok!"; }

としたとき(まあ、変数をわざわざ "" で囲むことはないけど、例としてね)、比較されるのは $a変数に収められた ABC という文字列と、"" で囲まれた ABC という文字列である。決して、"ABC" と "ABC" が比較されるわけではない。
"" とすれば、それはダブルクォーテーションで囲まれた文字が何もない(空文字)ということになる。

ところが Windowsバッチで、

IF %1 == "ABC" ( ECHO 同じです ) ELSE ( ECHO 違います )

なんて書いて引数に ABC を指定して' test.bat ABC 'ってバッチを起動すると「違います」と言われる。「え?"ABC" と "ABC" なのに?」でも、実際は ABC と "ABC" の比較になってるのだ。
改めて、' test.bat "ABC" 'と実行すれば、これは「同じです」と返ってくる。ダブルクォーテーションも単なる文字として判断されているので、これなら "ABC" と "ABC" の比較となるからだ。

上記の IF 文で、引数に何も指定しなければ「"ABC" の使い方が誤っています。」というエラーになる。

この場合、%1 は「空文字」ではなく「無」な状態となり、変数展開後、

IF == "ABC" ( ECHO 同じです ) ELSE ( ECHO 違います )

と書いたのと同じことになるのだ。書式として誤った形になっている。なんか気持ち悪い(^^;;;

なので、正しい対応(あとで書くが、これは単なる慣習である)

IF "%1" == "ABC" ( ECHO 同じです ) ELSE ( ECHO 違います )

と書く。そうすると、引数が指定されなかったときは、

IF "" == "ABC" ( ECHO 同じです ) ELSE ( ECHO 違います )

と書いたのと同じになるので、書式として正しい。む~ん・・・

上の例は、まるで変数や文字列を二重引用符(ダブルクォーテーション)で囲ったように見えるが、これは実は引用符ではない。そもそも、Windowsバッチには引用符という概念がない。

これは実際には

IF X%1X == XABCX ( ECHO 同じです ) ELSE ( ECHO 違います )

のように、ダブルクオーテーションではなくても良い。%1 が「無」の状態とならなければいいのだ。だから囲ってやる必要もなく、

IF X%1 == XABC ( ECHO 同じです ) ELSE ( ECHO 違います )

でいい。%1が空だったときに、何かしらの値がそこに残ればいいのだ。上の例であれば、「IF X == XABC」となり書式としては成立している。そこを「頭に X を置くのでは見栄えも悪いし」ということで、慣習的にダブルクォーテーションで囲っているだけの話だ。

この辺が日ごろ Windowsバッチに触れてない人間には気持ちが悪いのよね。

「引用符の概念がない」のもそうだけど、そのため空文字対策で変数を何らかの文字で囲ってやらないといけないときは慣習的にダブルクォーテーションを使う(人が多い)。これが俺のようにたまにしか Windowsバッチに触れない人間には「変数を引用符で囲む必要ないんじゃないの?」とトラブルの元となってしまうのである。

もう!ほんま Microsoft の設計思想、嫌い(^^;;; なんでこんな仕様にした?
Windows(てか、DOSって書いた方が正解?)のバッチファイル(BAT ファイル)を久しぶりに書かないといけなくなった。

つーか、「久しぶり」ってのがウソで、正直言うと自分で一から BAT ファイルを書いたことはほとんどない。そういう仕事を受けたことがないもんで。だいたい UNIX 系が多かったからなあ。

とりあえずメモしとく。

IF 文の ELSE は、必ず ") ELSE (" と書かないといけない。")" の後ろで改行して "ELSE" を書くとエラーとなる。
ELSE を独立した命令と判断し

'ELSE' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

なんてことに・・・

まあ、「先頭に英字の文言が出てきたら命令と判断する」って単純な仕様なんだろうが、それにしてもなんだかなあ・・・

俺はそもそも if と else を同じ面で合わせたいので、

if (hoge) {
    hogehoge;
}
else {
    monyomonyo;
}

という書き方派なのよ。多分、(特に UNIX 系のプログラマは)

if (hoge) {
    hogehoge;
} else {
    monyomonyo;
}

って書きたい派が多いと思うけど。(なんとなく、ネット上のソースなんかを見ると)

でも、bash スクリプトでも

if [[ "$a" == "y" ]]; then
    echo "あなたはやましろしんご";
else
    echo "あなたはやなぎさわしんご";
fi

って書くでしょ?やっぱ ELSE の面は IF と合わせたいのよね、生理的に(笑)
20260613_nodejp1.jpg

Electron でのアプリ開発のために Git インストール後、今度は Node.jp を・・・

実際に使うアプリを開発するので(実験目的ではないので)、Node.js LTS版(Long Term Support(長期サポート)版)をインストールする。


2.下の方にある Node.js 24.16.0 (LTS) のアイコンをクリック。


4.node-v24.16.0-x64.msi を実行。ひたすら「Next」で進み、「Install」実行。

5.新しく立ち上げたコマンドプロンプトで、Node.js 関係のコマンドにパスが通っていることを確認

Microsoft Windows [Version 10.0.26200.8524]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>where npm
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd

C:\Windows\System32>where node
C:\Program Files\nodejs\node.exe

C:\Windows\System32>

通ってる。
※コマンドプロンプトには「環境変数を読み直す」機能はないので、新しいウィンドウを起動しような。

6.一応、バージョンも確認。

C:\Windows\System32>npm --version
11.13.0

C:\Windows\System32>node --version
v24.16.0

OK。いよいよ、Electron のプロジェクト作って簡単なプログラムを書いてみる。
なんか最近、ラーメンの話よりプログラム開発ネタの方が多いな。いかん、いかん。しっかりしないと痩せてしまう

・・・しかし、今回も技術的なメモ。Git のインストール。ほんとにインストールのメモだけで、中身はありませんけど(笑)

Spring Boot + Spring Batch で作ろうと思っていたアプリを(結局 Web 画面ベースだとローカルファイルのパスをサーバ側に渡せないことがわかったので)、Electron で作る方向に方針変更。まずは Electron のお勉強を。

というわけで、こちらのサイト


を参考に、Electron セットアップのために必要な Git(バージョン管理システム)をインストールします。

ちゅうわけで、コマンドプロンプトを起動(管理者権限でね)し、Git のインストール開始。

Microsoft Windows [Version 10.0.26200.8524]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32> winget install --scope machine --id Git.Git -e --silent --disable-interactivity --force --accept-source-agreements --accept-package-agreements --override "/VERYSILENT /NORESTART /NOCANCEL /SP- /CLOSEAPPLICATIONS /RESTARTAPPLICATIONS /COMPONENTS=""icons,ext\reg\shellhere,assoc,assoc_sh"" /o:PathOption=Cmd /o:CRLFOption=CRLFCommitAsIs /o:BashTerminalOption=MinTTY /o:DefaultBranchOption=main /o:EditorOption=VIM /o:SSHOption=OpenSSH /o:UseCredentialManager=Enabled /o:PerformanceTweaksFSCache=Enabled /o:EnableSymlinks=Disabled /o:EnableFSMonitor=Disabled"
'msstore' ソースでは、使用する前に次の契約を表示する必要があります。
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
ソースが正常に機能するには、現在のマシンの 2 文字の地理的リージョンをバックエンド サービスに送信する必要があります (例: "US")。

見つかりました Git [Git.Git] バージョン 2.54.0
このアプリケーションは所有者からライセンス供与されます。
Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。
ダウンロード中 https://github.com/git-for-windows/git/releases/download/v2.54.0.windows.1/Git-2.54.0-arm64.exe
  ██████████████████████████████  60.4 MB / 60.4 MB
インストーラーハッシュが正常に検証されました
パッケージのインストールを開始しています...
インストールが完了しました

C:\Windows\System32>

で、次は、Node.js をインストールします。Electron は Chromium と Node.js でデスクトップアプリを作るためのフレームワークじゃけえね。
macOS では、日本語入力の OFF/ON はスペースキーの左にある「英数」キー(日本語OFF)と、右にある「かな」キー(日本語ON)で行う。例えば「かな」キーを押せば必ず日本語入力になるし、「英数」キーを押せば必ず日本語入力は OFF になる。Windows のように「あれ?今日本語入力だっけ?」と悩むことはない。

Windows だとよくあるでしょ?半角で入力しようと思って「半角/全角|漢字」キー押したのに、すでに半角だったので全角になっちゃったなんてこと(笑)

Mac のキーボードには「半角/全角|漢字」キー、「カタカナ/ひらがな|ローマ字」キーというものは存在しない。
Windows の「半角/全角|漢字」キーのように、日本語入力を交互に OFF/ON 切替するのは、Ctrl キー + スペースキーで行う。

20250423_ime1.jpg

で、うちの MacBook Air では Parallels Desktop 20 for Mac という VMシステムの上で Windows11 Pro を動かしているのだが、当然、「半角/全角|漢字」キーがないので日本語入力への切り替えがキーボードでは行えない。マウスでタスクバー上の IME の文字アイコンをクリックして切り替えるとかしないといけない。不便・・・

というわけで、macOS を使っているときと同じように「英数」「かな」キーを使って日本語入力を切り替えられるようにする。

方法は簡単で、Windows11 の「設定」画面を開き、「時刻と言語」→「言語と地域」→「オプション」(日本語のオプション)→Microsoft IME」(オプション)→ 「キータッチのカスタマイズ」で、「キーの割り当て」をONにし、

無変換キー→「IME-オフ」
変換キー→「IME-オン」
Ctrl + Space →「IME-オン/オフ」

を選択するだけである。これで、macOS 同様、「英数」キー、「かな」キーで日本語入力の OFF/ON が可能となる。

ネット上でググると、IME のバージョンを古いものに戻さないとダメという話が見つかるが、あれは古いバージョンの Parallels や Windows OS での話。俺環境は、2025/4/23 現在で最新の macOS、Windows11、Parallels となっているので、上記のような対応でばっちり。わざわざ IME を古いバージョンに戻す必要はない。

20250423_ime2.jpg

ちなみに、ちなみに、「以前のバージョンの Microsoft IME を使う」を ON にしていると、「キータッチのカスタマイズ」で「キーの割り当て」機能が使えないので、すぐに「以前のバージョンを使う」は OFF にしよう。
また Windows にやられた。
もう、このクソ OS、というか Microsoft のやり方、セキュリティに対する迷走具合はどうにかならないのか?

あるインターネットに接続しない(Windows Update時に一時的に、ネットワークから切り離しPC単体で接続される)閉じられたネットワーク内で運用されているシステムがあり、その中でゲスト接続(パスワード認証を行わない)によるファイル共有が行われている。

これが Windows11 端末で、Windows Update 後、突然共有が出来なくなったのだ。
パスワードのないユーザなのに「パスワードを入れろ」と聞かれる。

20250412_win_error1.jpg

「危険な運用を Windows が止めてくれたので良いじゃないか」「そもそもパスワード無しのファイル共有なんて危険すぎる」と言う人もいるだろうが、まあ、アホである(笑)
そういう運用が許される環境は存在するし、それが「いきなり OS の仕様変更で勝手にできなくされる(必要もないのに)」ことこそ大問題なのだ。

そもそも、回避する方法があるんだから、「突然接続できなくなって、現場を混乱させてでも優先すべきセキュリティ対策」でもなんでもないのである。現場をバタバタさせるだけだ。

で、「ネットワーク資格情報の入力」を回避する方法(Windows11 Pro の場合)

20250412_gpedit.msc.jpg

グループポリシーエディタ(gpedit.msc)で、「ネットワーク」→「Lanman ワークステーション」で、「安全でないゲストログオンを有効にする」を「未構成」「無効」になっていれば「有効」にするだけである。

ちなみに、この「パスワード無しのゲストログインでファイル共有しているシステム」は俺が作ったシステムでもなんでもなく、たんに「使用しているだけ」なので、俺に「そもそもそういうシステムの設計が・・・」とか意見言われても仕方ないぞ。

そして、ここまで読んでもまだそういう意見を持っている人間は、「世の中にはそういう仕様でも、適切な環境設定さえされていればなんの問題もないシステム」が存在することを知ろうな。世間知らずめ(笑)
お客さんのところで Node.js 関係のインストールをしようとすると、

PC> fnm install 22
error: can't get remote versions file: error sending request for url (https://nodejs.org/dist/index.json)
PS C:\Users\Masanori Shinoda> fnm install v22.13.1
Installing Node v22.13.1 (x64)
error: Can't download the requested binary: error sending request for url (https://nodejs.org/dist/v22.13.1/node-v

となる。これは Node.js のインストールファイルをローカルに取ってきて先に進めたが、corepack を使って pnpm をインストールしようとして失敗。

PC> corepack prepare pnpm@latest --activate
Internal Error: Error when performing the request to https://registry.npmjs.org/pnpm; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting
<以下略>

なんでエラーになってるのかわからないので、試しに npm を使って pnpm のインストールを試みると、

PC> npm install -g pnpm@latest
npm error code ETIMEDOUT
npm error errno ETIMEDOUT
npm error network request to https://registry.npmjs.org/pnpm failed, reason:
npm error network This is a problem related to network connectivity.
npm error network In most cases you are behind a proxy or have bad network settings.
npm error network
npm error network If you are behind a proxy, please make sure that the
npm error network 'proxy' config is set properly.  See: 'npm help config'
npm error A complete log of this run can be found in: C:\Users\hogehoge\AppData\Local\npm-cache\_logs\2025-02-03T07_41_09_310Z-debug-0.log

https://registry.npmjs.org/pnpm へアクセスできないので、proxy の設定をちゃんとしろ的なことを言われているね。

確かに、ブラウザではプロキシ設定を行っているので、上記 URL にも到達できる。
コマンドプロンプトからコマンドでインストールを試みたり、Visual Studio からコマンドを実行したときには到達できないようだ。

そこで、環境設定で、システム環境変数 HTTP_PROXY と HTTPS_PROXY にプロキシサーバを(ブラウザで指定しているプロキシサーバに)設定してやればうまくいった。

・・・が、今度は Sourcetree でローカルサーバから最新ソースをプルしてくるときに、

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch --no-tags origin
fatal: unable to access 'http://hogeserver/dev/Proj0991/': The requested URL returned error: 503

というエラーが発生するようになった。

ああ、ローカルサーバまでプロキシ経由になっちゃってる・・・ってことで、環境変数 NO_PROXY にローカルサーバを設定してやる。

(例) NO_PROXY  localhost,127.0.0.1,hogeserver,192.168.

これでばっちりであった。
Windows はとにかく糞 OS である。

まあ、コンピュータに詳しい人ほど Windows 嫌いは進むんだけど(だいたい、Windows しか知らない中途半端な知識しかない小僧に Windows ファンが多い(笑))

なにがダサいかというと、その「自分優先」の設計思想だ。

今日ももう一時間近く仕事にならない。

20241121_windows1.jpg

WindowsUpdate のために Windows Modules Installer Worker といううんこのようなプログラムがディスクをがりがり読み続け、他のアプリがディスクを読むことができず固まり、まったく仕事にならない。

ファイルエクスプローラーで右ボタンメニューを出すだけで数分かかる・・・
日本語変換も固まったり・・・
Windows Modules Installer Worker というウジ虫みたいなプログラムが最優先でディスクをがりがり読んでいるせいだ。

馬鹿なの?そんなバックグラウンドのプログラム、ユーザの操作に影響をださないように自身のプライオリティは低めに設定しこっそり走らせろよ。それを、我れが我れがとシステム(OS)が占有して・・・だっせえなあ、Windows。どういう馬鹿が設計したらこんな糞バランスの OS が出来上がるんだろ?(^^;;;

とりあえず、ユーザにストレスをかけない OS の正しい動きについては macOS を参考にしなさい。(もちろん macOS にも不味い部分はあるが、Windows の糞具合と比べたら相当マシな OS である)
随分前に作った Linux(CentOS)上で動くプログラム。
LZH ファイルを解凍し、そのファイルをほげほげするのだが、さすがにもう Windows 上で LZH ファイルを作るのもきつくなってきた・・・ということで ZIP ファイル対応を依頼されたのだが(例えば、7-Zip なんかでも LZH 形式には対応してないからな(^^;)・・・ハマった(^^;

yum で入れた unzip は -O オプション(アーカイブ内のファイル名のエンコードが指定できる)が使える(以前のバージョンではパッチを当てないと駄目だった)ので、例えば unzip -Ocp932 -l exsample.zip で、exsample.zip の中の「かわいい中年男性一覧.csv」みたいなファイル名は取ってこれるんだけど、これをディスク上に解凍するとファイル名が化けまくる・・・

ちなみに、プログラムは EUC-JP で書かれている。なにせ、もう、18年前に初版公開したプログラムだからな(笑)。

これ、lha コマンドは EUC-JP でファイル名を出力するパッチが当たっていたので問題なかったんだけど、unzip は「サーバの locale のエンコードでファイル名が作られる」ため、実行サーバの locale である UTF-8 のファイル名となる。

他のプログラムにも影響あるから、なんとか EUC-JP でファイル名を設定してほしいなあ。

しかし、unzip にそのようなオプションはない。結局、unzip を実行する前に、locale を EUC-JP にする形でなんとかなった。

(例)
export LC_CTYPE=ja_JP.eucJP; /usr/bin/unzip -OCP932 -d /tmp exsample.zip

このプログラムは実行後シェルを閉じるので、LC_CTYPE の設定を投げっぱなしだが、同一シェル内で他のコマンドなど実行するのなら、

export LC_CTYPE=ja_JP.UTF-8

で locale を元の UTF-8 に戻すこと。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちWindowsカテゴリに属しているものが含まれています。

前のカテゴリはUNIXやLinuxです。

次のカテゴリはデータベースです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら