Linux – find

2021-12-30 / tau / コメントする

名前を指定して検索

特定の名前のファイル・ディレクトリーを探す。

-nameオプションに続けて”名前”で検索
大文字／小文字が区別される(case sensitive)

$ find -name "search_name"

1	$ find -name "search_name"

大文字・小文字を問わず名前を指定して検索する場合は、-inameを指定する(case insensitive)。

$ find -iname "search_name"

1	$ find -iname "search_name"

この場合"SEARCH_NAME"、"Search_Name"などもヒットする。

種類を指定して検索

-type 形式コードを指定。以下はファイルのみを検索する例。

$ find -iname "search_name" -type f

1	$ find -iname "search_name" -type f

主な形式コードは以下のとおり。

-type f：ファイルを検索
-type d：ディレクトリーを検索
-type l：シンボリックリンクを検索

ワイルドカード

'*'は任意長の文字列。以下の例では'.conf'で終わるファイルがヒット。

$ find -iname "*.conf" -type f

1	$ find -iname "*.conf" -type f

'?'は任意の1文字にヒット。以下の例では'*'と組み合わせていて、'loc'に3文字が続き、任意の拡張子を持つファイルが検索される。

$ find -iname "loc???.*" -type f

1	$ find -iname "loc???.*" -type f

たとえば以下のようなファイルがヒットする。

locale.rb
locker.c
locker.js
lock-i.ri

サイズ指定

-sizeオプションにサイズ、単位、以上／未満の符号をつけて検索する。

-size [符号なし/+/-]数値[c/k/M/G/b]

単位記号

c：bytes
k：K bytes
M：M bytes
G：G bytes

前置符号

符号なし：指定サイズに等しいファイル
+：指定サイズ以上のファイル
-：指定サイズ未満のファイル

以下の例では100キロバイトちょうどのファイルがヒットする。

$ find -type f -size 100k

1	$ find -type f -size 100k

以下の例では10Mバイト以上のファイルがヒットする。

$ find -type f -size +10M

1	$ find -type f -size +10M

以下の例では10Kバイト未満のファイルがヒットする。

find -type f -size -10k

1	find -type f -size -10k

-sizeの組み合わせが可能で、以下の例では10Mバイト以上、15Mバイト未満のファイルがヒットする。

$ find -type f -size +10M -size -15M

1	$ find -type f -size +10M -size -15M

時刻指定

時刻の種類には以下の三種類がある。

Access Time: ファイルに最後にアクセスがあった時刻
Modification Time: ファイル内容が最後に変更された時刻
Change Time: ファイルの状態(inodeデータ)が最後に変更された時刻

3つの時刻に対して、指定する数値が日単位か分単位かでオプション名が変わる。

日単位：-atime, -mitime, -ctime
分単位：-amin, -mmin, -cmin

各オプションに、時間の数値と前置符号を指定する。

-atime/-mtime/-ctime [符号なし/+/-]日数
-amin/-mmin/-cmin [符号なし/+/-]分数

前置符号

符号なし：その時刻前、たとえば
- -atime 3 → 3日前にアクセス
-：その時刻以内、たとえば
- -mtyme -3 → 変更されたのが3日前以内
+：その時刻以上経過、たとえば
- -ctyme +3 → 変更されて以降3日以上経過

さくらサーバー – MySQLのアップグレード

2021-12-25 / tau / コメントする

概要

2021年11月、さくらインターネットのカスタマーセンターよりメールがあり、内容はMySQL5.1, 5.5から5.7へのアップグレードを推奨するものだった。5.5のサポート終了やWordPressなどCMSの推奨環境のバージョンアップなどの背景によるもの。

私の環境はさくらレンタルサーバーのスタンダードプラン。後述の経緯もあって少しとまどったが、アップグレードとWordPressの設定を終えた。

状況としては、

MySQL5.5と並んで、既にMySQL5.7が稼働していた
WordPressで使っていたのはMySQL5.5の方

手順の概要は

5.7のWordPress用データベースを削除
5.5のWordPress用データベース以外を削除
アップグレード予約・実行
wp-config.php書き換え

経緯

今回の経緯は以下のとおり。

2016年、さくらレンタルサーバー(スタンダードプラン)の利用開始
- このときにMySQL、WordPressも運用開始
その後2021年6月までの間に5.5→5.7へアップグレード
- アップグレード後も5.5は存続
- このときにWordPressの設定は変更せず
- このため、これ以降も投稿等は5.5の方に記録
2021年11月に5.7へのアップグレード推奨メール
2021年12月に再度アップグレードとWordPress設定変更完了

確認作業

データベース構成

メールを受けてさくらサーバーのコントロールパネルで確認したところ、以下の2つのデータベース(以下、DB)が存在。

mysql57.アカウント名.sakura.ne.jp→MySQL5.7
(mysql2019.db.sakura.ne.jp)
→システムの管理で使われるホスト名
mysql304.db.sakura.ne.jp→MySQL5.5

5.5のデータベースは以下のとおり。

information_schemaはMySQLの管理用
_wp1はWordPress用のDB
_mainと_testの2つはテスト用に自分で作成したもので、特に重要ではない

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| アカウント名_main  |
| アカウント名_test  |
| アカウント名_wp1   |
+--------------------+
4 rows in set (0.05 sec)

mysql> show databases;

+--------------------+

| Database |

