投稿者「sasakima-nao」のアーカイブ

Mac JavaScript getenv

Linux 屋が Mac を使うと環境変数が少ないなぁと感じる。

env

そのせいか osascript で環境変数を得る方法がなかなか見つからなかった。
いくら検索してもパスを通すことばかり、Windows と変わらないじゃん。
三時間くらい探し続けてやっと見つけた。

CotEditor :: ひまつぶし雑記帖

鳶嶋工房 / AppleScript / JavaScript for Automation (JXA)

osascript って stdlib のインクルードも可能なのか。
なら stdio もイケるかも、よしやってみよう。

#!/usr/bin/osascript

ObjC.import("stdlib");
ObjC.import("stdio");

var user = $.getenv("USER");
//console.log("ユーザー名は " + user + " です");
// 戻り値が出力されるので変数に入れている
// printf って転送バイト数が戻るとは知らなかった...
// 自動改行されるので \n を省いています
var dev_null = $.printf("ユーザー名は %s です", user);

/* //ShellScript から得るという手段もある
app = Application.currentApplication();
app.includeStandardAdditions = true;
var path = app.doShellScript("echo $LANG");
console.log("$LANG は " + path + " です");
*/

getenv

なんだよ、glibc の関数が普通に使えるじゃないか。
しかし今まで何気に使っていた printf にこんな罠が。

ただ printf と console.log は混在させないほうがいい。
上記下側のコメントアウトを外してみよう。

output_pointer

出力が上下で入れ替わってしまった、ように見えますが。
単に printf と console.log で出力ポインタ管理が違う。
つまり console.log の出力は行先頭のままになる。
結果、最初の出力が console.log の出力に押し出されてこうなる。

#!/usr/bin/osascript

ObjC.import("string");

var nae = "優木苗";
console.log(nae.length); //=>3
console.log($.strlen(nae)); //=>9

おぉ日本語のバイト数も C 標準関数を使えば得られる。
Gjs で GLib 関数がフルに使えるのとほぼ同じことができるのね。
Mac で JavaScript も想像していたより便利そうです。

jjs and gjs

jjs という JavaScript 実行コマンドがあることを今更知った。
JVM 上で動く、Jython みたいなものという解釈でいいのかな。
Open 含む JDK 1.8 の付属品で nashorn が実行エンジン。

openjdk_jjs

Fedora 23 にはデフォルトで入っている。
更に /etc/alternatives/jjs へのリンクが最初から /usr/bin にある。

Oracle Blogs 日本語のまとめ: [Java, JavaScript] Oracle Nashorn: A Next-Generation JavaScript Engine for the JVM

なんか起動が遅い、Java だから当然なのだが。
これでも IronPython より全然マシだ、てか DLR は完全に失敗作。

Gjs 同様に引数無しならインタラクティブシェルとして使える。
Ctrl+D で同様に終了できるけど改行してくれないな、別にイイけど。
引数に *.js を与えれば実行エンジンになる、まんま Gjs だな。

Gjs との違いは何だろう、遅くてもメリットがあるならヨシだし。

Nashorn(Java8のJavaScriptエンジン)でシェルスクリプト – よしなしごと

ってナンジャコリャ!ってくらい拡張されている。
ただこのシェル関連はインタラクティブシェルでは使えないようだ。

gjs, osascript で試すと全部できなかった、あたりまえか。
ヒアドキュメントだけでも他の実装に反映してほしいな。

Java Platform, Standard Edition Nashornユーザーズ・ガイド、リリース8

なんと JavaFX まで使えてしまうようです。
ただ OpenJDK には含まれていないので正規の Java8 が必要。

Changes/Java8 – FedoraProject

let は使えない。
実行引数の取得方法が実装毎で違うのはしかたがないが。
arguments オブジェクトが実行引数にも使えるのってコレ混乱しないかな?
引数指定に “–” が必要なのはどうなんだろう。
コレを忘れると引数を全部実行しようとするようだ。

#!/usr/bin/jjs

// gjs @ ARGV
// jjs @ $ARG or arguments (./hoge.js -- arg1 arg2)
// osascript @ function run(argv){}

var argv = $ARG;
//let argv = ARGV

if (argv.length == 0) {
    print("No argv");
} else {
    argv.forEach(function(element) {
        print(element);
    });
}

jjs, gjs とも console.log() は使えず print() で標準出力。
function run は AppleScript の機能なので当然 osascript のみ。
他色々あるけど、そもそもインポートできるものがバラバラ。
シバンを書いておかないとワケワカになるかも。

色々あるけど Java の資産があるなら便利だよね。
それよりバイトコードにビルドせず jre が使えることのほうが大きいかも。

ってドンダケ筆者はコンパイルが嫌いなの!と思われそう。
しかしなんか本格的に JavaScript の時代になってきているNE!

Mac Script (No Terminal.app)

Mac で AppleScript/JavaScript を端末起動無しで使う手段があった。

OSXのアプリケーションをJavaScriptで作る – Qiita

