X

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2019/10/25(金) 00:08:45.53ID:6btPTvif
シェルスクリプトに関する総合スレッドです。

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

シェルスクリプト総合 その31
https://mevius.5ch.net/test/read.cgi/tech/1565446670/
0520デフォルトの名無しさん
垢版 |
2020/02/01(土) 20:57:55.39ID:rbhAio8f
なんか説明しようとしたんだがな
ダブルクォートが入っていても関係ないよ。なぜかは調べてね
0521デフォルトの名無しさん
垢版 |
2020/02/01(土) 20:59:45.01ID:rbhAio8f
>>518
悪い文化というより、POSIXで規定しろというだけかな
悪い文化のががっつりカーネルで実装されてるんだけど
0522デフォルトの名無しさん
垢版 |
2020/02/01(土) 21:13:13.94ID:izL/3CDz
>>521
単なる表現だから気にしないでほしいけど
悪い←実装ごとに挙動がバラバラ・標準仕様が規定を諦めている
文化←にもかかわらずほとんどの実装がこれを取り入れていて、利用者もしょうがなく使っている
という状況を言ったつもりだった。
0523デフォルトの名無しさん
垢版 |
2020/02/01(土) 21:19:14.91ID:rbhAio8f
>>522
なるほど
まあ、誰も(大多数が)困ってないんじゃなのかな、統一されてなくても
もしくはそれぞれがそれぞれが良いと思って譲らないとかかwそれは確かに悪い文化だな
誰も困ってないって方だと思うけど
0524デフォルトの名無しさん
垢版 |
2020/02/01(土) 21:48:34.75ID:7bhnkH1k
shebangが悪い所の一つは絶対パス指定ってところなんだよね
content-typeみたいなのだったら良かったのに

shebangのオプションに関しては使わないっていうのが正解なんだと思う
なぜならファイルを直接指定して実行すると変わっちゃうから
0525デフォルトの名無しさん
垢版 |
2020/02/02(日) 14:26:51.03ID:xQhhTPSe
てかshebang使わなくてもシェルから起動したらそのまま動かない？

と思って、念の為Bashから起動したらまさかのaliasが効かなかった……。

こういうのを避ける為に#!/bin/shとせざる得ないのか。残念。
0526デフォルトの名無しさん
垢版 |
2020/02/02(日) 16:53:40.51ID:XLs1Cb+c
>>524
絶対パスかどうかは、シェルというか、インタープリタに依存するんじゃないの？
Pythonなんかだと、パスさえ通っていれば、#!python とか #!python3 で使い分けできるし。
0527デフォルトの名無しさん
垢版 |
2020/02/02(日) 17:45:00.84ID:Cva1xhgA
>>526
(少なくとも現在は)shebangを解釈しているのはOSであって、絶対パス必須
#!pythonと書いたスクリプトをexecveした場合、普通は動かない
0529デフォルトの名無しさん
垢版 |
2020/02/03(月) 08:04:03.85ID:24GdBe+7
envがあるところは/usr/bin/envな

あとそれ使うと

#!/usr/bin/env bash -e

とかできなくなるからな
Linuxで
0531デフォルトの名無しさん
垢版 |
2020/02/03(月) 10:00:30.45ID:24GdBe+7
>>530
envってコマンドを使うと、環境の違いを吸収してくれるから便利だぞ
0532デフォルトの名無しさん
垢版 |
2020/02/03(月) 11:22:27.68ID:8ufJ91gq
>envがあるところは/usr/bin/env
に対しての
/bin/envにある環境もあるって話だろ。「それってなに？」だろ言うなら
0539デフォルトの名無しさん
垢版 |
2020/02/03(月) 12:09:00.93ID:sGoeeXwW
なんかこの前々スレあたりで標準出力と標準エラー出力に別々の処理を施した上で
どちらも標準出力に流す方法を見た覚えがあるんだけど
今それっぽい語句で検索しても引っ掛からない。