+--------------------+

| information_schema |

| アカウント名_main |

| アカウント名_test |

| アカウント名_wp1 |

+--------------------+

4 rows in set (0.05 sec)

5.7のデータベースは以下のとおり。こちらにもWordPress用の_wp1があり、他のDBも5.5と同じ。

mysql> show databases;
+---------------------------+
| Database                  |
+---------------------------+
| information_schema        |
| アカウント名_main         |
| アカウント名_test         |
| アカウント名_test_utf8mb4 |
| アカウント名_wp1          |
+---------------------------+
6 rows in set (0.07 sec)

mysql> show databases;

+---------------------------+

| Database |

+---------------------------+

| information_schema |

| アカウント名_main |

| アカウント名_test |

| アカウント名_test_utf8mb4 |

| アカウント名_wp1 |

+---------------------------+

6 rows in set (0.07 sec)

WordPress用データベース

MySQL5.5、5.7ともアカウント名_wp1のテーブル構成は同じで、以下のとおり。

mysql> show tables;
+----------------------------+
| Tables_in_アカウント名_wp1 |
+----------------------------+
| wp_ts01_commentmeta        |
| wp_ts01_comments           |
| wp_ts01_links              |
| wp_ts01_options            |
| wp_ts01_postmeta           |
| wp_ts01_posts              |
| wp_ts01_term_relationships |
| wp_ts01_term_taxonomy      |
| wp_ts01_termmeta           |
| wp_ts01_terms              |
| wp_ts01_usermeta           |
| wp_ts01_users              |
+----------------------------+
12 rows in set (0.00 sec)

mysql> show tables;

+----------------------------+

| Tables_in_アカウント名_wp1 |

+----------------------------+

| wp_ts01_commentmeta |

| wp_ts01_comments |

| wp_ts01_links |

| wp_ts01_options |

| wp_ts01_postmeta |

| wp_ts01_posts |

| wp_ts01_term_relationships |

| wp_ts01_term_taxonomy |

| wp_ts01_termmeta |

| wp_ts01_terms |

| wp_ts01_usermeta |

| wp_ts01_users |

+----------------------------+

12 rows in set (0.00 sec)

ここで、5.5と5.7でwp_ts01_postsに以下のような違いがあった。

5.5の投稿数。投稿日付は2016年6月16日～2021年12月13日で確認時点の日付まで。

mysql> select count(*) from wp_ts01_posts;
+----------+
| count(*) |
+----------+
|    12500 |
+----------+
1 row in set (0.02 sec)

mysql> select count(*) from wp_ts01_posts;

+----------+

| count(*) |

+----------+

| 12500 |

+----------+

1 row in set (0.02 sec)

5.7の投稿数。2016年6月16日～2021年2月8日まで。

mysql> select count(*) from wp_ts01_posts;
+----------+
| count(*) |
+----------+
|     9192 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from wp_ts01_posts;

+----------+

| count(*) |

+----------+

| 9192 |

+----------+

1 row in set (0.01 sec)

5.5に対して5.7の投稿数が少なく、途中までの投稿記録で途切れている。

wp-config.phpのMySQLホスト名を確認すると、以下のようにMySQL5.5の方のホスト名になっていて、MySQL5.7運用開始後もWordPressは5.5を使っている。

........
/** MySQL のホスト名 */
define('DB_HOST', 'mysql304.db.sakura.ne.jp');
........

........

/** MySQL のホスト名 */

define('DB_HOST', 'mysql304.db.sakura.ne.jp');

........

したがってMySQL5.7運用開始後もWordPressでは利用されず、投稿等は5.5の方に記録されていることになる。このことから5.7のWordPress用データベースを破棄して5.5のデータベースに入れ替え、設定変更することにする。

アップグレード

要点

アップグレードの要点は、さくらインターネットのサイトによると以下のとおり。

MySQLの5.5→5.7へのアップグレードは、既に5.7が存在していても可能
アップグレード先の5.7に5.5と同じ名前のDBが存在する場合はアップグレード不可
アップグレードはDBを指定して実行時間を予約
アップグレード後にWordPress等の設定変更が必要

データベースの整理方針

5.5のデータベースをアカウント名_wp1のみ残して削除し、アップグレード先の5.7の同じ名前のDBを削除。

5.5の他のデータベースは自分で作成したテスト用のものだけなので、削除しても問題ない
5.7のアカウント名_wp1は途中までしか投稿記録がなく、不要と判断
双方のinformation_schemaは残置

アップグレードの予約

アップグレードの予約はコントロールパネルで行った。

さくらのコントロールパネルで
- 5.7のアカウント名_wp1を削除
- 5.5のアカウント名_wp1以外を削除
information_schemaはコントロールパネルでは表示されないが5.5、5.7とも残置
12/21の02時にアップグレード予約

アップグレードの確認

翌朝確認したところ、MySQL5.7の方にアカウント名_wp1が作成されており、コンソールで確認したところ昨日までの最新の投稿が記録されていた。

コメントが2件、2時以降についていたが、いずれもspam判定のもので、内容も確認して無視。

WordPressの設定変更

コンソールでも可能だが、さくらインターネットサイトにあるとおりファイルマネージャーで実行。

