bash - jq or xsltproc alternative for s-expressions? -

i have project contains bunch of small programs tied using bash scripts, per unix philosophy. exchange format looked this:

meta1a:meta1b:meta1c ast1 meta2a:meta2b:meta2c ast2 

where :-separated fields metadata , asts s-expressions scripts pass along as-is. worked fine, use cut -d ' ' split metadata asts, , cut -d ':' dig metadata. however, needed add metadata field containing spaces, breaks format. since no field uses tabs, switched following:

meta1a:meta1b:meta1c:meta 1 d\tast1 meta2a:meta2b:meta2c:meta 2 d\tast2 

since envision more metadata fields being added in future, think it's time switch more structured format rather playing game of "guess punctuation".

instead of delimiters , cut use json , jq, or use xml , xsltproc, since i'm using s-expressions asts, i'm wondering if there's nice way use them here instead?

for example, looks this:

(echo '(("foo1" "bar1" "baz1" "quux 1") ast1)'  echo '(("foo2" "bar2" "baz2" "quux 2") ast2)') | sexpr 'caar'  "foo1" "foo2" 

my requirements are:

• straightforward use of stdio minimal boilerplate, since that's programs read/write data
• easily callable shell scripts or provide very compelling alternative bash's process invocation , pipelining
• streaming i/o if possible; ie. i'd rather work 1 ast @ time rather consuming whole input looking closing )
• fast , lightweight, if it's being invoked few times; each ast few kb, can add hundreds of mb
• should work on linux @ least; cross-platform nice

the obvious choice use lisp/scheme interpreter, 1 i'm experienced emacs, far heavyweight. perhaps implementation more lightweight , suited this?

in haskell i've played shelly, turtle , atto-lisp, of code spent converting between string/text/bytestring, wrapping/unwrapping lisps, implementing own car, cdr, cons, etc.

i've read little scsh, don't know if appropriate either.

you might give common lisp try.

straightforward use of stdio minimal boilerplate, since that's programs read/write data

(loop (attributes ast) = (safe-read) (print ...) 

• read/write standard input , output.
• safe-read should disable execution of code @ read-time. there @ least one implementation. don't eval ast directly unless know what's in there.

easily callable shell scripts or provide compelling alternative bash's process invocation , pipelining

in same spirit java -jar ..., can launch common lisp executable, e.g. sbcl, script in argument: sbcl --load file.lisp. can dump core or executable core of application preloaded (save-lisp-and-die). or, use cl-launch above automatically, , portably, , generates shell scripts and/or makes executable programs code.

streaming i/o if possible; ie. i'd rather work 1 ast @ time rather consuming whole input looking closing )

if whole input stream starts (, read read up-to closing ) character, in practice done: source code in common lisp not enclosed in 1 pair of parenthesis per-file, sequence of forms. if stream produces not 1 many s-exps, reader read them 1 @ time.

fast , lightweight, if it's being invoked few times; each ast few kb, can add hundreds of mb

fast be, if save core. lightweight, well, well-known lisp images can take disk space (e.g. 46mb), issue. why is important? maybe have definition lightweight means, because unrelated size of ast parsing. there should no problem reading ast, though.

should work on linux @ least; cross-platform nice

see wikipedia. example, clozure cl (ccl) runs on mac os x, freebsd, linux, solaris , windows, 32/64 bits.