覚えてる人いない？
0541417
垢版 |
2020/02/04(火) 21:40:22.30ID:M0ahQJ78
>>446
ありがとうございます。
コードを参考にさせていただいて、
sed -e 's/\("[^"]*"\)*,\("[^"]*"\)*/\1 \2/g'
という手法にしました。

今のところ
<<. cat |
aa,"dd,dd","aa,bb",cc,"ab c"
.
sed -e 's/\("[^"]*"\)*,\("[^"]*"\)*/\1 \2/g'
がうまいこといくので満足してます。
どうもお手数おかけしました。
0545デフォルトの名無しさん
垢版 |
2020/02/05(水) 07:03:40.14ID:TkSDhbEE
(unofficial) Bash Strict Modeって知ってる？
http://redsymbol.net/articles/unofficial-bash-strict-mode/

これが何って話があるわけじゃないんだけど有名なのかな？と思って
外国だとそれなりに情報出てくるけど日本はあまり見つからない

名前が知られてないだけでsetで-eu -o pipefailしましょうというのは聞くけどね
ただIFS=$'\n\t'は知らなかったな。これやったほうがいいんかな？
スペースが削られてるから問題起きそうだけど
0546デフォルトの名無しさん
垢版 |
2020/02/05(水) 08:00:23.89ID:ER23be8Q
>>545
IFS=$'\n\t'
↑これはどういう事態を防げるの？
寧ろ
for file in *; do
echo $file
done
こういうのが動かんくなる気がするけど。
0550デフォルトの名無しさん
垢版 |
2020/02/07(金) 22:46:56.58ID:LLO+pCZY
なるほど。文芸的プログラミングという
ドキュメントを書くときにコードを埋め込んで
（動作確認のために？）実行できるようにするための
マークアップ言語みたいなものがあるんだな
コードの中にコメントを埋め込むのとは逆の発想か
0551デフォルトの名無しさん
垢版 |
2020/02/07(金) 22:58:24.38ID:YkBBCjCg
bashのsourceって英語としては意味なんだろう？
includeとかimportだったら読み込むってわかるけど、
なんでsourceって単語にしたんだろうか
0552デフォルトの名無しさん
垢版 |
2020/02/08(土) 00:06:22.51ID:Ld8bPHII
なんのことかと思ったらMarkdown文書をソースとするshellがありますぞというだけかという感じ
0554デフォルトの名無しさん
垢版 |
2020/02/08(土) 12:05:42.11ID:vyHTTWz1
>>551
元々は設定ファイルを読み込む

$ source .bashrc

あたりで使っていたようなので、「基にする」あたりが
英語の意味かと思う
0556デフォルトの名無しさん
垢版 |
2020/02/08(土) 14:51:42.04ID:0wE1WgKD
importは他のファイル等で定義済みの関数やクラスを今の名前空間に持ってくるイメージ
sourceは他のファイルに書いてるコードを実行するイメージ
言語によってはやってること同じだったりするけど主たる目的が違う気がする
0558デフォルトの名無しさん
垢版 |
2020/02/08(土) 15:41:05.52ID:WgESEu8I
> sourceは他のファイルに書いてるコードを実行するイメージ
動作としてはそうなんだけど、
気になってるのは英単語としてどうかなんだよね
変なことを気にしてると思うけど

そもそもsourceって動詞？ああ、動詞としての意味もあるのか？
https://talking-english.net/source/
> sourceは動詞でも使い方があり「仕入れる」といった意味になりますが、
>
> 例文
> We source our coffee beans from Venezuela.
> 私たちはコーヒー豆をベネズエラから仕入れている。
0559デフォルトの名無しさん
垢版 |
2020/02/08(土) 22:01:26.95ID:EnngxFza
importに名前空間を移動する印象があるのは同意だけど
sourceの「他のファイルに書いてるコードを実行する」ような印象はないな。
つーかsourceってシェル以外でみかけない。
名前空間とか高級な概念を無視する、単なる対象ファイルの実行・読み込みは
includeが一番「それっぽい」な。
C言語みたいなコンパイル方式でもm4・Xresourceみたいなインタプリタ・設定ファイル形式でも。
0560デフォルトの名無しさん
垢版 |
2020/02/08(土) 23:17:01.30ID:WgESEu8I
sourceの本来の名前が . だとして、
/etc/profileとかに . /etc/bash.bashrc とか書いてあるでしょ？

