Linuxでファイルの先頭部分を表示する方法

Linuxでファイルの先頭部分を表示する方法の実務上の結論は「先頭行はhead -n、先頭byteはhead -cを使い分けます。構造化fileのheaderは専用parserを優先し、type・size・encodingを先に確認します。」です。header確認はtext line、固定byte、NUL recordのどれを数えるかでcommandを分けます。先頭sampleが取得できても、file全体の形式や安全性まで確認済みとはみなしません。

目次

先頭行と先頭byteを区別する

headは既定で先頭10行を表示し、-nは行数、-cはbyte数を指定します。headerが『最初の一行』とは限らず、BOM、comment、空行、固定長binary headerなどformatごとに定義が違います。textの冒頭確認、magic byteの調査、streamのsample取得を同じ手順にせず、必要量と単位を先に決めます。

head -n 40 — fileは40行、head -c 64 — fileは64byteです。複数fileを渡すとfile名headerが挿入されるため、自動処理では対象を一件ずつ扱うかquiet指定の挙動を確認します。負の-nなど末尾を除くGNU拡張は移植性を確認し、POSIX環境向けscriptでは利用可能なsyntaxを実機manualへ合わせます。

line単位かbyte単位かを先に選ぶ

  • line単位かbyte単位かを決める
  • headerの正式なformatを確認する
  • encodingとBOMの有無を確認する
  • 機密値が先頭へ含まれないか確認する

CSVなら論理recordが改行を含む可能性を、binaryならmagic領域の必要byte数を先に確認します。測定単位が決まらない時は実行を止め、仕様書と小さなfixtureからhead -n、-c、-zのどれかを選びます。

head -n・-c・-zを別fixtureで試す

先頭十行を表示

head -n 10 -- ./data.txt

既定値に依存せず必要line数を明記します。

最初の一行だけ表示

head -n 1 -- ./table.csv

CSVではquoted multiline fieldがあるとrecord一件とは限りません。

先頭64byteを取得

head -c 64 -- ./sample.bin | od -An -tx1

binaryは直接terminalへ出さずhex表現で確認します。

複数fileへ見出しを付ける

head -n 5 -- ./a.txt ./b.txt

GNU headのfile名headerと本文を後続parserで混同しません。

NUL区切り入力の先頭を扱う

head -z -n 3 -- ./records.bin | od -An -tx1

GNU拡張の-zが対象versionにあることをhelpで確認します。

headの終了とpipelineを読む

head -nはnewlineで区切られたline、-cはbyteを数えます。UTF-8の途中byteで切ると表示不能な断片になる場合があります。CSV、JSON、compressed fileは先頭lineがschemaや一recordと一致するとは限らず、専用toolが必要です。

行数指定はnewlineまでを単位にするため、newlineのない巨大一行では大量dataが出ます。byte指定はUTF-8文字の途中で切れ、表示が文字化けしても原本破損とは限りません。pipe入力ではheadが必要量を得て終了するとproducerがSIGPIPEを受けることがあり、pipeline全体の失敗とhead単体の成功を分けて評価します。

空file、短いfileは要求数より少ない出力でも正常終了し得ます。read error、directory指定、権限不足、途中truncateはstderrとstatusで区別します。圧縮fileの先頭をtextとして読んでも展開後headerにはならず、binary control byteをterminalへ出す危険があります。format固有のheader位置を思い込みで決めません。

短いfile・NUL record・SIGPIPEを区別する

  • headの既定10行を仕様として固定する
  • -cを文字数と解釈する
  • CSV一行を一recordと断定する
  • binary control byteをterminalへ出す
  • 複数fileの見出し行をdataへ数える

要求数より短い出力は直ちにerrorではなく、短いfileまたは少ないrecordかもしれません。pipelineのSIGPIPE、read error、空fileをstatusで分け、byte数が不足した場合は原本を変更せず再取得元を確認します。

先頭確認を全量dumpへ拡大しない

headerにtoken、email、内部host名があるfileを共有screenへ出しません。binaryを直接出す代わりにod等で制限付き表示します。原本を変更しないcommandだけを使い、pipe先の保存場所とpermissionも確認します。

secret fileやunknown binaryの先頭にもcredentialやcontrol sequenceが含まれ得ます。表示量が少ないから安全とは考えず、file typeと閲覧権限を先に確認します。production streamへheadを挿入するとupstreamの終了挙動を変える場合があるため、監視中pipelineへ無断で追加せず、複製したtest streamで確認します。

空・1行・改行なし・64byte入力でhead出力を照合する

空file、1行、9/10/11行、末尾newlineなし、UTF-8 multibyte、BOM、binaryのsampleを作ります。wc -l/-cと比較し、出力byte数と原本hashを確認します。さらに一行が非常に長いcase、quoted multiline CSV、compressed file、読み取り途中で更新されるfileを分離して試します。手順書にはline数かbyte数か、表示時のencoding、切断されたmultibyteをerrorとする条件、機密headerを共有しない基準を明記し、同じsampleを別端末でも再現します。

0行、1行、10行、11行、newlineなし巨大一行、UTF-8多byte、CRLF、binary、pipeをsampleにします。-nと-cの出力byte数、line数、終了status、producer側statusを期待表へ照合します。複数file時の見出し、file名にdashやnewlineがある場合の扱いも確認し、原本hashが不変であることを記録します。

scriptでは『10行出た』だけを成功条件にせず、必要fieldがparseできたか、短いfileを許容するか、最大byte数を越えないかを定義します。headの結果をJSONやCSVの完全recordとみなさず、multiline recordは専用parserへ渡します。producerのstatusを取得できるshell設定とtimeoutを用意し、partial outputを完全dataとして保存しません。

先頭sampleから次のparserを決める

冒頭の目視ならhead -n、binary signatureならodやxxdなどのbyte表示、構造化formatならparser、継続streamなら専用consumerを選びます。headerだけでversionや安全性が確定しないformatでは、size、hash、signature、validator結果を追加します。必要な判断単位が行かbyteかを決めることが、option選択の出発点です。

headでは行数を指定する-nとbyte数を指定する-cを混同しません。pipeの後段が必要量を読んで終了すると、前段がSIGPIPEを受ける場合があるため、pipeline全体の終了値を保存するときはpipefailの有無も記録します。binary fileや非常に長い一行では端末へ制御文字を出さず、fileで種類を確認してから安全なcopyへ適用します。

合格はLF text、NUL record、空file、64 byte未満のbinaryで取得単位と件数が期待どおりになることです。形式が不明なsampleは後段へ送らず、od結果を添えてparser選定へ戻します。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次