コントロールパネル左の”Webサイト/データ”→”インストール済み一覧”を選択して、でWordPressのインストール先を確認
“Webサイト/データ”→”ファイルマネージャー”を開いて上記のディレクトリーに移動
wp-config.phpを確認
コンソールでwp-config.phpのコピーを別名で保存(バックアップ用)
ファイルマネージャーでwp-config.phpを右クリック→編集
- MySQLのホスト名の変更
  
  wp-config.php
  PHP
  
  /** MySQL のホスト名 */ define('DB_HOST', 'mysql304.db.sakura.ne.jp'); # 'mysql57.アカウント名.sakura.ne.jp'に変更
  
  1
  2
  3
  
  /** MySQL のホスト名 */
  define('DB_HOST', 'mysql304.db.sakura.ne.jp');
  # 'mysql57.アカウント名.sakura.ne.jp'に変更
- DB名は同じ名前なので変更しない
  
  wp-config.php
  PHP
  
  /** WordPress のためのデータベース名 */ define('DB_NAME', 'アカウント名_wp1');
  
  1
  2
  
  /** WordPress のためのデータベース名 */
  define('DB_NAME', 'アカウント名_wp1');
- パスワードも変更していないのでそのまま
  
  wp-config.php
  PHP
  
  /** MySQL データベースのパスワード */ define('DB_PASSWORD', '********');
  
  1
  2
  
  /** MySQL データベースのパスワード */
  define('DB_PASSWORD', '********');
ファイルマネージャーで”保存”、”閉じる”

WordPressの設定後確認

設定変更後、以下を確認した。

WordPressが正常に表示される
新規投稿を書き込み、投稿が反映されること、その内容がMySQLのDBのテーブルに反映されていることを確認
新規投稿を削除し、削除が反映され、テーブルにも削除経緯が反映されることを確認

WordPress – QuickLatexのエラー

2021-11-28 / tau / コメントする

QuickLatexにエラー発生

2021年11月のある日、WordPressで作業していてQuickLatexでエラーが出てしまった。

*** QuickLaTeX cannot compile formula:

\begin{equation*}
\frac{d\boldsymbol{f}(\boldsymbol{x})^T}{d\boldsymbol{x}} =
\left[ \begin{array}{ccc}
\dfrac{\partial f_1}{\partial x_1} & \ldots & \dfrac{\partial f_n}{\partial x_1} \\
\vdots & \dfrac{\partial f_j}{\partial x_i} & \vdots \\
\dfrac{\partial f_1}{\partial x_m} & \ldots & \dfrac{\partial f_n}{\partial x_m} \\
\end{array} \right]
\end{equation*}

*** Error message:
Cannot connect to QuickLaTeX server: cURL error 60: SSL certificate problem: unable to get local issuer certificate
Please make sure your server/PHP settings allow HTTP requests to external resources ("allow_url_fopen", etc.)
These links might help in finding solution:
http://wordpress.org/extend/plugins/core-control/
http://wordpress.org/support/topic/an-unexpected-http-error-occurred-during-the-api-request-on-wordpress-3?replies=37

*** QuickLaTeX cannot compile formula:

\begin{equation*}

\frac{d\boldsymbol{f}(\boldsymbol{x})^T}{d\boldsymbol{x}} =

\left[ \begin{array}{ccc}

\dfrac{\partial f_1}{\partial x_1} & \ldots & \dfrac{\partial f_n}{\partial x_1} \\

\vdots & \dfrac{\partial f_j}{\partial x_i} & \vdots \\

\dfrac{\partial f_1}{\partial x_m} & \ldots & \dfrac{\partial f_n}{\partial x_m} \\

\end{array} \right]

\end{equation*}

*** Error message:

Cannot connect to QuickLaTeX server: cURL error 60: SSL certificate problem: unable to get local issuer certificate

Please make sure your server/PHP settings allow HTTP requests to external resources ("allow_url_fopen", etc.)

These links might help in finding solution:

http://wordpress.org/extend/plugins/core-control/

http://wordpress.org/support/topic/an-unexpected-http-error-occurred-during-the-api-request-on-wordpress-3?replies=37

certificateに関するエラーらしいがよくわからない。

下記サイトに対処方法が整理されていて助かった。感謝したい。

参考サイト：数樂管理人のブログ～Cannot connect to QuickLaTeX server:…

手順

古い証明書の退避

さくらサーバーにssh接続して、証明書ファイルの確認。

% ls www/wp1/wp-includes/certificates
ca-bundle.crt

% ls www/wp1/wp-includes/certificates

ca-bundle.crt

このca-bundle.crtを別の名前にリネーム(.bakを付けるなど)。

新しい証明書の導入

このgithubサイトのWordPressページに証明書の内容が掲載されているので、その内容でca-bundle.crtファイルをローカルに作成し、先のディレクトリーにアップロード。

これで元の様にQuickLatexがコンパイルされるようになった。

MySQL – 月単位の集計～残高もある場合

2021-09-17 / tau / コメントする

例題設定

例題として個人の銀行口座の入出金記録の以下の構造のテーブルを考える。

mysql> DESCRIBE account;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| id          | int          | YES  |     | NULL    |       |
| date        | date         | YES  |     | NULL    |       |
| branch      | varchar(3)   | YES  |     | NULL    |       |
| transaction | varchar(20)  | YES  |     | NULL    |       |
| category    | varchar(10)  | YES  |     | NULL    |       |
| withdrawal  | int          | YES  |     | NULL    |       |
| deposit     | int          | YES  |     | NULL    |       |
| balance     | int          | YES  |     | NULL    |       |
| partner     | varchar(100) | YES  |     | NULL    |       |
+-------------+--------------+------+-----+---------+-------+
9 rows in set (0.00 sec)

