シェルスクリプト総合 その33

■ このスレッドは過去ログ倉庫に格納されています
2020/03/23(月) 01:12:30.31ID:TYte82vJ
シェルスクリプトに関する総合スレッドです。

全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット（死語）を意識しましょう。
・「○○（他の言語）でいいやん」は禁止。他のスレに行ってください。

シェルスクリプト総合 その32
https://mevius.5ch.net/test/read.cgi/tech/1571929725/
2020/06/26(金) 21:44:27.05ID:WqCeXtR5
>>509
無くなってないだろ
2020/06/26(金) 22:04:15.47ID:WqCeXtR5
>>510
foo () {
echo "$1='$(eval echo "\"\$$1\"" | sed -e "s/'/'"'\\'"''/g")'"
}

VAR='a
b=c
d'

echo "$VAR"
bar="$(foo VAR)"
echo "$bar"
VAR=''
echo "before: $VAR"
eval "$bar"
echo "after: $VAR"

一応dashで動いているようだけど？対処できないって？
2020/06/26(金) 22:33:00.77ID:WqCeXtR5
とりあえず、三つの環境で試してみたが動いているかな
こんな簡単でいいのかというのは拭えないが

しかし、
コード書けないのか書かないのか、
ちゃんと考えず検証もせずに、
自分の頭の中もしくはおま環だけで、
解決にも繋がらないのをよく続けてたな、どっちも
って感じ
2020/06/26(金) 22:55:36.19ID:Sc0VO8uZ
出、出〜両成敗言奴〜
2020/06/26(金) 23:06:55.36ID:WqCeXtR5
レスはするがそんなレスしかしないのは、
対処できないってことはないってことでいいいのね
2020/06/27(土) 09:22:36.01ID:VhavnPnf
最近はpwshが便利でお気に入り
bashは何をやるにもめんどくさくてだめだ
未だに引数の解析をloopとcaseでやるとか原始時代かよ
2020/06/27(土) 09:40:10.35ID:gS37C1rZ
その程度の問題ならライブラリを作るだけで解決するんだがな
2020/06/27(土) 22:42:10.04ID:712NPp+Q
getopts知らない可能性が微レ存
2020/06/27(土) 22:53:58.90ID:vaH0ijdP
getoptsもループだろ
2020/06/27(土) 23:10:59.70ID:gS37C1rZ
getoptsは文字列操作が苦手なC言語のためのもので
それをそのままシェルスクリプトに移植しても
あまり意味がないんだよな

しかも設計がUnixの歴史の初期の頃のものだから
最近の言語のものに比べて使いやすくもない
2020/06/28(日) 18:17:34.25ID:AbPoRZT9
rust製のコマンドが流行って来てるね
shft-jis対応が微妙なのが多いけど
2020/06/29(月) 11:20:40.30ID:rI2xXdg9
今時Shift-JISなんて使ってるとこがおかしいw
2020/06/29(月) 15:44:22.24ID:6OaJq9UQ
Windowsでbashやpythonのスクリプトを書いてると
表立っては目に見えなくはなってるけど
未だにcp932の呪縛から逃れられない
エラーが出て改めて気付かされる
2020/06/29(月) 17:28:25.05ID:KH0T80po
WSLでええんちゃうの
2020/06/29(月) 19:53:16.74ID:tYVp58Ca
cp932を使う必要ないよ
2020/06/29(月) 19:55:39.65ID:tYVp58Ca
そもそもファイルはUTF-8で書く
各コマンドはWindowsネイティブのUTF-16で出力する
（UTF-16はWSLにわたすとUTF-8に変換される）

とまあUnicodeで完結するわけで
cp932とかいらないし、でてこない。
2020/06/29(月) 22:49:57.66ID:P14Kkthl
WSLのウリの一つであるLinuxとWindowsのシームレスな運用という点を活かそうと、
WSLからWindowsのプログラム（cp932対応）を呼び出し、応答を受けたりしようとする場合には、
cp932に全く触れないで済む、とは必ずしも言えないでしょう。