これは関数定義等を読み込んでると言うより、
ただそこにあるスクリプトを実行してるという感じがしない？
0562デフォルトの名無しさん
垢版 |
2020/02/09(日) 07:56:47.77ID:u8D56ofC
>>560
ああ、いや、たしかにそうなんだけど、
sourceっていう名前の（または.（ドット）って名前の）コマンドや指令が
シェルスクリプト以外で見掛けないなと思ってさ。
じゃあシェルスクリプト以外の言語でsourceに最も近いはたらきをするのは
なにかって言えば、includeかなぁ。と。
0563デフォルトの名無しさん
垢版 |
2020/02/09(日) 08:09:38.60ID:WtBEbY+3
includeで言えばC言語かなぁ
でもC言語のincludeはヘッダファイルの読み込みで
（今のC++はそうとは言えないが）
実行するものはなにもないものだったよね

.やsourceを他の言語で見たことがないのは同意
なんでこの単語を選んだのか。まあ当時はそういうことをするときの
標準的な単語はなく、includeやimportの方がたまたま有名になったってだけな気もするけど

includeってC/C++以外あったっけ？
0565デフォルトの名無しさん
垢版 |
2020/02/09(日) 08:15:45.81ID:WtBEbY+3
とういうか、その話をするためにきたんじゃなかったｗ

makeってどういう亜種があるの？
それぞれのOSでどこまで互換性があるの？
どこかにそういう情報まとまってないかな
0568デフォルトの名無しさん
垢版 |
2020/02/09(日) 08:40:31.63ID:WtBEbY+3
Makeについて調べていたら上のシバンの話、!の後にスペース入れれっていうのが見つかったでｗ

https://web.sfc.wide.ad.jp/~sagawa/gnujdoc/autoconf-2.59/autoconf-ja_10.html
> また，以 下のように，インタプリタ仕様として，感嘆符の後にスペースを含めてください．
>
> #! /usr/bin/perl
0569デフォルトの名無しさん
垢版 |
2020/02/09(日) 08:41:08.32ID:WtBEbY+3
ここまでコピペするべきだった

> パスの前のスペースを省略する場合，(DYNIXのような)4.2BSDを基本 とするシステムは，
> `#! /'は4バイトのマジックナンバーとして解釈される ので，その行を無視します．
> 古いシステムでは，`#!'行の長さにも小さな 制限があり，例えばSunOS 4では，(改行を含めず)32バイトになります．
0571デフォルトの名無しさん
垢版 |
2020/02/09(日) 10:20:28.40ID:gml78nRc
>>569
それ間違っている
https://www.in-ulm.de/~mascheck/various/shebang/#blankrequired

>You may also read, that (allegedly) such a kernel parses "#! /" as a 32-bit (long) magic.
>4.2BSD in fact doesn't require it, although previous versions of the GNU autoconf tutorial wrongly claimed this ("10. Portable Shell Programming", corrected with release 2.64, 2009-07-26).
>But instead, see 4.2BSD, /usr/src/sys/sys/kern_exec.c (the first regular occurence). A blank is accepted but not required.
0572デフォルトの名無しさん
垢版 |
2020/02/09(日) 12:28:36.33ID:mw6BsSoR
pgrepには検索文字数の制限があるのか？
0575デフォルトの名無しさん
垢版 |
2020/02/09(日) 14:04:29.38ID:Fnglc4p2
>>563
あなたはC言語がUNIXを作るために作られた言語だと知らないの？
0576デフォルトの名無しさん
垢版 |
2020/02/09(日) 14:07:08.39ID:Fnglc4p2
>>569
そもそもどのUNIX、Linuxの話をしているのか？
0578デフォルトの名無しさん
垢版 |
2020/02/09(日) 14:57:41.05ID:RDxzsaY4
shellはUNIX上でのいちプログラム、UNIXはCで作られてる。shellだってCで(途中から？)作られていただろう。故に、
>当時はそういうことをするときの標準的な単語はなく、includeやimportの方がたまたま有名になった
ということはなく、同じならinclude使うんじゃねってとこかな？なんか違うから違うのにしたという方が読みやすいかなあ