mysql> DESCRIBE account;

+-------------+--------------+------+-----+---------+-------+

+-------------+--------------+------+-----+---------+-------+

| id | int | YES | | NULL | |

| withdrawal | int | YES | | NULL | |

| deposit | int | YES | | NULL | |

| balance | int | YES | | NULL | |

+-------------+--------------+------+-----+---------+-------+

9 rows in set (0.00 sec)

ここでidは入出金記録の順番に付されていて、変更されないものとする。すなわち、日・月・年などの単位でグルーピングしたとき、idが最も大きいレコードのbalanceがその期の残高となっている。

合計計算のみの場合

月ごとの合計を計算するだけの場合、年月でグルーピングしてSUM関数を使う。

SELECT
  MAX(DATE_FORMAT(date, '%Y年%m月')) AS 年月,
  SUM(withdrawal) AS 月別出金,
  SUM(deposit) AS 月別入金
FROM account
GROUP BY DATE_FORMAT(date, '%Y%m')
;

SELECT

MAX(DATE_FORMAT(date, '%Y年%m月')) AS 年月,

SUM(withdrawal) AS 月別出金,

SUM(deposit) AS 月別入金

FROM account

GROUP BY DATE_FORMAT(date, '%Y%m')

;

要点は以下の通り。

GROUP BY句で、yyyymm形式でフォーマットされた年月単位でグルーピング
グループごとにSUM関数で出金額と入金額を合計
年月表示はGROUP BY句のフォーマットと異なってもよい
ただしグルーピングされた複数レコード中のどのレコードのdateを使うかを明示するため、MAX関数を使っている。
- こうしないと(オプション指定なしでは)エラーが発生する

各月の残高も含める場合

月ごとの最終取引の抽出

各月の残高がデータに含まれていて、取引がidの昇順であることがわかっている場合、月ごとにグルーピングされたレコードのうちidが最大のレコードがその月の最後の取引になり、そのbalanceが月の残高になる。

そこで、まず各月の最終取引のidを取得する。

SELECT
  MAX(id) AS max_id
FROM account
GROUP BY DATE_FORMAT(date, '%Y%m')
;

SELECT

MAX(id) AS max_id

FROM account

GROUP BY DATE_FORMAT(date, '%Y%m')

;

各月最終取引のレコード取得と残高表示

最終取引のidに一致するレコードのみ元のテーブルから取り出すため、INNER JOINを使う。

SELECT
  id,
  DATE_FORMAT(date, '%Y年%m月') AS 年月,
  balance AS 月末残高
FROM mufj
INNER JOIN (
  SELECT
    MAX(id) AS max_id
  FROM mufj
  GROUP BY DATE_FORMAT(date, '%Y%m')
) AS monthly_final_transaction
ON id = max_id
;

SELECT

id,

DATE_FORMAT(date, '%Y年%m月') AS 年月,

balance AS 月末残高

FROM mufj

INNER JOIN (

SELECT

MAX(id) AS max_id

FROM mufj

GROUP BY DATE_FORMAT(date, '%Y%m')

) AS monthly_final_transaction

ON id = max_id

;

要点は以下の通り。

最終取引を抽出したクエリーをサブクエリ―として、そのidと等しいレコードのみを元のテーブルから抽出している
サブクエリ―にはエイリアスが必須
抽出された最終取引のbalanceを月末残高として表示
SELECT句のidは確認用で、表示目的としては不要

月ごとの入出金額を追加

上記のクエリーに、グルーピングされた月ごとの入出金額を追加する。

SELECT
  DATE_FORMAT(date, '%Y年%m月') AS 年月,
  monthly_withdrawal AS 出金額,
  monthly_deposit AS 入金額,
  balance AS 月末残高
FROM mufj
INNER JOIN (
  SELECT
    MAX(id) AS max_id,
    SUM(withdrawal) AS monthly_withdrawal,
    SUM(deposit) AS monthly_deposit
  FROM mufj
  GROUP BY DATE_FORMAT(date, '%Y%m')
) AS monthly_final_transaction
ON id = max_id
;

SELECT

DATE_FORMAT(date, '%Y年%m月') AS 年月,

monthly_withdrawal AS 出金額,

monthly_deposit AS 入金額,

balance AS 月末残高

FROM mufj

INNER JOIN (

SELECT

MAX(id) AS max_id,

SUM(withdrawal) AS monthly_withdrawal,

SUM(deposit) AS monthly_deposit

FROM mufj

GROUP BY DATE_FORMAT(date, '%Y%m')

) AS monthly_final_transaction

ON id = max_id

;

要点は以下の通り。

月ごとにグルーピングしているサブクエリ―で、SUM関数によって月単位の出金・入金額を計算
それらの値をエイリアスを使って元のテーブルで表示

このクエリーのチェックは、前月残高に当月の入出金額を加減して当月残高となることで確認できる。

MySQL – CSVファイルのインポート

2021-09-17 / tau / コメントする

概要

MySQLでCSVファイルをインポートする手順。

要点は以下の通り。

