Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
はじめに mkdir, ls, cp, touch, mv, rm以上のコマンドにあんまり触れていない。。。という方、もっとコマンドを使いこなしたい！という方。。。必見。 基本的だが全部網羅するには大変な基本コマンド及びショートカットを溢れんばかり71選お届けします。たくさんありますので、表題に何のコマンドか書いてあるのをご活用ください。 一部、macユーザー向けとなっていることをご了承ください。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 Ctrl を使ったショートカット 最初に、Ctrlを使ったショートカットを紹介します。 Ctrl-A 行頭移動 ↓ Ctrl-E 行末移動 ↓ Ctrl-W 直前一単語を削除 ↓
One thing that all programs on your computer have in common is a need for memory. Programs need to be loaded from your hard drive into memory before they can be run. While running, the majority of what programs do is load values from memory, do some computation on them, and then store the result back in memory. In this post I'm going to introduce you to the basics of memory allocation. Allocators
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ～ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題ShellScriptUNIXshellシェル芸POSIX はじめに シェルスクリプトで ls コマンドの出力結果（ファイル名一覧）をパイプで他のコマンドに渡して処理するのは推奨されません。ls コマンドを使ったコードを ShellCheck で検査するとおそらく問題があると警告が表示されるでしょう。ls を使うなという指摘自体には賛成なのですが SC2010、SC2011、SC2012 に書いてある理由については正しい説明がされていないと思っています。この記事ではなぜ ls の出力結果を他のコマンドにパイプで渡すのが悪いのか、ls を使わずに実現するにはどうしたら良いのかを解説したいと思います。一つ補足をしておくと、この問題は CLI コマ
なんだろう、嘘つくのやめてもらっていいですか？ 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか？ シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか？ そんなことあ
jq（https://stedolan.github.io/jq/）の紹介では、「JSON処理のワンライナー〈一行野郎〉としてめちゃくちゃ便利！」とアピールするのが定番です。もちろんそれは本当で、「めちゃくちゃ便利！」です。が、実は jq は、ワンライナー記述にとどまらない、かなり本格的なプログラミング言語です。 JSON処理のためのDSL〈Domain Specific Language | 領域特化言語〉なので、汎用言語ではありません。しかし、汎用言語が備えている言語機能の一部（関数定義、モジュールシステムなど）を jq も持っています。また jq は、独特で楽しいプログラミング・パラダイム -- “パイプライン指向”に基づいて設計されています。 この記事では、ワンライナーを超えた jq の使い方と、プログラミング言語としての jq の特徴を紹介します。長い記事になってしまったので、一
社内で、crontabのtabは実はtableだからクーロンタブじゃなくてクーロンテーブルなんだよね、という話が盛り上がった。 ファクトチェックとして、crontab(5)が紹介されていた(cron tableという言葉が出現している)。 manで事実確認がすぐできてすごいと思う一方、それを可能たらしめているmanもありがたいと思った。 man(1) とかの数字って何？ 意外なものにmanがある 最近のコマンドにman pageが無い件 manまわりのコマンドの紹介 man(1) とかの数字って何？ ちなみに、manのマニュアルやコマンド自体をアドレスするときに使うman(1)といった記法のカッコ内の数字は、manのセクション番号である。 コマンドと設定ファイルが同名であることがしばしばあるため、カッコ内にセクション番号を書くことで識別できるようにしている(例えば、crontab(1)はそ
UNIXができたころのことを話そうとするとその頃のコンピューター事情が今とだいぶ違うのでなかなか話が伝わりません。そこでそのころ（1970年ごろ）のコンピューター事情について、正確性はちょっと置いておいて、分かりやすいようにざっくりと説明したいと思います。 アポロ11号の月面着陸が1969年なのでその辺りの映画などに出てくるでかいコンピューターを想像するとイメージしやすいかもしれません。 ## 大雑把な分類 初期のUNIXが開発されたころ（1970年ごろ）に使われていたコンピューターは主に下記の二種類でした。 - メインフレーム - ミニコン（ミニコンピューター） このころ主に"コンピューター"といえば今で言う"メインフレーム"のことを指していました。 マイコン（マイクロコンピューター）／パソコンは1980年ごろ普及しました。しかしパソコンでUNIXを動かすのが実用的になったのは1990年
はじめに 環境の用意 ブートプログラムを作る 動かしてみる コンパイル QEMU上で起動 GDBで制御 最後に おまけ 執筆者 : 高橋 浩和 ※ 「RISC-V OSを作ろう」連載記事一覧はこちら ※ 「RISC-V OS」のコードはgithubにて公開しています。 はじめに RISC-VはMIPSアーキテクチャの流れを汲む正統派？のRISC CPUです。命令セットはシンプルですが、既存のメジャーなCPUのアーキテクチャと大きな違いがあるわけではありません。 Linux上で利用できるRISC-Vツール群も揃ってきたので、それらを使ってRISC-V用の小さなOSを実装してみようと思います。 最初は欲張らずに単純な実装を目指すことにします。 シングルコアのみサポート 64bitモードを使用 マルチタスキングを実現 タイムシェアリングスケジューリングを実装 割り込みネストは無し 保護機能は使わ
こんにちは、カナダに来て1年弱ですが、いまだに"how are you?"にアイムファインセンキューと返してしまう全然英語が上達してない聖賢です。 インフラエンジニアならみんな大好きtopコマンド、おそらくビヨンドの中ではサーバ運用の中で最初に覚えるコマンドじゃないでしょうか。 実は結構奥が深いコマンドでいろんなことができるので、これまでドヤ顔で「こんなこともできるんやで」と上司の威厳、、、もとい先輩としての経験を後進に伝えていたのですが私も最近になって初めて知った超便利な使い方を紹介したいと思います。 ちょっと長いですがお付き合いください。 普通にtopコマンドを実行すると以下のような画面が表示されます 結構これだけでもサーバ運用には重要な情報が詰まっているのですが、topコマンドの見方などは他でも色々と紹介されていると思うので今回は割愛します 今回はこのtopコマンドの表示を最終的にこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