これに加えて、python 2だった頃は、もうユニコード地獄とともに、cp932を常に意識しないとならなかったけど、
python 3になって、ずいぶん楽になったわ。

いずれにしても、対応するプログラム次第だな。
2020/06/29(月) 23:21:10.60ID:cNuHuLWV
>>532
> WSLからWindowsのプログラム（cp932対応）を呼び出し
なんのことでしょうか？

まずWindowsのコマンドは全てUnicode対応です。
chcp 65001でUTF-8に変更してちゃんと表示されるのがその証拠です。

またWSLからWindowsのコマンドを呼び出した場合、それはUnicodeで出力されます。
例えば絵文字などcp932にない文字を含んだファイル名があるディレクトリを表示してみてください
問題なく表示されるはずです。

例 WSL上で実行: $ cmd．exe /c dir c:\\dir


同様にそのコマンドを他のプログラムにリダイレクトしてみてください

例 WSL上で実行: $ cmd．exe /c dir c:\\dir | less

この場合chcp 65001されたのと同じように英語モードに切り替わりますが
ファイル名は文字化けしません。nkfを使えばUTF-8であることが判明します。

例 WSL上で実行: $ cmd．exe /c dir c:\\dir | nkf --guess
UTF-8 (CRLF)

WSLからWindowsのコマンドを呼び出す際、cp932に触れることはありません。
2020/06/30(火) 00:47:57.76ID:qHUx6lkJ
cp932とかshift-jisとか別に対応しなくてもいい、必要ならユーザ側で変換すればいいだけの話でもある
cp932とかshift-jisとか日本でも今更の方が多いのに、日本／日本人じゃないプロダクトで対応を求めるのはまあない話だな
2020/06/30(火) 00:54:07.86ID:3w3RlvW0
>>532
>ユニコード地獄
って何？？地獄というほどだからすぐに出せるほどのでしょう
まさか、よくある非難批判自説強めるためにだけのことさらのではないだろうから、具体的にどうか
2020/06/30(火) 13:29:30.53ID:4tQoD8Fw
言いたい事は伝わるけど日本語が不自由すぎる
2020/06/30(火) 13:45:57.96ID:ww2Xd+MO
結局文字コードに関しての理解が浅いから
Windowsはcp932なんだよ！だからcp932を使うんだよ！
そしてcp932扱おうとすると難しいんだよ！ってなるんだよ

普通にUTF-8を使っていれば、Windows（Unicodeがネイティブの文字コード）とも
Linuxとも相性がいいのに
2020/06/30(火) 14:08:10.20ID:rT4NJ8lb
テキストの中身はいいとしてファイル名()
2020/06/30(火) 16:43:12.21ID:v6RmXu90
ファイル名でも同じだな
結局文字コードに関しての理解が浅いから()
2020/06/30(火) 17:02:50.63ID:NeVIM/JQ
cp932を使ってる環境が今でもある以上、それに対応する必要はあるだろ
自分で管理できる環境しかいじらないのであれば、utf-8にでも統一すればいいが
そうじゃない場合はそのままではどうしようもない

utf-8が当たり前だと思ってるやつは、euc-jpとかも使ったこともないんだろうな
以前はperlなんかのcp932ダメ文字対策にはこれしかなかった
2020/06/30(火) 17:11:34.24ID:2vqY+HLu
めんどくさいのを知ってるからUTF-8に統一できるのだからそれにしたそれにするって話なのに
未だにcp932だの言ってるのはめんどくさくないんだろ？文句言うなw
2020/06/30(火) 18:38:38.55ID:KNAz+qB3
めんどくさいけどそれを避けられないという場合もあるという話だろ
巷にはまだまだ古い環境が残ってるんだよ
自分のせいじゃないんだから文句くらい言わせろw
2020/06/30(火) 19:14:10.54ID:XR44DBqi
チラ裏にでも書いてろって話だな
2020/06/30(火) 19:24:16.74ID:nJuhvFVE
cp932 を UTF-8 にマイグレーション：めんどくさいからやりたくない
cp932 <> UTF-8 処理中に逐次相互変換：めんどくさいからやりたくない
cp932 <> UTF-8 フロントエンドで相互変換：めんどくさいからやりたくない
自分で対応できることをやりたくないから、誰かがcp932対応しろ
って話ですね
2020/06/30(火) 20:52:19.85ID:tmp+8cJm
すでにcp932に対応しているので遠慮しておきます
2020/06/30(火) 21:00:48.27ID:ww2Xd+MO
>>540
> cp932を使ってる環境が今でもある以上