CSVファイルはUTF-8(BOMなし)で準備する
改行コードに注意
MySQLサーバーとクライアントの両方でローカルのファイル入力の許可が必要
- クライアントはログイン時のオプションで、サーバー側はグローバル変数で設定する

CSVファイルの準備

CSVファイルを準備し、MySQLで読み込む場所に配置する。CSV作成時の型と文字コードに注意。

型に関する注意点

数字だが001のように表現したい場合は文字列として扱う。

Excelの列の形式で適切な型を設定する

日付・時刻形式の空白値に注意。

日付・時刻値の列に空のデータがある場合にMySQLのdate/time/datetimeで読み込むと、NULL値ではなく'0000-00-00'や'0000-00-00 00:00:00'で埋められてしまう

文字コードの注意点

CSVファイルはUTF-8のBOMなしで準備する。

ExcelのシートをCSVファイルとして保存すると、UTF-8(BOMあり)になるので、メモ帳などで開いてBOMなしで保存し直す必要がある

MySQLログイン時のオプション

MySQLにログインするクライアントで、ローカルのファイル入力を許可する必要がある。

ログイン時に以下のオプションのいずれかを付ける

--enebale-local-infile
--local_infile=1またはon

$ mysql -u root -p --enable-local-infile

1	$ mysql -u root -p --enable-local-infile

MySQLログイン後の設定

グローバル変数の確認

SELECTかSHOW GLOBAL VARIABLESでlocal_infileの値を確認。この値が0/OFFの場合は許可されていない。以下のいずれかで確認できる。

SELECT @@local_infile;

mysql> SELECT @@local_infile;
+----------------+
| @@local_infile |
+----------------+
|              0 |
+----------------+
1 row in set (0.00 sec)

mysql> SELECT @@local_infile;

+----------------+

| @@local_infile |

+----------------+

| 0 |

+----------------+

1 row in set (0.00 sec)

SHOW GLOBAL VARIABLES LIKE 'local_infile';

mysql> SHOW GLOBAL VARIABLES LIKE 'local_infile';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| local_infile  | OFF   |
+---------------+-------+
1 row in set (0.01 sec)

mysql> SHOW GLOBAL VARIABLES LIKE 'local_infile';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| local_infile | OFF |

+---------------+-------+

1 row in set (0.01 sec)

グローバル変数の設定

SET GLOBALでlocal_infileの値を1またはONにセットする。

SET GLOBAL local_infile=1またはON;

mysql> SET GLOBAL local_infile=1;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@local_infile;
+----------------+
| @@local_infile |
+----------------+
|              1 |
+----------------+
1 row in set (0.00 sec)

mysql> SET GLOBAL local_infile=1;

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@local_infile;

+----------------+

| @@local_infile |

+----------------+

| 1 |

+----------------+

1 row in set (0.00 sec)

インポート実行

テーブルの準備

CSVの各カラムに対応した構造で、空のテーブルを準備しておく。

MySQLのtimestamp型の2038年問題に注意。

LOAD DATAの実行

SQLの例

CSVファイルをテーブルにインポートするSQLの例。

LOAD DATA LOCAL INFILE "ファイルパス"
  INTO TABLE テーブル名
  FIELDS
    TERMINATED BY ','
  LINES
    TERMINATED BY "\r\n"
  IGNORE 1 LINES
;

LOAD DATA LOCAL INFILE "ファイルパス"

INTO TABLE テーブル名

FIELDS

TERMINATED BY ','

LINES

TERMINATED BY "\r\n"

IGNORE 1 LINES

;

この例では、WindowsのようにCRLFで改行されたファイルを読み込み、区切り文字がカンマのCSVとして、先頭1行を飛ばして読み込む。

FIELDS

TERMINATED BY: CSV保存時に選んだ区切り文字を指定する。1文字である必要はない。デフォルトは'\t'。
ENCLOSED BY: フィールドを囲み文字を1文字で指定する。デフォルトは''(空)で、フィールドが区切り文字で囲まれていることを期待しない。OPTIONALLYを付けると文字列のみ囲み文字で囲まれていることを期待する。
ESCAPED BY: エスケープ文字を1文字で指定する。エスケープ文字に続く文字がエスケープシーケンスとして解釈される。デフォルトは'\\'で'\'一文字を表している。

LINES

STARTING BY: 指定したprefix以降のみ行として扱い、それ以外はスキップする。prefixは1文字でなくてもよい。デフォルトは''でprefixを設定していない(常に行頭から読み込む)。
TERMINATED BY: 行末の文字列を指定する。デフォルトは'\n'。

IGNORE

IGNORE 数値 lines/rowsで、先頭の指定した数の行／列を読み込まない。

PHP – 変数のコンソール表示

2021-09-09 / tau / コメントする

概要

PHPをコマンドラインで実行する場合に、変数の内容をコンソールに表示させるいくつかの方法を整理。JavaScriptのconsole.log()に比べて、何となく帯に短し襷に長し。個人的には使うとしたらview_export()か。

var_export()、print_r()については、結果の文字列を表示させるのではなく、戻り値として扱うことができる。

jason_encode()は趣旨が少し違うが一応加えておく。

変数の内容をコンソールではなくブラウザーに表示する場合はこちら。

準備

以下のような変数・値を表示させる。

$int = 100;
$str = '文字列';
$arr = [1, 2.0, 'three', '四'];
$asc = [
  'one' => 1,
  2 => '弐',
  '実数3' => 3.0,
];