shell scriptはPrologの構文が元じゃなかったっけ。ちょっとググったとこでは、
:-
か。なんかこれに似てるといえば似てるな . は
0579デフォルトの名無しさん
垢版 |
2020/02/09(日) 15:11:26.44ID:Fnglc4p2
>>577
先に存在しているC言語とは別の考えで設計されている。カリフォルニア大学のバークレー校の複数人が考えたものだから、統一感がないのは仕方ない。
0580デフォルトの名無しさん
垢版 |
2020/02/09(日) 15:48:09.09ID:mPwdKOvO
>>572
linuxならlinux自体にプロセス名の長さ制限(16文字)があるからそうなる
コマンドライン自体はlinuxも十分長い文字列を扱えるから、-fを使えばよい
0581デフォルトの名無しさん
垢版 |
2020/02/09(日) 16:48:41.40ID:RDxzsaY4
>>578
>shell scriptはPrologの構文が元じゃなかったっけ
違った。ALGOLだな。ALGOLでそれっぽいのはUSINGみたいだが、ちょっと違うなあ
0582デフォルトの名無しさん
垢版 |
2020/02/09(日) 16:50:22.96ID:u8D56ofC
for a in XXX; do
somecmd...
done
↑ここのXXXの大きさについて、SUSやらで文書化された制限ってある？
もしあるとすればどう調べればいいかな。

XXXは引数じゃないからARG_MAXとかじゃないし、
もしかしたら実質無制限？（システムのメモリに依存とか？）
0583デフォルトの名無しさん
垢版 |
2020/02/09(日) 19:33:12.64ID:wmQivLfL
ksh 2020がでたのは知ってるけどkshに一体何が起きてるんです？
20年以上の開発がゴミクズとして消えるんですか？

Rewinding this repo and encouraging community
https://github.com/att/ast/issues/1466
0584デフォルトの名無しさん
垢版 |
2020/02/10(月) 00:06:22.74ID:jvWR6fCp
https://github.com/att/ast/tree/ksh2020

This branch is not supported
This branch contains the ksh2020 version of the AST tools, from January 2020,
which primarily written and maintained by @krader1961 and @siteshwar.

This branch is not supported or maintained by AT&T; the repo at
https://github.com/att/ast only officially hosts ksh93u+ and the experimental ksh93v- branch.

See #1464 and #1466 for discussion and history of this decision.

Please search for forks of this repo if you are looking for ksh2020.
0585デフォルトの名無しさん
垢版 |
2020/02/10(月) 00:08:02.47ID:jvWR6fCp
https://github.com/att/ast/issues/1466

私はAT＆T Labs Research で@lkoutsofiosと協力し、コミュニティが
快適な状態にレポを復元できるかどうかを確認するためにボランティアで参加しました。これは最後に＃1464で議論されました。

私はkshや技術的な問題の専門家ではなく、歴史全体を知りませんが、私の理解は

1. ksh93u +は、AT＆Tからの最終的な公式リリースです。これはブランチ2012-08-01-masterにあります

2. 後のバージョンであるksh93v-は、AT＆Tを離れた後に元の作者によって提供されましたが、
このバージョンは安定しているとは見なされません。これはタグksh93vで見つけることができます

3. @ krader1961はmasterブランチを数年間維持しています。彼はコードベースを合理化しようとしました
（そしてastの残りではなくkshのみをサポートしました）が、これは互換性の問題を引き起こしました。
kshの元の作者はすべてAT＆Tを去りました。社内にはまだ多くのユーザーがいますが、
プロジェクトを維持および管理できるユーザーはいません。
0586デフォルトの名無しさん
垢版 |
2020/02/10(月) 00:11:44.63ID:jvWR6fCp
私の提案は：

