なぜｼｪﾙｽｸﾘﾌﾟﾄ言語で大規模ｱﾌﾟﾘが作れないのか？

シェルスクリプト言語が強力であれば、
大規模アプリが作れるはず。

逆に、大規模アプリが効率良く作れる言語なら
シェルスクリプト言語として使うっても
効率がいいはず。

GUI？CUI？
小規模アプリでもやってみればわかるけどGUIは無理
TUIも無理かも
CUIだとできそうだけどシェルスクリプトじゃできること限られるし
シェルスクリプトに限らずpythonとかのスクリプトも有りなら可能性は広がる

ただ大規模なプログラムになるとスクリプト言語は実行速度で不利

#↓削除依頼出してねって書き込まれるに1ペリカ

ユニケージは？

>>3 で終了

シェルスクリプトだけだと、どうしても外部コマンドに頼る場面が
でてくるから、そこでのfork&execのコストがどうしても高くつく。

保守性が糞悪い
vbスクリプト技術者なら安い賃金で調達可能

もうメインフレームのバッチ処理みたいな仕事は無いよ

シェルスクリプトは日常語だから。

>>6
実データがテキストファイルで目に見える形で保存される、これが客に与える安心感は大きい。そしてそこから発生する手回しの良さに気付かないとは…お前もお偉いさんになっちまつたんだなぁ

で、ほかの開発環境に比べて良いところは？データがテキストってだけ？

#!/usr/bin/env ruby

データもシステムも設計が細切れになる。パイプを駆使してプチプチと。
それは非オブジェクト的で、構造とデータとプログラムの境目がなくなっていく。いかにも今風な流れだと思うけどねえ

何を今更なスレだな。
ユニケージ開発のuspに喧嘩売ってんの?

ユニケージ開発について調べてみた？
あれ、怪しげな開発手法じゃないか。

シェルスクリプトはほんの少ししか関係ない。
スクリプトキディ＋金儲けが始めたビジネス。

よくわからん開発手法を掲げて
後はセミナーで金をとる商売。

基本的に >>1 が何をさして「大規模アプリ」とか「強力である」とか言ってるかよく分らん。
「シェルスクリプト言語として使う」ってコマンドライン操作のことかな。

まぁ釣なんだろうけど。

>>1
聞いて聞きっぱなし?

dtkshのスレか？

>>13
このスレ的には>>3で終了だし、
ユニケージ開発っていうのは元々のUNIXの利用者的な思考そのものって
いうこともあって自然だから別に怪しいわけでもないと思うが、

ユニケージ開発の肝の一つである
「独自コマンドをLinux, UNIX等に展開しないのはなぜ？」

って思うね。
UNIX文化、Linux文化とは完全に相容れない異質な思想がそこにはある。

故に、毛並みは違うけども他の有償アプリケーション等とあまり変わらないイメージがあるな。
ユニケージ開発が言っている事はこういう事だ。
「数は少ないが、作り出すのは面倒な独自コマンドをUNIX互換環境で作り出せば、
　独自コマンドと既存コマンドの組み合わせで大規模アプリ相当の機能が簡単に作り出せる。」

ただし上記の前提条件は、USP研究所（笑）に金払って決めなきゃダメ。
しかも、（分岐を防ぐため）独自コマンドの導入はUSP研究所が検証したものでないとダメｗｗｗ

コマンドの仕様を公開していないから、色々（主張している事と）矛盾が出てるんだよね。
そこが「怪しい」と思われるポイントになっている気がするよ。

GNUのようにオープンにソースを公開して、古くから大勢の人に検証されてきたコマンドと違って
バグが有る可能性は否めないし、オープンな議論があったわけでもないので
必要なコマンドのチョイスも結構怪しい。と思われる事自体に問題がある。
また、独自コマンドを作る事が出来ない環境では全く役に立たない方法論で、
いくらUNIX, Linuxが広く使われていても、適用範囲はすごく狭い。

色々ダメダメだな。

あ、でも

頼むから続き書いてくれ
おもんなくてもいいしなんなら金払ってもいい

ユニケージ開発が怪しいのは
英語版Wikipediaに存在しないから。

ゴミはゴミ。

んじゃページ作れば怪しくなくなるのか?

GPLでなくたって、BSD/MITライセンスでええやん。

>>21
俺が悪かった。
ページがあってそれが複数の人で定期的に
メンテナンスがされてないとだめだな。訂正する。

叶姉妹って怪しいけど
Wikipedia 英語ページがあって定常的に複数の人にメンテされてるよ。

だいぶワロタ

>>24
つまり、ユニケージ開発は
叶姉妹よりも怪しいってことだなｗ

長年、嫌がらせをされています。
工作員　エージェント　影の政府　超常罠　イルミナティ悪魔の13血流　で検索。

オープンソースなユニケージ互換コマンドとか無いの？
USPが配布している機能限定無料版じゃなくて、全く別開発者の
オープンソース版

ユニケージスレになっとる。

もっと盛り上がればオープンソース版もあり得るかもね
とりあえず今のライバルは叶姉妹