$int = 100;

$str = '文字列';

$arr = [1, 2.0, 'three', '四'];

$asc = [

'one' => 1,

2 => '弐',

'実数3' => 3.0,

];

var_dump

var_dump()は引数の変数の内容を型まで含めて詳しく表示する。少し冗長。

変数ごとの表示後に改行される
変数を複数指定しても、別々に実行したのと同じ結果
キー・値の文字列はダブルクォートで囲まれる
実数はfloat[1]の様に表示される

var_dump($int, $str);
// int(100)
// string(9) "文字列"

var_dump($arr);
// array(4) {
//   [0]=>
//   int(1)
//   [1]=>
//   float(2)
//   [2]=>
//   string(5) "three"
//   [3]=>
//   string(3) "四"
// }

var_dump($asc);
// array(3) {
//   ["one"]=>
//   int(1)
//   [2]=>
//   string(3) "弐"
//   ["実数3"]=>
//   float(3)
// }

var_dump($int, $str);

// int(100)

// string(9) "文字列"

var_dump($arr);

// array(4) {

// [0]=>

// int(1)

// [1]=>

// float(2)

// [2]=>

// string(5) "three"

// [3]=>

// string(3) "四"

// }

var_dump($asc);

// array(3) {

// ["one"]=>

// int(1)

// [2]=>

// string(3) "弐"

// ["実数3"]=>

// float(3)

// }

var_export

var_export()は、var_dump()より簡潔な形で表示する。

結果をPHPのソースにコピー・ペーストして使える
表示後に改行されない
キー・値の文字列はシングルクォートで囲まれる
実数は小数部がゼロでも1.0のように表示される
配列の各要素末尾にカンマが付く

var_export($int); echo PHP_EOL;
// 100

var_export($str); echo PHP_EOL;
// '文字列'

var_export($arr); echo PHP_EOL;
// array (
//   0 => 1,
//   1 => 2.0,
//   2 => 'three',
//   3 => '四',
// )

var_export($asc); echo PHP_EOL;
// array (
//   'one' => 1,
//   2 => '弐',
//   '実数3' => 3.0,
// )

var_export($int); echo PHP_EOL;

// 100

var_export($str); echo PHP_EOL;

// '文字列'

var_export($arr); echo PHP_EOL;

// array (

// 0 => 1,

// 1 => 2.0,

// 2 => 'three',

// 3 => '四',

// )

var_export($asc); echo PHP_EOL;

// array (

// 'one' => 1,

// 2 => '弐',

// '実数3' => 3.0,

// )

print_r

print_r()はvar_export()より更に簡潔に表示する。

単純変数の表示後は改行されないが、配列の表示後は改行される
文字列はクォートで囲まれない
実数の小数部がゼロの時、整数と同じ表示になる
配列の要素末尾にカンマは付かない

print_r($int); echo PHP_EOL;
100

print_r($str); echo PHP_EOL;
文字列

print_r($arr);
Array
(
    [0] => 1
    [1] => 2
    [2] => three
    [3] => 四
)

print_r($asc);
Array
(
    [one] => 1
    [2] => 弐
    [実数3] => 3
)

print_r($int); echo PHP_EOL;

100

print_r($str); echo PHP_EOL;

文字列

print_r($arr);

Array

(

[0] => 1

[1] => 2

[2] => three

[3] => 四

)

print_r($asc);

Array

(

[one] => 1

[2] => 弐

[実数3] => 3

)

json_encode

変数の内容をJSON形式で返す。オプションのJSON_UNESCAPED_UNICODEを指定しないと、マルチバイト文字がHex表示になる。

echo json_encode($int) . PHP_EOL;
// "100"

echo json_encode($str, JSON_UNESCAPED_UNICODE) . PHP_EOL;
// "文字列"

echo json_encode($arr, JSON_UNESCAPED_UNICODE) . PHP_EOL;
// "Array\n(\n    [0] => 1\n    [1] => 2\n    [2] => three\n    [3] => 四\n)\n"

echo json_encode($asc, JSON_UNESCAPED_UNICODE) . PHP_EOL;
// "Array\n(\n    [one] => 1\n    [2] => 弐\n    [実数3] => 3\n)\n"

echo json_encode($int) . PHP_EOL;

// "100"

echo json_encode($str, JSON_UNESCAPED_UNICODE) . PHP_EOL;

// "文字列"

echo json_encode($arr, JSON_UNESCAPED_UNICODE) . PHP_EOL;

// "Array\n(\n [0] => 1\n [1] => 2\n [2] => three\n [3] => 四\n)\n"

echo json_encode($asc, JSON_UNESCAPED_UNICODE) . PHP_EOL;

// "Array\n(\n [one] => 1\n [2] => 弐\n [実数3] => 3\n)\n"

何とか'\n'を改行として表示するなら、以下の様にするか。

eval('echo ' . json_encode($asc, JSON_UNESCAPED_UNICODE) . ';');
// Array
// (
//     [one] => 1
//     [2] => 弐
//     [実数3] => 3
// )

eval('echo ' . json_encode($asc, JSON_UNESCAPED_UNICODE) . ';');

// Array

// (

// [one] => 1

// [2] => 弐

// [実数3] => 3

// )

Vagrant/Linux環境でPHPサーバーを起動する

2021-09-07 / tau / コメントする

概要