Mac には osacompile なんてスクリプトコンパイラがあったのか。
これで Mac でもスクリプトを使う時にターミナルを開かずに使えるぞ!

っっって、それじゃ意味無いジャン。

スクリプト言語はコンパイルせずにスパッと使えるのがメリットなんだから。
つかコンパイルするなら Swift とかで作ったほうが絶対に楽だし。

世の中にはそうしたい奇妙な人が結構いることは置いておいて。
特に IronPython でコンパイルしたい人の多さにドン引きDESU。

うーん、コンパイルせずにターミナルを開かない方法は…
あ、Automator という手があった。

Automatorで簡単にコマンド実行アプリを作る|MacFan

この程度ならシェルスクリプトのほうが圧倒的に簡単だと思うんですけど…
それはいいとして。

この手段で端末を開かずに bash 等のシェルが使えるようだ。
本当に上手くいくのかな?
JavaScript でウインドウを作って試してみよう。

いや、筆者はまだ Cocoa がよく解っていない。
なので上のリンク先にあるウインドウを作るスクリプトをコピペ。

app_create

と Bash から osascript にスクリプトのフルパスを与えて。
JavaScript でも -l オプションは必要無かったのね。
/Applications 内に保存して Finder から W クリックしてみる。

app_exec

よしスクリプトのまま端末起動無しで実行できた。
しっかり Dock にも表示される、アイコンは自前で入れればイケそう。

実行パーミッションを付ける必要もないしメンテも簡単そう。
シェルで起動しているだけだから Python でも何でもイケるな。
何より書き換えしてもコンパイルのやりなおしをする必要が無い。

いいことづくめに感じるけど、ただただ面倒臭い!
Linux と PyGObject コンビがドンダケ神がかっているか思い知るだけだった。

Nemiver Vala

何を今頃気になった。
前記事のように C/C++ という特定言語での GUI デバッガは Nemiver で賄える。
っって Vala みたいな別言語へのジェネレーターだとどうなるんじゃ?
gdb 直使いな人も気になる所かも。

経験値が多いなら出力された C ソースへリンクと予測できる。
でもやってみなきゃ断言できないな、試すとしよう。

Gtk.Application ? gtk+-3.0

valadoc.org がしばらく見ない内に色々進化していた。
ソコらはもっと詳しい人にまかせてと。
このページにある vala ソースを gedit にこんな外部ツールで Nemiver に渡してみる。

vala_gedit

nemiver_vala

全然面白くない結果になってしまった。
Vala から使っても生成された C ソースへのリンクになるってことね。
コレだと Vala で書いているソースコードの直接的デバッグにならないんですが。

Vala という超マイナーな言語で書ける人という時点で(以下略
現状ならソレでいいけどさ。
未来なんて誰も断言できないから。
スマートフォンがココまで普及すると予測できた人なんているのか?

Gedit gcc

Gedit の外部ツールは便利だが自分で設定したショートカットキーを忘れる。
簡単なキーに割付けたくてもできないことも多いし。
特に C ビルドで GLib や Nemiver の利用を振り分けしたい場合とか。

Nemiver | PaePoi

本格的に作るものなら当然 Makefile を用意するので問題ない。
けれどチビッと試したいコードのためにそんな面倒したくないですよ。
プログラミング関連は全部 F5 キーだけでまかなえないものか。

そうだ、’GLib.h’ という文字列が含まれているかどうかで振り分けできないか?
ものは試しだ、こんなツールを作ってみた。

#!/bin/sh
PYTHON="text/x-python"
GJS="application/javascript"
HTML="text/html"
BASH="application/x-shellscript"
VALA="text/x-vala"
CSRC="text/x-csrc"
echo @MIMEtype $GEDIT_CURRENT_DOCUMENT_TYPE
if [ $GEDIT_CURRENT_DOCUMENT_TYPE = $PYTHON ]; then
    python3 $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $GJS ]; then
    gjs $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $HTML ]; then
    google-chrome $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $BASH ]; then
    sh $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $VALA ]; then
    vala $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $CSRC ]; then
    src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
    case $src in
        *gtk.h*)
            echo "Gtk Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0` ;;
        *glib.h*)
            echo "GLib Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0` ;;
        *)
            echo "Gcc Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH ;;
    esac
else
    echo Non Support File
fi

全部読み込んで case 文にしたのは inclide が一行目とは限らないので。
ぶっちゃけ効率ガン無視だがチョコッとビルド用途なのでいいよね。

ついでに Nemiver 用も

#!/bin/sh

src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
case $src in
    *gtk.h*)
        echo "Gtk Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0`
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
    *glib.h*)
        echo "GLib Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0`
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
    *)
        echo "Gcc Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
esac

gedit_tool

これで F5 を押すだけで筆者が使う言語は全部まかなえるぜ。
あと PHP があるけどこれは Apache 経由でしか使わないので。

いや、本当はモードごとに書いたほうがいいのだろうけどね。
ツールが一つで自力振り分けのほうが筆者はメンテが楽なだけ。