お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。

バッチファイルで文字列置換する

投稿日：
OS::Windows言語::batファイル

変数の文字列を文字列で置換

@ECHO OFF

SET text="hoge piyo fuga"
REM 置換文字を標準出力
ECHO %text:hoge=XXX%
REM 置換文字を変数に設定
SET replaced_text=%text:hoge=XXX%
ECHO %replaced_text%

@ECHO ON

変数の文字列を変数の文字列で置換

SET "var=value"とSET var="value"の差は後述のAppendixを参照
CALLを付けているのは、これがないと変数名そのものが文字列として扱われるため

@ECHO OFF

SET "text2=foo bar baz"
SET "search_word=baz"
SET "replacer=ZZZ"

REM 置換文字を標準出力
CALL ECHO %%text2:%search_word%=%replacer%%%
REM 置換文字を変数に設定
CALL SET replaced_text2=%%text2:%search_word%=%replacer%%%
ECHO %replaced_text2%
REM 検索文字列を削除
CALL SET replaced_text3=%%text2:%search_word%=%%
ECHO %replaced_text3%

@ECHO ON

Appendix

SETコマンドの記述方法を変えた場合の出力結果の差について

SET "var=foo bar ZZZ" SET var="foo bar ZZZ"
foo bar ZZZ "foo bar ZZZ"

参考

コメント（0件）

WSL2のUbuntu 20.04にGiteaを生やす

投稿日：
OS::Linux::Ubuntuソフトウェア::WSLソフトウェア::BTSツールジャンル::セットアップ

ローカルで個人メモを管理したいがRedmineでは物足りない。そうだGiteaを使おう。
この記事ではDockerを使用せず、バイナリからセットアップします。
Gitのリポジトリをホスティングできる部分までは確認してます。

外部に公開することは一切考慮していません。ローカルマシンでの個人利用を想定しています。

確認環境

Env Ver
Ubuntu 20.04.4 LTS
WSL2 1.0.3.0
Gitea 1.18.5
MySQL Ver 15.1 Distrib 10.3.37-MariaDB
Git 2.25.1

前提条件

  • WSL2上にUbuntu 20.04.4 LTSをインストール済
  • GitとMySQLは構築済

手順

公式の手順ではユーザーがgitですが、ここではgiteaに変えてます
他にも多少変えてます

Giteaディレクトリの作成とバイナリ配置

# 動作用ユーザーの追加
sudo adduser \
   --system \
   --shell /bin/bash \
   --gecos 'Git Version Control' \
   --group \
   --disabled-password \
   --home /home/gitea \
   gitea

# 必要なフォルダを切る
sudo mkdir -p /var/lib/gitea/{custom,data,log}
sudo chown -R gitea:gitea /var/lib/gitea/
sudo chmod -R 750 /var/lib/gitea/
sudo mkdir /etc/gitea
sudo chown root:gitea /etc/gitea
sudo chmod 770 /etc/gitea

# バイナリのインストール
wget -O gitea https://dl.gitea.com/gitea/1.18.5/gitea-1.18.5-linux-amd64
chmod +x gitea
sudo cp gitea /usr/local/bin/gitea

# mysqlにログイン
mysql -u XXX -pYYY

DBのセットアップ

SET old_passwords=0;
CREATE USER 'gitea' IDENTIFIED BY 'gitea';
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
FLUSH PRIVILEGES;

quit

Giteaの起動とWebインストール

以下のコマンドを叩き表示されたURLを開き、Webインストーラーで適当に設定

gitea web -c /etc/gitea/app.ini

Webインストール後の後処理とデーモンへの登録

# 自分以外書き換え不能に変更
sudo chmod 750 /etc/gitea
sudo chmod 640 /etc/gitea/app.ini

# デーモンの定義を作成
cat <<'EOF' | sudo tee /etc/init.d/gitea
#!/bin/sh
## BEGIN INIT INFO
# Provides:          gitea
# Required-Start:    $syslog $network
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: A self-hosted Git service written in Go.
# Description:       A self-hosted Git service written in Go.
## END INIT INFO

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="Gitea - Git with a cup of tea"
NAME=gitea
SERVICEVERBOSE=yes
PIDFILE=/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
WORKINGDIR=/var/lib/$NAME
DAEMON=/usr/local/bin/$NAME
DAEMON_ARGS="web -c /etc/$NAME/app.ini"
USER=gitea
STOP_SCHEDULE="${STOP_SCHEDULE:-QUIT/5/TERM/1/KILL/5}"

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