VagrantのLinux上でPHPのビルトインサーバーを立ち上げる。

ゲスト側IPアドレスの確認

Vagrant環境下でip aやifconfig -aを実行してネットワークインタフェイスのアドレスを確認する。

[vagrant@localhost php]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:0e:4e:dd brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global noprefixroute dynamic eth0
       valid_lft 74563sec preferred_lft 74563sec
    inet6 fe80::10ae:de8c:87bc:71ab/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

[vagrant@localhost php]$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

link/ether 08:00:27:0e:4e:dd brd ff:ff:ff:ff:ff:ff

inet 10.0.2.15/24 brd 10.0.2.255 scope global noprefixroute dynamic eth0

valid_lft 74563sec preferred_lft 74563sec

inet6 fe80::10ae:de8c:87bc:71ab/64 scope link noprefixroute

valid_lft forever preferred_lft forever

サーバーの起動

ビルトインサーバーの起動コマンドは以下のとおり。

php -S ホスト:ポート -t ドキュメントルート
php --server ホスト:ポート --docroot ドキュメントルート

ホスト部分に、確認したIPアドレスを指定する。ドキュメントルートに、実行ファイルが置かれる場所を指定する。

$ php -S 10.0.2.15:3000 -t ~/test/php

1	$ php -S 10.0.2.15:3000 -t ~/test/php

ブラウザーでの表示

ブラウザーでのURL指定は以下のとおり。

http://localhost:3000/phpファイル名

1	http://localhost:3000/phpファイル名

Laravel – artisan – ルーティングリストの表示

2021-08-30 / tau / コメントする

下記コマンドでルーティングのリストが表示される。

php artisan route:list

ただし、各ルーティングで呼ばれるコントローラー・アクションが定義されていなければならない。

実行例。

[vagrant@localhost laravel_photo]$ php artisan route:list
+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+
| Domain | Method    | URI               | Name          | Action                                      | Middleware   |
+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+
|        | GET|HEAD  | /                 |               | Closure                                     | web          |
|        | GET|HEAD  | api/user          |               | Closure                                     | api,auth:api |
|        | POST      | items             | items.store   | App\Http\Controllers\ItemController@store   | web          |
|        | GET|HEAD  | items             | items.index   | App\Http\Controllers\ItemController@index   | web          |
|        | GET|HEAD  | items/create      | items.create  | App\Http\Controllers\ItemController@create  | web          |
|        | DELETE    | items/{item}      | items.destroy | App\Http\Controllers\ItemController@destroy | web          |
|        | PUT|PATCH | items/{item}      | items.update  | App\Http\Controllers\ItemController@update  | web          |
|        | GET|HEAD  | items/{item}      | items.show    | App\Http\Controllers\ItemController@show    | web          |
|        | GET|HEAD  | items/{item}/edit | items.edit    | App\Http\Controllers\ItemController@edit    | web          |
+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+

[vagrant@localhost laravel_photo]$ php artisan route:list

+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+

+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+

| | GET|HEAD | / | | Closure | web |

| | DELETE | items/{item} | items.destroy | App\Http\Controllers\ItemController@destroy | web |

| | PUT|PATCH | items/{item} | items.update | App\Http\Controllers\ItemController@update | web |

| | GET|HEAD | items/{item} | items.show | App\Http\Controllers\ItemController@show | web |

| | GET|HEAD | items/{item}/edit | items.edit | App\Http\Controllers\ItemController@edit | web |

+--------+-----------+-------------------+---------------+---------------------------------------------+--------------+

MySQL – timestampの2038年問題

2021-08-30 / tau / コメントする

timestamp型とdatetime型

MySQLの日付・時刻表現にはtimestamp型とdatetime型がある。

MySQLのtimestamp型は内部表現に整数を用いていて、これが32bit精度の場合には、2038-01-19 03:14:07UTCまでしか表現できない。これは日本のタイムゾーンだと2038-01-19 12:14:07JSTに対応する。

一方datetime型は文字列で日時を表現していて、その範囲は1000年～9999年の間とされている。

timestamp型とdatetime型の有効範囲を比較すると以下のとおり。

timestamp	datetime
UTC内部表現で保持	タイムゾーン文字列で保持
1970-01-01 00:00:01UTC～2038-01-19 03:14:07UTC	1000-01-01 00:00:00～9999-12-31 23:59:59

timestamp型の2038年問題

確認環境

timestamp型で上限値より大きな値を登録しようとすると、エラーで登録ができない。このことを確認してみる。環境は以下のとおり。

Windows(64bit版)上のVagrant+VirtualBOXで構築したCentOS7
MySQLのバージョンは8.0.26

$ mysql --version
mysql  Ver 8.0.26 for Linux on x86_64 (MySQL Community Server - GPL)

1 2	$ mysql --version mysql Ver 8.0.26 for Linux on x86_64 (MySQL Community Server - GPL)

確認用のテーブルは以下のとおり。

mysql> DESCRIBE test;
+-------+-----------+------+-----+---------+-------+
| Field | Type      | Null | Key | Default | Extra |
+-------+-----------+------+-----+---------+-------+
| id    | int       | YES  |     | NULL    |       |
| time  | timestamp | YES  |     | NULL    |       |
+-------+-----------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> DESCRIBE test;

+-------+-----------+------+-----+---------+-------+

+-------+-----------+------+-----+---------+-------+