ぶっちゃけ、湯にケージ（GoogleIMEで候補に出ない）
なんてものは、ほぼ全員このスレをみて知っただろ？

>>31
当たり前でしょ
マイナーすぎて

>>31
Software Design読んでるから
名前だけなら知ってたわ。

コミケでUSP発行の薄い本買ってみた事はある。

ユニケージの真髄は、シェルスクリプトで書く事じゃなくて「既にある使ってない物も」で書く事
ラッピングと言う名の再発明を無駄に繰り返して一歩も前に進まないシステム業界よりよっぽど良い

って言うか、元々UNIXってそういう思想・哲学で作られてるんだろ。
わざわざWindowsやMacの糞アプリの真似して、巨大な何でも入りアプリを作るのは馬鹿。

Linuxカーネルがなんでも入りカーネルなんだけどなｗ

configで要らないのは外せるじゃん。


依存関係ややこしくて死ねるけどw

>>28
Open usp Tukubaiが公開されてるじゃん
https://github.com/usp-engineers-community/Open-usp-Tukubai/

細かいコマンドはCで書いて
あとはシェルスクリプトで・・・・って普通だな

「UNIX シェルスクリプト・コマンドブック 第2版」 山下哲典、2012
この本は良書です。この本によると、

1行ずつのループ処理で、5千行までなら、whileを使う
(forは遅いので、なるべくなら使わない)
2万行以上なら、sed、awk、perl、を使う

10万行のループ処理にかかる時間は、whileは5秒、forは9分
それらを、awkとperlに書き直せば、0.1秒と載っています

使うシェルにもよるんじゃないの?
まさかスクリプトにbash使ってる馬鹿は居ないよな?

ところが結構見るんだよな。
配列とか独自機能を使うためにbash指定してる模様。

まあtcshとか指定されるよりはマシかと諦めてる。

>>42
なんで bash でスクリプト書くと馬鹿なの?

Linux、Mac OSだとシステムのデフォルトがbashだからそれほど拒否感ないけどな。
ただ「#/bin/sh」と書いておきながらbash依存な書き方するのはなんだかなぁという気もする。
まぁ、「こまけぇことはｒｙ」だな。

たしかに「!」を抜くのはいかんよな。

さすがLinux ユーザーびっくりですね。www

#!/bin/zsh
よりはまし

>>44
man bash 嫁

bash自身がバグとして、巨大過ぎる・重過ぎる、だからスクリプトに使うな、
って書いてあったりする。
しかしLinuxだと、bashばっかで本物のshが入ってないディス鳥多いしな。

そもそも本物のshって何だろう。v6あたりのbourne shellだろうか。
あんまり古い/bin/shだとPOSIX非互換だったりして、それはそれで
辛いよ。

そんなあなたにdash!

そんなあなたは ash

NetBSD時間…

俺こそが本流: ksh # mksh愛用中

一度でいいからwindowing kshを使ってみたかった…

>４９
普通の鳥に入ってると言えばBusyboxの中の人じゃね？
アレはshに近いんだっけ？

>>44
本人じゃないから想像だが、
bashがUNIX非標準の独自シェルだから、使われると動かないUNIX系OSが出てくるからじゃないかな。
UNIXの標準シェルはkshだが、Linuxには本物のkshはない。
kshクローンはLinuxにもあるけど本物のkshとの互換性が問題になるし、
Linuxやcygwinなどにはデフォルトではインストールされていないことが多い。
UNIXとUNIXクローンのOS間での互換を考えると、shの構文に収めないといけない。

>>42
cshならええ？
最近使わないから忘れそうだけど

>>49
今どきのマシンなら bash が重くて困る状況減ってるんじゃないの。

>>57
いろんな環境で動かすスクリプトだと問題かもね。
bash あること前提の環境でしか動かさないなら問題ない。

TVやプリンタ等の「組込み」で使うには、bashは論外。
ashだな。>>52

>>57
>UNIXの標準シェルはkshだが、Linuxには本物のkshはない。
>kshクローンはLinuxにもあるけど本物のkshとの互換性が問題になるし、

sysv系はたしかにkshだが、unixの標準シェルがkshというのは違うような。
# posix shellの元になったという意味では標準に近いけど、ksh==posix shではないし。

昔はkshのソースは公開されてなかったのでクローンを使うしかなかったけど、
今はオープンソースなので、linuxでも使おうと思えば本物のkshがふつーに使える。

>>62
ksh はこれに入ってるね。
http://www2.research.att.com/~gsf/download/

Debian とかだとパッケージもある。
http://packages.debian.org/ksh

日経Linux 8月号に、
Pythonで書かれた、MITライセンスの、
企業向け、データ操作用のコマンド、「Open usp Tukubai」と、
その商用版「usp Tukubai」の特集が載っている

ハンズラボがユニケージで内製しているという記事を見たので、
ユニケージ原論を買って読んだのだが、酷いなこれ
まるでカルト宗教だ
適用案件では常にお客さんと大ゲンカになっているらしいし

そもそも、ひたすら「シェルスクリプトは素人でもすぐに覚えられる」を繰り返してるけど
もうこの時点でウソじゃん