do_start()
{
    GITEA_ENVS="USER=$USER GITEA_WORK_DIR=$WORKINGDIR HOME=/home/$USER"
    GITEA_EXEC="$DAEMON -- $DAEMON_ARGS"
    sh -c "start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \\
        --background --chdir $WORKINGDIR --chuid $USER \\
        --exec /bin/bash -- -c '/usr/bin/env $GITEA_ENVS $GITEA_EXEC'"
}

do_stop()
{
    start-stop-daemon --stop --quiet --retry=$STOP_SCHEDULE --pidfile $PIDFILE --name $NAME --oknodo
    rm -f $PIDFILE
}

do_status()
{
    if [ -f $PIDFILE ]; then
        if kill -0 $(cat "$PIDFILE"); then
            echo "$NAME is running, PID is $(cat $PIDFILE)"
        else
            echo "$NAME process is dead, but pidfile exists"
        fi
    else
        echo "$NAME is not running"
    fi
}

case "$1" in
    start)
        echo "Starting $DESC" "$NAME"
        do_start
        ;;
    stop)
        echo "Stopping $DESC" "$NAME"
        do_stop
        ;;
    status)
        do_status
        ;;
    restart)
        echo "Restarting $DESC" "$NAME"
        do_stop
        do_start
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|status|restart}" >&2
        exit 2
        ;;
esac

exit 0
EOF

# デーモン登録
sudo chmod 755 /etc/init.d/gitea
sudo update-rc.d gitea defaults

# デーモン起動
sudo service gitea start

自動起動する場合はWindowsのスタートアップ時に以下が走るようにしておけばOK

wsl -d Ubuntu -u root -- service gitea start

トラブルシュート

この記事を書くにあたってハマったことのまとめ

gitea 起動時にpermission deniedとエラーが出る

/var/lib/gitea/custom/options/locale: permission denied

以下のコマンドを流せばいける。公式のコマンドではコケる

gitea web -c /etc/gitea/app.ini

サービス起動時にFailed to get home directoryとエラーが出る

2023/03/03 13:17:38 ...s/setting/setting.go:656:loadFromConf() [F] Failed to get home directory: cannot get home directory

/etc/init.d/giteaのdo_start()の部分を以下の内容にすればいける

do_start()
{
    GITEA_ENVS="USER=$USER GITEA_WORK_DIR=$WORKINGDIR HOME=/home/$USER"
    GITEA_EXEC="$DAEMON -- $DAEMON_ARGS"
    sh -c "start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \\
        --background --chdir $WORKINGDIR --chuid $USER \\
        --exec /bin/bash -- -c '/usr/bin/env $GITEA_ENVS $GITEA_EXEC'"
}

git pushでエラーが出る

RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

nginxからgiteaにリバースプロキシしてる場合はconfのserverセクションに以下を追加

client_max_body_size 0;

参考

コメント（0件）

Slackのリマインダー操作方法（登録、削除、一覧）

投稿日：
サービス::Slackその他::便利ツール

公式のリファレンスが情報少なすぎるのでメモ
特にこれというフォーマットはなく、ある程度幅広い書式があるようで、公式のドキュメントを見る限り、多少のブレはよしなに解釈してくれるっぽい？
この記事ではoperatorなどの用語が登場しますが、これは私が勝手に名付けたものなので、特に公式の用語ではありません

手組するの面倒なので雑にコマンド生成ツールを作りました。

https://tool.lycolia.info/slack-remider-creator

登録

基本

  • フォーマット
    • /remind [宛先] [メッセージ] [実行日時]
  • 例
    • /remind #random "hoge piyo fuga" at 10:00 every monday, sunday

書式

宛先
宛先 意味
me 自分
@someone メンション
#channel チャンネル
メッセージ

"hoge piyo fuga"のように書けるが、hoge piyo fugaでも一応通じる
ダブルクォートで囲む場合、改行も利用可能