UTF-8に変換して処理が終わったら戻せばいいだけ
2020/06/30(火) 21:54:26.59ID:nHUgkpqk
それを世の人は「対応」という
2020/07/01(水) 00:00:33.48ID:nsCEyl21
元レスのヤツがその対応してないのに対してのだろ
とんちんかんじゃね
2020/07/01(水) 00:55:56.18ID:bhKr/oya
日本語でおk
2020/07/01(水) 01:31:07.01ID:keO9QSLH
Windows を使うのは大変なんだな。
…ああ、それが無理だから Linux しか使わなくなったんだった。
2020/07/01(水) 06:57:53.27ID:lozEWamw
多分なcp932をUTF-8に変換して戻せばいいって聞いた時
間抜けなやつは、コードの中でいちいち変換してるんだよ

func() {
　str_sjis=$1
　str_utf8=$(sjis_to_utf8 "$1")
　ret_utf8=$(foo "$str_utf8")
　ret_sjis=$(utf8_to_sjis "$ret_utf8")
　echo "$ret_sjis"
}

こんな感じでな。コードのあちこちでこのような変換を行ってる。
あー、あほあほ、ばからしすぎる

コマンド呼び出しの前に外部コマンドで変換してしまうという発想がない
2020/07/01(水) 07:44:48.00ID:61AWgfbD
cp932からutf8は不可逆変換
2020/07/01(水) 08:54:24.38ID:lozEWamw
>>552
それがどうかしたの？
2020/07/02(木) 00:24:14.35ID:oVzUH9JU
自己紹介しなくてもいいのにねぇ
2020/07/02(木) 00:53:42.38ID:9cYvmHwP
テキストエディタを作る時、内部のデータをUnicodeで持つか
あらゆる文字コードでデータが持てるようにするかの違い

あらゆる文字コードに対応するのは大変だから
ファイル読み書き時に変換し内部データはUnicodeでもつのが普通

シェルスクリプトで言えばiconvやnkfなどのフィルタを使って
文字コードを変換すれば、シェルスクリプトでは全てUTF-8として扱うことができる
シェルスクリプト以外の各言語でも同じことができる
なぜ未だにcp932のことを考える必要があるのかわからない
2020/07/02(木) 00:58:14.59ID:9cYvmHwP
そもそもWindowsはUTF-16がネイティブで
すべてのCLIコマンドはUTF-16で出力するのに
一体誰がcp932を出力するのかわからない

なおWindowsから標準出力にUTF-16で出力したデータは
WSL上のコマンドで受け取ったときには自動的にUTF-8に変換されている
（ファイル読み込み時に勝手にデータが変換されるという意味ではない）
2020/07/02(木) 04:04:30.63ID:7rdALa4M
>内部データはUnicodeでもつのが普通
厳密にはOS(API)のネイティブな文字コードだな
今時のOSのはUnicodeだから間違ってもいないけど、多分、古いWindowsのはShift-JISなんじゃないかな
2020/07/02(木) 04:37:48.98ID:9cYvmHwP
古いWindowsとか適当なことを言うな
Windows 95よりも早く開発していた
Windows NTは最初からUnicodeだ
2020/07/02(木) 04:57:08.09ID:mSCtcEnU
XPでCygwinでシコシコやってた頃は、
cp932やらeuc-jpやらで大変だったなぁ
対応版が出るまで、utf-8？ 何それ美味しいの？ 状態で、
まともに使えるように、いろいろおまじないしてたっけ
2020/07/02(木) 10:38:14.71ID:6iBChMal
>>95
Windows 95よりも早く開発していたなんて嘘言うなよ
内部と表層は違う。Unicodeが表層にもなったのは最近だろ
Windows 95よりも早くとか曖昧なとこで完全な嘘だしな。痴呆で忘れたか？
2020/07/02(木) 10:39:39.66ID:6iBChMal
>>560
誤 >>59
正 >>558
2020/07/02(木) 12:02:46.70ID:9cYvmHwP
>>560
https://ja.wikipedia.org/wiki/Microsoft_Windows_NT#%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%89%E9%81%B7%E5%8F%8A%E3%81%B3%E3%81%9D%E3%82%8C%E3%81%9E%E3%82%8C%E3%81%AE%E7%89%B9%E5%BE%B4