・ 現在のマスターをブランチ「ksh2020」（または適切なもの）に移動します。
・そのブランチのREADME.mdおよびCHANGELOG.mdをメンテナンスされていないものとして
明確にマークします。＃1464をポイントし、詳細についてはこの問題を参照してください。
・ マスターブランチを2012-08-01-masterにリセットします
・リポジトリから外部の共同編集者を削除します。AT＆Tの誰もこれを維持していないので、
このフォークをアクティブなものにすることは意味がありません。GitとGithubを使用すると、
誰でも自分のスペースで好きな方向にコードを取得できます。
0587デフォルトの名無しさん
垢版 |
2020/02/10(月) 00:12:00.37ID:jvWR6fCp
・ README.mdをクリーンアップして、現在の状態を反映します。「このレポには、ASTの
AT＆T ksh93u +および試験的なksh93v-バージョンが含まれます。ASTおよびkshのフォークは
後である可能性があります。」
・ CONTRIBUTING.mdを変更し、テンプレートを明確にして、このフォークを
積極的に維持しておらず、何も確認しないことを約束します。
・リポジトリの説明を「AST-AT＆T Software Technology」に短縮します（＃1441）

これが完了したら、AT＆Tでmasterブランチのksh93u +にパッチを提供する可能性があります。
些細なこと（ビルドの問題など）でない限り、貢献を確認したり受け入れたりすることはおそらくないでしょう。
最終的には、このリポジトリをアーカイブします。

現在、会社の誰もがkshのためだけにレポを作成するつもりはないと思います。
しかし、これはかなり簡単で、コミュニティが取り上げることができると思います。
0588デフォルトの名無しさん
垢版 |
2020/02/10(月) 00:27:01.24ID:jvWR6fCp
こういうこと？

1. AST-AT＆T Software Technologyはkshだけのプロジェクトではない。kshはASTプロジェクトの一部
2. 誰かがkshだけをメンテナンスしていた。ASTプロジェクト全体をメンテナンスしてる人はいない
3. 今リリースされてるksh 2020はそれ
4. ksh 2020 は後方互換性がなく古いスクリプトが動かなくなっていた
5. それは困るのでmasterを2012-08-01-masterにリセットしてアーカイブする
6. AT&Tはこのリポジトリをメンテナンスしない。 誰か開発したいのなら、ksh2020ブランチから続きをやれ
7. ksh2020ブランチにはもうメンテナンスしてないって書いてあるからそれ消してから勝手に続きをやれ
0589デフォルトの名無しさん
垢版 |
2020/02/10(月) 08:02:14.12ID:RPv+4ALj
Google翻訳使うなとは言わないけど，わざわざそれをスレに載せるな。
せめて自分で訳したものならともかく，なんの情報でもない。
0590デフォルトの名無しさん
垢版 |
2020/02/10(月) 08:09:49.99ID:jvWR6fCp
え？翻訳すらしないでコピペすることだってあるじゃん
そういうのを引用っていうんだよ。
引用したらだめってこと？意味がわからないなぁ
0591デフォルトの名無しさん
垢版 |
2020/02/10(月) 11:18:22.31ID:RPv+4ALj
>>590
飛躍しすぎ。
スレと関係ないただの忠告になるからこれ以上言わんが、
引用するななんて一言も言ってないし，ただの引用のほうがよほどマシ。
ていうかGoogle翻訳したものを貼り付けて「引用」って……