実行日時
  • <oparator> <repeat-operator>
    • <oparator>で実行日時を設定
    • <repeat-operator>で繰り返しを設定
  • 例
    • at 10:00 every monday, sunday
oparator
オペレーター 例 意味
in <value> (seconds \ minutes \ hours)
at <HH:mm> at 1700 指定時刻に実行
on <yyyy-MM-dd HH:mm> on 2023-10-10 09:15 指定日時に実行
repeat-operator
  • every <operator>
  • 例
    • every monday, sunday
operator
day
weekday
sunday, monday, tuesday, wednesday, thursday, friday, saturday

削除

  • /remind listでリスト表示して消す

一覧

  • /remind list
コメント（0件）

Linuxコマンドメモ：wget

投稿日：
OS::Linux::コマンド

高機能ダウンローダー
単純な疎通確認やバッチでファイルを落としたりするときに重宝する

wget [options...] <url>

Options

  • -O <path>
    • 出力先のフルパス
  • -P <path>
    • 出力先フォルダ
    • ファイル名は元のファイル名になる
  • --referer
    • リファラ

参考

  • https://linux.die.net/man/1/wget
コメント（0件）

TypeScript + SWC + Jestでexport方法別のspyOnするパターンを書いた

投稿日：
言語::TypeScriptNode.js::JestNode.js::SWC言語::JavaScript::CommonJS言語::JavaScript::ES Module開発::テスト

本記事ではTypeScriptとSWC、Jestの組み合わせ環境でjest.spyOnを使う方法をexportパターン別に書いていきます。また、jest.spyOn対象の実装の詳細はテストせず、モック化したインターフェースのテストのみを行う前提で書いています。

確認環境

Env Ver
Node.js 18.14.0
typescript 4.9.5
@swc/cli 0.1.62
@swc/core 1.3.36
@swc/jest 0.2.24
jest 29.4.3

サンプルコード

全編は以下にあります
jest.spyOn pattern example for SWC + TypeScript

親関数から子関数を呼び出すパターンで、子関数のjest.spyOnをするシチュエーションで考えます。

default export編

以下のdefaultエクスポートをjest.spyOnする方法です。

child.ts
export const child = (param: string) => {
  return param;
};
parent.ts
import child from 'src/default/child';

const parent = (param: string) => {
  return child(param);
};

export const Parent = {
  parent,
};
parent.spec.ts

この形式の場合import側では書き換え不能なのでファイルごとモックにして解決します。
このやり方はファイルごとモックするため、同じファイルにある関数をjest.spyOnするのには向いていません。

import * as child from 'src/default/child';
import { Parent } from 'src/default/parent';

jest.mock('src/default/child');

describe('default', () => {
  it('called by child function', () => {
    const spiedChild = jest.spyOn(child, 'default');
    Parent.parent('foo');

    expect(spiedChild).toHaveBeenCalledWith('foo');
  });
});

named export編

以下の名前付きエクスポートをjest.spyOnする方法です。

child.ts
export const child = (param: string) => {
  return param;
};
parent.ts
import { child } from 'src/named-export/child';

export const parent = (param: string) => {
  return child(param);
};
parent.spec.ts

default exportと同じくimport側では書き換え不能なのでファイルごとモックにして解決します。
このやり方はファイルごとモックするため、同じファイルにある関数をjest.spyOnするのには向いていません。

import * as child from 'src/named-export/child';
import { parent } from 'src/named-export/parent';

jest.mock('src/named-export/child');

describe('function', () => {
  it('called by child function', () => {
    const spiedChild = jest.spyOn(child, 'child');
    parent('foo');

    expect(spiedChild).toHaveBeenCalledWith('foo');
  });
});

namespace export編

やり方はnamed export編と同じです。

child.ts
export namespace Child {
  export const child = (param: string) => {
    return param;
  };
}
parent.ts
import { Child } from 'src/namespace/child';

export namespace Parent {
  export const parent = (param: string) => {
    return Child.child(param);
  };
}
parent.spec.ts

namespaceの場合、トランスパイル後にクロージャになり、書き換え以前に関数にアクセスできなくなるため、ファイルごとモックにして解決します。
このやり方はファイルごとモックするため、同じファイルにある関数をjest.spyOnするのには向いていません。

import { Child } from 'src/namespace/child';
import { Parent } from 'src/namespace/parent';