シェルスクリプトはソースがわかりやすいだと？
ワンライナーの呪文の列挙になってるじゃん

件の本には実際の業務画面のサンプルが一つも載ってないんだけど、
画面はどうやって対応してんだこれ

プログラム言語を普通に使える普通のプログラマだが、
それでもシェルスクリプトでプログラミングはしたくない。

バッドノウハウの固まりっていうか
意外な方法で、やりたいことを実現するという
コードの集まり。

数値計算にしろ文字列演算にしろ
数値比較にしろ

>>65
> ハンズラボがユニケージで内製しているという記事を見たので、
> ユニケージ原論を買って読んだのだが、酷いなこれ
> まるでカルト宗教だ
> 適用案件では常にお客さんと大ゲンカになっているらしいし
常に大喧嘩のソースは?
まさかユニケージ言論を読むと書いてあるの?www

>>62
UNIXはUNIXのライセンスを持っているOSのことをいい、
POSIX準拠のOSのことをいうのではない。
そして、kshはUNIXのライセンスを持っていないUNIXライクOSでは通常使えるようになっていない。

技術者はUNIXの精神を愛してるのであってUNIXを愛してる訳ではない

>>68
unix認証を受けてるIBMのz/OSはkshではなくて独自実装のshを使っているらしいよ。
触ったことないので伝聞だが。
単に/bin/shとして使っていないSUS認定UNIX、という程度ならMacOSXもそう。
/bin/kshとしてインストールされているので使おうと思えば使えるが、
標準シェルではない。

ということで、正規にunixを名乗ることを許されたものでも標準シェルがkshとは限らん。

逆に、そうでないOSでもベンダーがクローンではなくAT&T由来の本物のkshを
提供している例は腐るほどある。WindowsですらMicrosoft純正のkshバイナリが存在する。
標準シェル(/bin/sh)として使ってる例はさすがに知らんけど。
# OpenBSDの/bin/shはkshクローン。

>>70
Microsoft Windowsの標準シェルはcmd.exeで、kshは付いてこないよね。
標準シェルの捉え方が私と違っている。
私はshの呼び出し先の本体が標準シェルといっているわけではなく、
各UNIXにデフォルトでインストールされているシェルのうち最も高機能なシェルのことを言っている。
ライセンスを持っていないUNIXライクOSで、なんらかの手段を使えばkshも使えるという話は標準シェルの話題としては無意味。
デフォルトで入っているシェルの話をしているのだから。
なんらかの手段を講じないと使えないのは標準ではないからね。
本物のkshの話をしているのでkshクローンの話も意味がない。
今はどうか知らないが、昔、Linux上のpdksh(kshクローンのひとつ)でksh用のスクリプトを動かそうとしたが全然動かなかった。
とりあえず、正規UNIXではデフォルトでkshが入っていて、ライセンスのないUNIXライクOSはデフォルトでkshが入っていないのが普通なのではないだろうか。
そして、ライセンスのないUNIXライクOSは入れたくてもOS側がサポートしていないことが多いよね。
ソース入手してコンパイルしろとか、OS非サポートの野良ビルド使えとか、商用ソフトを買えとか、そんな状況のシェルで開発するのは問題があるだろう。
この話の発端は、bashがだめという意見が出たことだが、
今は正規UNIXよりUNIXライクOSのほうが主流だからbashでいいと思うけどね。
あえてbashがだめな理由を考えると、正規UNIXはkshがインストールされていてもbashがなかったりすることだという話。
それもbashの野良ビルドをインストールすればいいのかも知れないけど、しないですむならそれに越したことはないよね。

フレームワークもなしに大規模アプリとか馬鹿じゃねえか？

こんなスレがあったなあと思い出して貼りにきた

フルスクラッチから1日でCMSを作る シェルスクリプト高速開発手法入門 [大型本]
http://www.amazon.co.jp/dp/4048660683/

シェルは文法がこなれていない。
本来ファイルをフィルタに掛けるような用法を主眼にしてるから
そこだけ一点豪華になってて、汎用性に欠けるのでは。

とりあえず日本語エディタとか作ってみてよ。

>>73
著者のUSP研究所の上田隆一って、
雑誌 Software Design でよく記事を書いている人だね

漏れはプログラマーだから、この人の記事はよく読む

#!/bin/sh
# nihongo editor
cat > $1

システムをファイルを分けて書くときに、ファイルをまたぐ参照とか呼び出し
とかのオーバーヘッドが大きそうだな。すれにスクリプトやインタプリター
言語は、実行時になって始めてわかるエラーがコンパイラ言語に比べて
多くなるだろ。たとえば未定義変数とか、引数の不整合とか、型の不一致とか、
未定義関数とかの。コンパイラ言語だと、滅多通らない処理の箇所でも、一応
全部の可能性ある処理の経路にそって、参照関係とか定義未定義のチェックは
コンパイル時にできているわけで、もちろんファイルを分割したら、リンク時
まで参照の解決が終わらないけれども。実行前にある程度多くの検査ができて
いることになるから。