あなたはGoogle翻訳（機械翻訳全般）を信じてるのかも知れないけれども，
2020年現在，これらの翻訳の質は，あなたが貼り付けた文章を見ても分かる通り，酷いもの。
半分「嘘っぱち」の文章が出てると言っても過言じゃない。
特に，機械翻訳の中でも，minhonやlibtr8nとは違って，Google翻訳は2018年ころから
「学習した英語・日本語訳文からそれっぽい文字の並びを引っ張ってくる」っていう手法を取るようになったから
「見てくれは他の機械翻訳より〝自然〟だけど内容が全くデタラメ」っていう最悪の事態を生み出すようになってしまった。
幸か不幸か，あなたが貼り付けた文章にそこまで酷い誤謬はないけど，上述の翻訳手法である以上，
Google翻訳した文書を貼り付けるのは，原文を貼り付けるより酷いばかりか，
何も情報を提供せずに各自がリンク先なんかで情報を確認するよう要求するほうがよほどマシなくらい。

あなたは悪気なくGoogle翻訳を使って，スレに貢献しようとしたのかもしれない。
リンク先の文書の内重要と思われる部分をスレ本体に引用することは悪いことじゃないけれど，
そこでGoogle翻訳を使ってしまうのは，ちょっとキツい言い方になるけど「嘘を教える」ことに繋がってきてしまう。

もしこれからリンク先の文章を引用する機会があれば，原文を貼り付けるか，下手でもいいから自分で翻訳してみてね。
0592デフォルトの名無しさん
垢版 |
2020/02/10(月) 11:56:29.56ID:jvWR6fCp
>>591
はは、的外れすぎてワロタw
英語をそのまま貼ってもリンク先読まない人が多いから
単に変換しただけ。英語というだけでスルーする
日本語ならぱっと見でわかる。内容が気になったのならリンク先読みなさい。
読んだのなら貼り付けた意味があったということ
0594デフォルトの名無しさん
垢版 |
2020/02/10(月) 19:51:47.28ID:RPv+4ALj
>>593
もう放っておこうぜ。

俺なりにかなり丁寧に説明したんだけど，
どうも何について文句を言われてるかすら分かっていないようだから。
0597デフォルトの名無しさん
垢版 |
2020/02/12(水) 17:16:49.73ID:SPYER+lN
コマンドの速度を測りたいときに出力を/dev/nullに捨てるとその影響で
出力を捨てないときより速く計測されてしまうことがあるんだけど
例:
$ time { < /usr/bin/od od -A nx -t x1 -v; }
...
出力略
...
real 0m0.055s
user 0m0.042s
sys 0m0.008s
$
$ time { < /usr/bin/od od -A nx -t x1 -v > /dev/null; }

real 0m0.020s
user 0m0.020s
sys 0m0.000s

これを防ぐために「端末上に書き出してるのと同じくらいの負荷が書かるけど、実際には端末上に出力されない」
みたいな状況を作りたい。
おしえてください。
0598デフォルトの名無しさん
垢版 |
2020/02/12(水) 17:58:00.53ID:44kLfG7j
pv 使うとか

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time { < /usr/bin/od od -A nx -t x1 -v; }
:

real 0m0.404s
user 0m0.024s
sys 0m0.005s

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time { < /usr/bin/od od -A nx -t x1 -v | pv -q -L2M > /dev/null; }
real 0m0.458s
user 0m0.019s
sys 0m0.007s
0599デフォルトの名無しさん
垢版 |
2020/02/12(水) 21:18:18.55ID:ngmZ90wk
>>597
画面に出力されてる時間のせいだから無理じゃね？
/dev/ttyにだせば端末上に出力されてるけど標準出力に影響はない
あとは出した上でエスケープシーケンスで消すとか
0600597
垢版 |
2020/02/13(木) 19:02:20.33ID:qpgEIAWv
>>598
うーん。ちょっと偉そうな注文だけど
システム全体の設定を変更したり、
かつroot権限が必要なのはちょっと…

>>599
エスケープシーケンスは思い付かなかった。
でも出力の中に一つでも文字属性を元に戻すようなものが
含まれたりするとマズいよね（いやまあ，それに目を瞑ればいいだけの話なんだけど）…