jest.mock('src/namespace/child');

describe('namespace', () => {
  it('called by child function', () => {
    const spiedChild = jest.spyOn(Child, 'child');
    Parent.parent('foo');

    expect(spiedChild).toHaveBeenCalledWith('foo');
  });
});

module export編

これだけやり方が変わります。

child.ts
const child = (param: string) => {
  return param;
};

export const Child = {
  child,
};
parent.ts
import { Child } from 'src/module/child';

const parent = (param: string) => {
  return Child.child(param);
};

export const Parent = {
  parent,
};
parent.spec.ts

このケースの場合オブジェクトをexportしていて書き換えができるため、モック化せずにそのままjest.spyOnすることが出来ます。
このやり方であれば、ファイルのモックはしないため、同じファイルにある関数をjest.spyOnする事ができますが、裏を返せばオブジェクトの書き換えが可能であるため、実装方法によっては予期せぬ不具合が生まれる可能性があり、危険です。
何かしらの悪意ある攻撃を受けた場合にオブジェクトがすり替わるなどすると致命的だと思います。

import { Child } from 'src/module/child';
import { Parent } from 'src/module/parent';

describe('module', () => {
  it('called by child function', () => {
    const spiedChild = jest.spyOn(Child, 'child');
    Parent.parent('foo');

    expect(spiedChild).toHaveBeenCalledWith('foo');
  });
});

おまけ：それぞれのトランスパイル結果

.spec.jsは省いてます

default export編

child.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'default', {
  enumerable: true,
  get: () => _default,
});
const child = (param) => {
  return param;
};
const _default = child;
parent.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'Parent', {
  enumerable: true,
  get: () => Parent,
});
const _child = /*#__PURE__*/ _interopRequireDefault(require('./child'));
function _interopRequireDefault(obj) {
  return obj && obj.__esModule
    ? obj
    : {
        default: obj,
      };
}
const parent = (param) => {
  return (0, _child.default)(param);
};
const Parent = {
  parent,
};

named export編

child.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'child', {
  enumerable: true,
  get: () => child,
});
const child = (param) => {
  return param;
};
parent.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'parent', {
  enumerable: true,
  get: () => parent,
});
const _child = require('./child');
const parent = (param) => {
  return (0, _child.child)(param);
};

namespace export編

child.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'child', {
  enumerable: true,
  get: () => child,
});
const child = (param) => {
  return param;
};
parent.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'Parent', {
  enumerable: true,
  get: () => Parent,
});
const _child = require('./child');
var Parent;
(function (Parent) {
  var parent = (Parent.parent = (param) => {
    return _child.Child.child(param);
  });
})(Parent || (Parent = {}));

module export編

child.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'Child', {
  enumerable: true,
  get: () => Child,
});
const child = (param) => {
  return param;
};
const Child = {
  child,
};
parent.js
'use strict';
Object.defineProperty(exports, '__esModule', {
  value: true,
});
Object.defineProperty(exports, 'Parent', {
  enumerable: true,
  get: () => Parent,
});
const _child = require('./child');
const parent = (param) => {
  return _child.Child.child(param);
};
const Parent = {
  parent,
};

この記事を書いた切っ掛け

一言でいうとTSC(TypeScript Compiler) からSWCに移行した際にjest.spyOnを使ったら、上手く使えずにハマったためです。

まずTypeScript + JestではTypeScriptをCJS(CommonJS) にトランスパイルするためjest.spyOnが有効でした。しかし、SWCはTypeScriptをESM(ES Modules) にトランスパイルします。ESMではjest.spyOnが有効になりません。

これはCJSではexportしたObjectの書き換えが可能なのに対し、ESMでは出来ないためです。（jest.spyOnは実行時にオブジェクトを書き換えることで動いています）

この対策としてファイルそのものをモックに置き換えることで、jestの管理下に起き、自由に書き換えられるようにするのが本記事のアプローチです。以前と異なり、呼び出している関数の実装の詳細を見ることはできなくなりましたが、これは単体テストの観点としては正しいため、ある意味本来の単体テストになったとも取れると考えています。（モックに元の処理を注入することで今まで通り実装の詳細を確認することも出来る可能性がありますが、確認してません）

コメント（0件）