> IBMと共同で開発していたOS/2のバージョン2の次期バージョンをWindows NTとし、
> IBMとは別に製品を開発していくこととなる。最初のバージョンは3.1であり、
> これ以前に発売されていたWindows 3.1と互換性があるため、Windows NTの
> 最初のバージョンも3.0ではなく3.1として発売した。これはWindows3.1と歩調を揃えるという、
> マーケティング上の理由による。
>
> 以下、英語版の発売年を併記する。
>
> Windows NT 3.1（1994年）
>
> 初期バージョン。コードネームはWNT。デスクトップ シェルとしてWindows 3.1と
> 同じユーザインタフェースを採用していた。英語版は1993年7月27日に発売された。
2020/07/02(木) 12:05:14.83ID:9cYvmHwP
>>560
表層とか曖昧なことを言うなよ
アプリの問題とOSの問題は違う

Windows NTの表層（笑）はUnicodeだ
9x系用アプリの表層が違うだけ
2020/07/02(木) 13:33:50.59ID:ACoXsYjy
Windows API には システムエンコーディング対応のとUnicode対応のがある
日本語に限っては、システムエンコーディングがUTF-8対応になったのはつい最近、当然それ以前はShift-JIS
てとこかな、ググったとこでは

UTF-8に対応してないのにわざわざUnicodeに対応しようとはしないわな当たり前に
システム内部でUnicode対応していようが、Shift-JIS APIしか「使えない」んだったら内部で対応していようがデベロッパーには見えない部分だし、そんなアプリが普通でもおかしくはないな
2020/07/02(木) 13:45:58.39ID:ACoXsYjy
>>562
なんの引用かいまいちわからんけど、Windowsが内部的にUnicodeになったのはWindows NTからみたいだけど。普及したというならWindows 2000からか
(それでも内部でUnicodeだろうがShift-JISがデフォのようだけど）

Windows 9x 前(もちろん 3.1も)までは限定的なUnicode文字列操作ライブラリがあったとかかな
2020/07/02(木) 15:28:28.91ID:9cYvmHwP
>>564
> 日本語に限っては、システムエンコーディングがUTF-8対応になったのはつい最近、当然それ以前はShift-JIS
> てとこかな、ググったとこでは

日本語がおかしい。知らないなら適当なこと書くなよ

> システム内部でUnicode対応していようが、Shift-JIS APIしか「使えない」んだったら
人の問題を持ち出すな。
無能が使えないからってなんなんだ

> (それでも内部でUnicodeだろうがShift-JISがデフォのようだけど）
根拠は？日本語以外の国があるのしらんの？ｗ
2020/07/02(木) 16:07:07.26ID:ACoXsYjy
Windows UTF-8 ベータ
知らないのはどっちかなとしか思えないw
2020/07/02(木) 16:13:26.48ID:ACoXsYjy
ああ、
システムエンコーディングがUTF-8対応になったのはつい最近、日本語だとそれ以前はシステムエンコーディングはShift-JIS
だよ。すまんなw
2020/07/02(木) 21:31:15.20ID:9cYvmHwP
アホだな。

それはUnicodeに対応してないアプリ用のエンコーディングに
UTF-8が使えるようになったのが最近なだけだろ

システムエンコーディングが9x用アプリのための設定のことだって知らないんだろうな
2020/07/02(木) 22:29:06.37ID:SkSFT8E6
OSでいくらutf8に対応しようが末尾AのAPI使ったアプリはsjisの入出力前提で書かれてるんだし
対応しようとすれば文字列周りは全部作り直しだよ
VBAやVBScriptとかのWSHも同じ問題を抱えてる
Windowsのutf8完全移行なんて10年後すら怪しい
2020/07/02(木) 23:58:17.21ID:9cYvmHwP
だからそれはアプリの問題じゃん

Windowsの標準コマンドはUnicode前提（対応）で書かれている。
PowerShell等から利用するUnicode前提
WSLもUnicode（透過的に変換されるUTF-8）

VBAやVBScriptとかのWSHも同じ問題を抱えてるというが
問題があるのはそれとバッチファイルぐらいでしょ。
今は殆ど使われてない
2020/07/03(金) 10:48:21.18ID:D1jLBB9V
今は殆ど使われてない[要出典]
573デフォルトの名無しさん
垢版 |
2020/07/03(金) 13:31:14.36ID:adDL+CTN
Windowsを使うな(暴論)
574デフォルトの名無しさん
垢版 |
2020/07/03(金) 22:08:43.15ID:pyXUrnYQ
エディタが対応した時点で932とか捨てたわ
変換する必要すらない(更新予定のない)古いメモ以外に残っていない
21世紀も20年目に入ってるというのにまだそんなの使ってる自体遅れいるのか
2020/07/03(金) 22:26:00.04ID:uIgOlo/V
俺がcp932を捨てたのいつだっけな？
Windowsになってからlzhを捨ててzipにした。
日本語が含まれる可能性がある個人用のファイル圧縮に
Unicodeを使う7zを使うようになったのは、うーん？2000年頃かなぁ

9x系に見切りをつけて（動かなければソフトの方を諦める）Windows 2000にした頃には
ファイルはどうしても無理な場合を除いてUTF-8を使うようにしていたし

cp932を使っていた時代は、LinuxもEUC-JPだったし大変だったね
LinuxでEUC-JPからUTF-8に変わった時には、WindowsもUTF-8を使うようにした
2020/07/03(金) 23:44:56.51ID:9C03Lp22
文字コードとしてのcp932と
システムロケールとしてのcp932をごっちゃにしてるやつが多すぎる

前者は単なる文字コードだから、個人レベルでどうにでもなる
長いことWindowsでutf-8を使ってると言う場合はこれに当たる

後者は現在のwin10でもバリバリの現役で、utf-8は1803から追加されたものの、未だベータ扱い
一部の古いソフトだと不具合がでるので、そう簡単な話ではない
たとえば、このレスを書くために開いているJane Style
2020/07/03(金) 23:59:49.05ID:uIgOlo/V
システムロケールはOSではなくてソフトの問題なんだよな
Windows自体はシステムロケールの設定に依存していない
なぜならすべてUnicode（UTF-16）で処理してるから
（もちろん互換性のための処理として一部例外はあるだろうが）
2020/07/04(土) 00:30:48.50ID:1qYUKBUR
ソフト側でロケールを理解できなかったらダメだからねぇ

そういえば、Linuxもutf-8への移行期（Fedora Core 1が最初だっけ？）に、
それまでのRed Hat 9で問題のなかったeuc-jp前提のソフトがダメダメだった
まぁシェルスクリプトは問題なかったはず
2020/07/04(土) 05:09:47.82ID:ve9MtcL4
Windowsの場合Unicodeで作ってれば
システムロケールなんて関係ないよ

システムロケールを理解する必要があるのは
Unicode（UTF-16）非対応アプリの話

システムロケールと使用する言語（表示する言語）は別だからね
2020/07/05(日) 00:52:27.71ID:m0wz7oid
メモ帳の保存形式にあるUnicodeとかいう多重トラップ嫌い
2020/07/13(月) 19:16:41.40ID:Xa4f7njE
Austinで大規模なファイル更新があって，
お，何か重要な局面を迎えたのかな？と期待して報告書を読んだら，
全文書に存在する"POSIX.1-201x"を"POSIX.1-202x"に書き換える作業だったていうオチ。
582デフォルトの名無しさん
垢版 |
2020/07/15(水) 10:35:51.78ID:GO+Zaox3
組み込み系のash環境です。

以下のコードは、外部テキストファイル(shift-jis)をwhileで1行ずつ読み込んで、
シリアルポートの/dev/ttyUSB0へ1行の内容をそのまま送信する処理の一部です。

ファイルの中に日本語の0x5cのバックスラッシュがあると、文字化けしてしまいます。
0x5c混在のサンプルとして「表示」の漢字が正常に送れるかの試験コードを作りました。

以下のスクリプトの文字コードはshiftJISで保存し実行しました。

text=ダメ文字表示テスト
filtered_text=`echo $text | sed -e 's/\\/\\\\/g'`

echo -e "ORG text $text"
echo -e "filtered_text $filtered_text"
echo -e "$filtered_text" > /dev/ttyUSB0

結果
sed: unmatched '/'
ORG text ダメ文字侮ｦテスト
filtered_text
やりたいこと
シェルスクリプト内の変数に格納して、/dev/ttyUSB0へ「ダメ文字表示テスト」とそのまま送信したいです。
1行ずつ送信する理由は、たまに行間で制御コードを混ぜる必要があるためです。

sedの行が肝になると思い、作例を1日探しましたが、探し方が下手で見つけられませんでした。
sed以外のコマンドでも使えるコマンドがあれば何でもいいです。

nkfは無しでした。iconvはありましたがShiftjisのコードが含まれていませんでした。
そもそも最終的に送信するデータがshiftjisなので、これらは関係ないと気づきました。

どのような書き方でできるか、お知恵をいただけないでしょうか。
2020/07/15(水) 11:54:50.30ID:IqfNcqeZ
ダメ文字は、数十年前の話w
2020/07/15(水) 12:02:36.35ID:gwK3CNky
>>582
> 以下のスクリプトの文字コードはshiftJISで保存し実行しました。

それは絶対ダメ
ASCIIと互換性がない文字コードには対応してないのが普通
2020/07/15(水) 12:03:29.33ID:gwK3CNky
>>582
> 以下のコードは、外部テキストファイル(shift-jis)をwhileで1行ずつ読み込んで、
同様に対応してないのが普通
2020/07/15(水) 12:04:14.63ID:gwK3CNky
いい加減文字コードはUTF-8に一括変換してから
処理して戻すってことを覚えたほうがいい
2020/07/15(水) 12:07:30.43ID:gwK3CNky
>>582
echoは使うなprintfを使え
2020/07/15(水) 12:09:01.51ID:gwK3CNky
> 1行ずつ送信する理由は、たまに行間で制御コードを混ぜる必要があるためです。
意味がわからん。制御コード1文字が二行に分かれたりでもするんか？
2020/07/15(水) 13:17:28.61ID:4eO2mC8f
>>582
とりあえずシングルクォートは要るんじゃないの？
text='ダメ文字表示テスト'
2020/07/17(金) 17:54:07.38ID:pKRyHByg
>>582
>sed: unmatched '/'
SJIS云々の前にsedのコマンドがちゃんと認識されてないじゃん。
とりあえず、バックスラッシュの数を変えたり``じゃなくて$()を使ってみたらどう?
2020/07/18(土) 06:32:49.36ID:belUdedc
ひょっとしてSJIS完全対応のテキストエディタってLinuxには存在しない？
昔mousepadで盛大に化けた覚えが
2020/07/18(土) 07:03:52.09ID:6UJBCs7F
Emacs
2020/07/18(土) 10:26:12.51ID:PyiwbgQS
Vim
2020/07/18(土) 10:38:54.42ID:W7WHirLG
vscode
2020/07/18(土) 11:38:05.10ID:PyiwbgQS
バカな投稿をすると釣られた人間が正しい知識を教えてくれるメソッド
よかったな，>>591！
2020/07/18(土) 11:44:04.46ID:fwbEJCvA
つまりvscodeが正しいと？
2020/07/18(土) 12:39:31.97ID:PyiwbgQS
俺のスレ読んでないの？w
2020/07/18(土) 13:28:14.79ID:fwbEJCvA
お前のレス？釣られた人間が正しい知識を教えてくれるんでしょう？
それ以外になんかあるの？
2020/07/18(土) 13:48:08.58ID:W7WHirLG
エディタも使いこなせないならwinのメモ帳でも使いなよ。sjis対応だよ
2020/07/19(日) 08:53:42.63ID:b8gde26L
お前いつも壁と話してんな
2020/07/19(日) 10:23:03.44ID:HNDAT4gV
壁だと思ってるのはお前だけで、実は人間なんだぜ（ホラー風）
2020/07/19(日) 11:15:59.84ID:W3hSYpRn
ぬりかべ「かべっ！？」
2020/07/27(月) 19:01:06.79ID:prTniRCc
manコマンドはPOSIXに取り入れられそうなのに
その表示に関わるroffコマンドは影も形もないって、
なんつーか意味あんのかそれって思う。
2020/07/27(月) 20:34:03.79ID:Sw4i8xv6
>>603
roff 使わなくても cat1 とか cat8 に成形済みテキスト置いておくだけで man
は動くんだから、別に roff なくても良いといえばいいとか、そんな理屈なのかも。
2020/07/27(月) 20:48:14.37ID:9y96d1KX
manをPOSIXに取り入れるぐらいなら
HTMLビューワーをPOSIXに取り入れたほうが良い
JavaScriptとCSSに対応させる必要はないからさ
2020/07/27(月) 20:50:03.70ID:9y96d1KX
curlをPOSIXに入れればいいのに
フル機能じゃなくていいけどREST API叩けるぐらい
2020/07/27(月) 21:12:03.12ID:vTLRE8Va
>>603
おお、するどい。
でもmanが入ってないというのはどう言う意味? POSIXとSUSの意味の違いにこだわる?

で実際manの記述を見ると文章の整形とかそれをどう作るとかは書いてないので、
そういうレベルのものは規定しないという態度なのかも。

あと事実上GNU roffが標準だと思うが、さすがにそれを規格には入れられないのかも。
かといって今更大昔のroffに制限するのもなあと。

しかし最近GNUで検索するとKingの方がヒットしやすくてうざいw
2020/07/27(月) 21:16:04.45ID:vTLRE8Va
というか、King Gnuと言ったらRMSしかありえないだろw
2020/07/28(火) 08:42:48.22ID:UlETHBDV
こんなのか?
https://www.e-hon.ne.jp/bec/SA/Detail?refShinCode=0100000000000030681001&;Action_id=121&Sza_id=F3

まだ役に立ってるよ。俺が持ってるのは 20.3 だけど。
2020/07/28(火) 13:13:59.11ID:R16GmJU5
質問。
次のような行からいずれかのvalueをきれいに削除するにはどうすれば？
name=value0,value1,value2,value3

たとえば次のコマンドだと、value1を削除できるものの、先頭か末尾か連続かのカンマが残ってしまう。。。
sed 's/^(name=.*)value1(.*)$/¥1¥2/'

残ったカンマを後で処理したらいいんだけど、そもそも一発でうまくやることができるんでは？という気がどうしても。
2020/07/28(火) 13:23:54.46ID:Mb4DOiRz
^(name=.*)�bvalue1,?(.*)$
こうかな
2020/07/28(火) 13:24:17.04ID:Mb4DOiRz
文字化けてるとこは円記号な
613デフォルトの名無しさん
垢版 |
2020/07/28(火) 13:53:56.25ID:DVrEteyf
King Gnu?
どっかで聞いたことあるようなないような▪▪▪
2020/07/28(火) 14:07:36.32ID:R16GmJU5
>>611
value3の場合、末尾にカンマが残るよね？
また、value0なら先頭に残る。

どれでも一発できれいに削除できないかな？
2020/07/28(火) 14:08:46.03ID:3p32kQjL
残らないが？
2020/07/28(火) 14:25:35.27ID:R16GmJU5
残るが。
value3直前のカンマが¥1に含まれるので。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況