more は less に vi は Vim と、コマンドはより少ないバグと高い性能を目指して進歩してきました。
最近は exa (ls) や ag (grep) 等、UNIX ツールの洗練も進んできています。
こういった「若い」コマンドを語り合いましょう。
>>17
digってnslookup共々、もはやFreeBSDの標準コマンドですらないんだな
今はhostかdrillを使うんだとさ 若くないけどmostってのがあったからちょっと使ってみたらlessとキーが全然違って使いにくかった
bash のスクリプトに
continue 2
っていうセンテンスがあって、見た瞬間、意味は分かったんだけど、
こんなの昔は無かったなー
って思った。
0048名無しさん＠お腹いっぱい。2018/05/22(火) 02:39:20.93
知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
HOF51
趣旨に合ってないかもしれんが
Linuxでネットワーク関連のコマンドの置き換えが進んでるみたいね。
ipやらまた新しい操作法覚えなきゃならないけど、ただ今までより体系立ってるし分かりやすいのは事実だから
変更する価値は多少あると思った。
0050名無しさん＠お腹いっぱい。2018/06/04(月) 20:46:48.44
まったく最近の若いコマンドは苦労ってものをしっちゃいねぇ
俺らの頃はな、遅いCPUと少ないメモリでどうやって仕事を
実現できるってのを考えて働いたもんだ
>>50
違う違う。「ip」というコマンドがあるんだわ。 0053名無しさん＠お腹いっぱい。2018/07/07(土) 19:12:29.31
>>53
ああ，そうなんだ。それは知らなかった。
申し訳ない。 >>55
ゴミ
https://uec.usp-lab.com/TUKUBAI/CGI/TUKUBAI.CGI?POMPA=ABOUT#ann01
> usp Tukubaiを試用目的で利用できるようにしたバージョン。
> Windows版、CentOS版、Mac OS X版が用意されている。ダウンロードした月から
> 向こう6ヶ月の月末まで使用可能（2016年2月1日にダウンロードした場合、
> 2016年8月末まで使用できる。商用利用は不可）。
> usp Tukubaiの強力な機能をそれぞれのオペレーティングシステムで手軽にためすことができる。
> ライセンスの購入やPersonal Tukubaiの取得に関してはUSP研究所のソフトウェア Personal Tukubaiを参照のこと。 ま，まあPythonによる再実装があるし……（震え声）
0058名無しさん＠お腹いっぱい。2018/09/11(火) 20:26:33.53
Unicodeの正規化や文字幅を扱えるコマンド群ってないっすか。
0059名無しさん＠お腹いっぱい。2018/09/13(木) 19:18:55.26
aria2c
これいいね。出力も見易い。
このスレだったか。最近usp Tukubaiの話書いていた所 >>55-56
シェルスクリプトを便利にするコマンドあるかなーって思って
コマンドリファレンスみてみたのよ
https://uec.usp-lab.com/tukubai_man
これ、全く使えねーなｗ
> usp Tukubaiは基幹業務システム、情報分析システム、データバッチ処理、
> 高速検索システム、勘定系システムなどにおけるシェルおよびシェルスクリプトの
> 用途を広げるためのUNIX環境用コマンド群であり、
たしかにこう書いてあるが、これ完全に
特定用途向けのツールでしかないな
一般的なシェルスクリプトを便利にするものではなく
COBOL的な業務システムのプログラムでよく使われる処理を
シェルスクリプト用のコマンド（関数）として実装したものに過ぎない RDB使えない/RDBだと性能出せないような老害だから仕方ないよ。
というか今時データベースで業務管理してる時点で なにか察せるものがあるよね
｢今時｣とか書いて騙せると思ってるところがすごいよね。
まあこれで騙せるような情弱をカモにしてるんだろうけど。
怪しげな情報商材とかが、正気の人間なら引っかからないような
ろくでもない宣伝文句を使ってるのと同じ戦略かな。
nprocコマンド::
CPUのプロセッシングユニットの数を表示する
（今まで/proc/cpuinfoとかを自力でパースしてたけど
こっちのほうが確実だし なにより楽）
archコマンド::
CPUアーキテクチャを表示する
書式が統一されていて 余計な文字列がないのでスクリプトなどで安全に簡単に扱える
>>68
> （今まで/proc/cpuinfoとかを自力でパースしてたけど
パースするほどのことでもないと思うんだけど？
grep processor /proc/cpuinfo | wc -l >>69
> archコマンド::
man archしたらuname -mと同じって書いてあってワロタｗ archってSolarisって名前がつく前のSunOSの時代からあるので全然最近じゃない。
あとnprocみたいに専用コマンドをどんどん増やすより、
各種パラメータをとってこれるgetconf使った
getconf _NPROCESSORS_ONLN
の方がいいんじゃね？
>>70
俺もそれに近いことはやってたけど，
必ずしも/proc/cpuinfoファイルに「processor」の項目があるとは限らなくね？
その点nproc(1)ユーティリティーはGNU Coreutilsに含まれてるのでGNU/Linuxなら確実に動く。
そういう違いかな。
もしかしたら/proc/cpuinfoに規格があるのかも知れんが，調べてないw realpath (GNU Core Utilities)
これ便利やわ。今までbasenameとか使って判定してたのが一発で済む。
ただFreeBSDとかだと始めからは使えない。
bashも最近カレントディレクトリのファイル実行に./要らなくなったね。
>>78
それセキュリティホールになるから勘違いでは?
間違って $PATH に｢.｣を加えちゃっただけじゃない？ 空文字列も｢.｣と同じ扱いになるから、
$PATH の先頭か末尾に｢:｣が余分についてるか、途中に｢::｣があるのかもね
悪漢がいるなんて思いもしなかった古き良き時代のあれやで
昔はデフォルトで$PATHに . を入れてたぐらいだからな。
時代は変わった。
昔は平和で良かった（老害並感）
ともあれ$PATH変数はreadonly付けてもいいくらいだよね。
>>85
それで防げる脅威が存在する状況なら、既に侵入されてるってことだから無意味だよ。 >>87
どういう attack vector を阻害できるのか説明してみて >>88
クラッカーが管理者権限を持っていない場合
↓
管理者権限を持つ人物に自分を昇格して欲しい
↓
管理者権限を持つ人物が実行するスクリプトに細工する
PATHを弄って自分が作成した害のあるスクリプトがあるディレクトリに通す
↓
管理者がそれを実行する
↑これを防げます。 管理権限を持つ人間が実行するスクリプトを改変できた時点で
既に侵入に成功できていて
そのスクリプトの中で管理権限で何でもやり放題じゃん。
$PATHを改変するまでもない。
だから全く無意味。
自分で書いてて｢管理者が〜実行する｣が
2回出てきたあたりで変だと気づかなかったのかな？
> 管理権限を持つ人間が実行するスクリプトを改変できた時点で
> 既に侵入に成功できていて
> そのスクリプトの中で管理権限で何でもやり放題じゃん。
ワロタw
こんな過疎スレじゃなきゃ今頃コピペ化してるかも知れん
0093名無しさん＠お腹いっぱい。2024/03/27(水) 19:56:33.51
サンダル
タバコ吸うくらいストレス溜まってるんやがな
0094名無しさん＠お腹いっぱい。2024/03/27(水) 20:08:36.53
これアニメ化も求める。
> 1000兆円規模の個人貯蓄を投資へと後押しする。