どうも一般的な方法では無理そうなので，
ダラダラ出力させることにします。
困ることといえば端末のスクロール履歴が消えるくらいだし。
0601デフォルトの名無しさん
垢版 |
2020/02/13(木) 19:45:08.54ID:d+A9Zjku
標準出力バッファを無効にして/dev/nullに送り込むと良いかも。知らんけど
0602デフォルトの名無しさん
垢版 |
2020/02/15(土) 07:57:33.28ID:TqNhf8oX
ていうかtimeで測った絶対速度なんてほとんど信用できなくて、（ハードウェアの状態なんかに依存するから）
使い道としては複数のコマンドどうしの相対速度の比較が主でしょう。
ならば、両方とも> /dev/nullに捨てておけば、相対速度としては変化しないから速度比較の目的は果たせるのでは。
0603デフォルトの名無しさん
垢版 |
2020/02/15(土) 09:41:54.81ID:LBGCL7FY
リダイレクトとfdは概ね理解したけど3以上はどう使えばいいんです？
1>や2>は自然と使い分けてるけど1>&3を使う機会なくて
&>の方がまだ出番ある
0604デフォルトの名無しさん
垢版 |
2020/02/15(土) 11:02:57.91ID:vIJrSTGq
>>603
スクリプト開始時の stdout や stderr を保存しておくのに使うぐらいかなあ
# stdout を fd=3 にコピー
exec 3>&1

# fd=1,2 を foo.log にリダイレクト
exec > foo.log 2>&1

echo "foo.log に途中経過出力中です..." >&3
...
echo "処理B開始" >&3
...
echo "終了しました" >&3
0605デフォルトの名無しさん
垢版 |
2020/02/15(土) 13:14:38.75ID:QAGa8Flq
bashの問題なのか知らんけど、
CRとかLFとかTABとかVTとかをどう解釈するかって
制御するフラグってあったりする？OSがらみの設定でもいいけど
0607デフォルトの名無しさん
垢版 |
2020/02/15(土) 17:24:25.12ID:LBGCL7FY
>>604
foo.logには標準出力とエラーが両方保存される
>&3がある行だけが画面に出力される
よく出来てますわ
ログ取りに使えるのか
0608デフォルトの名無しさん
垢版 |
2020/02/15(土) 22:02:17.95ID:7TGox9oB
>>606
sttyコマンドなのかな？

詳細は言えないけど、"予め構築された特定の環境"のみおかしくなる
（どうやって構築されたかは公開されてない）
それと近いと思われる環境を自分で作っても再現できなくて困っている。

evalやコマンド置換と改行やタブ含めたホワイトスペースに属する文字を
使ったときにおかしくなってるのはわかるんだが
どうやったらこんな状況を作れるんだろうか。なぞだ。
0609デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:22:52.25ID:FhP/kA+H
頭悪い奴ってのは、おかしくなったとかエラーになったとかいうだけで、
どうなったのかメッセージはなんなのか、そこを書かないのは何でだぜ
おかしいのはシステムじゃなくておまえの頭だろうという
0610デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:28:09.90ID:7TGox9oB
evalするときに何故か構文エラーが起きたり
ホワイトスペースがどこかで消えたりしている。
0611デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:28:21.51ID:2teiXV5j
>詳細は言えないけど
なんだろ。単なるチラ裏なことを長々とというだけの
対処する側なのにその前置きでエスパー求めるなんてありえないし
0612デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:28:41.71ID:7TGox9oB
もちろんその環境以外ではそんな事は起きていない。
だから制御する方法があるのだろうと思ってるがわからない。
0613デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:31:04.26ID:2teiXV5j
>>610
何かを求めたいなら具体的に書こうな。Terminalでのまんまとか
そのままじゃ何か問題があるなら、似たようなのに加工できるだろう
0616デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:33:17.78ID:7TGox9oB
短くしたら、お前が俺にレスさせるようにしただけ。
最初に詳細は言えないって書いてるんだから察しろ
0617デフォルトの名無しさん
垢版 |
2020/02/15(土) 23:36:08.92ID:2teiXV5j
そうちゃんと読みとって>>611と書いているんだが。すでに
何かをまだ期待してちょっとだけな>>610をとか続けるようだからなんだがな
これ以上もうないだろけど
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況