| id | int | YES | | NULL | |

+-------+-----------+------+-----+---------+-------+

2 rows in set (0.00 sec)

上限を超える値の登録は不可

まず上限値一杯の日時を登録してみる。UTCに対して日本のタイムゾーンで表現した2038年1月19日12時14分07秒を登録すると、問題なく登録される。

mysql> INSERT INTO test VALUES(1, '2038-01-19 12:14:07');
Query OK, 1 row affected (0.02 sec)

mysql> SELECT * FROM test;
+------+---------------------+
| id   | time                |
+------+---------------------+
|    1 | 2038-01-19 12:14:07 |
+------+---------------------+
1 row in set (0.00 sec)

mysql> INSERT INTO test VALUES(1, '2038-01-19 12:14:07');

Query OK, 1 row affected (0.02 sec)

mysql> SELECT * FROM test;

+------+---------------------+

| id | time |

+------+---------------------+

| 1 | 2038-01-19 12:14:07 |

+------+---------------------+

1 row in set (0.00 sec)

次に上限値に1秒を加えた日時を登録しようとすると、"Incorrect datetime value"となって登録できない。

mysql> INSERT INTO test VALUES(1, '2038-01-19 12:14:08');
ERROR 1292 (22007): Incorrect datetime value: '2038-01-19 12:14:08' for column 'time' at row 1

1 2	mysql> INSERT INTO test VALUES(1, '2038-01-19 12:14:08'); ERROR 1292 (22007): Incorrect datetime value: '2038-01-19 12:14:08' for column 'time' at row 1

timestamp型に対する加算の場合は9999年まで

次に登録された上限一杯の値に対してインターバルを加えていき、問題が生じるまでその境界を探していった。

その結果、9999年12月31日23時59分59秒999999…までは登録可能だが、10000年1月1日0時0分0秒に達することはできず、その場合にはNULLとなることがわかった。

mysql> SELECT time + INTERVAL 60*60*24*365*7967.23695944317605 SECOND FROM test;
+---------------------------------------------------------+
| time + INTERVAL 60*60*24*365*7967.23695944317605 SECOND |
+---------------------------------------------------------+
| 9999-12-31 23:59:59.999999                              |
+---------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT time + INTERVAL 60*60*24*365*7967.23695944317606 SECOND FROM test;
+---------------------------------------------------------+
| time + INTERVAL 60*60*24*365*7967.23695944317606 SECOND |
+---------------------------------------------------------+
| NULL                                                    |
+---------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SELECT time + INTERVAL 60*60*24*365*7967.23695944317605 SECOND FROM test;

+---------------------------------------------------------+

| time + INTERVAL 60*60*24*365*7967.23695944317605 SECOND |

+---------------------------------------------------------+

| 9999-12-31 23:59:59.999999 |

+---------------------------------------------------------+

1 row in set (0.00 sec)

mysql> SELECT time + INTERVAL 60*60*24*365*7967.23695944317606 SECOND FROM test;

+---------------------------------------------------------+

| time + INTERVAL 60*60*24*365*7967.23695944317606 SECOND |

+---------------------------------------------------------+

| NULL |

+---------------------------------------------------------+

1 row in set, 1 warning (0.00 sec)

32bitの上限を超えた後も値は保持されているが、その次の上限はdatetime型の上限と一致している。以下の何れかと推測される。

内部的には64bit表現だが、入力時には32bitの上限で、演算時にはdatetime型の上限で抑えている
内部的に32bit表現だが、その上限を超えたときにはdatetime型に内部的に切り替えている

まとめ

MySQLのtimestamp型は、2038年の上限値を超える値を登録できない
timestamp型に対する加算を行った場合、datetime型と同じ上限まで値を保持できる
- 加算後にdatetime型の上限を超えた場合の値はNULLになる

64bit整数の場合はtimestampも西暦3000億年弱まで扱い可能だが、一部が64bitシステムでも、データベース、言語、フレームワークの全てが対応していないとまずそうなので、日付時刻を扱う際はdatetime型としておくのが安全なようだ。

Tips – カラムの幅を一杯に広げる

2021-08-29 / tau / コメントする

概要

外枠の中に複数カラムを起き、1つのカラムを最大幅まで伸長するためのCSS。

外枠

外枠を表示領域の80%の幅とし、センタリング。

幅を表示領域の80%に：width: 80%;
左右方向のセンタリング：margin: 0 auto;

width: 80%; margin: 0 auto;

外枠の中に複数カラム

親要素にdisplay: flex;を指定し、伸長する子要素のみflex: 1;を指定。

2カラム～右拡張

外枠(親要素)：display: flex;
左側カラム：幅指定なし→内容に合わせる
右側カラム：flex: 1;→残り幅一杯

margin: 10px;

margin: 10px;flex: 1;
いづれの御時にか、女御、更衣あまた候ひ給ひける中に、いとやむごとなき際にはあらぬが、すぐれて時めき給ふありけり。

3カラム～中央拡張

外枠(親要素)：display: flex;
左側カラム：width: 10%;
中央カラム：flex: 1;→残り幅一杯
右側カラム：width: 10%;

width 10%;

margin: 10px;flex: 1;
いづれの御時にか、女御、更衣あまた候ひ給ひける中に、いとやむごとなき際にはあらぬが、すぐれて時めき給ふありけり。

width 10%;