Awesome! Thanks Henrik and Alex.
Henrik - Yes, that's what I was envisioning. Thank you for the quick update
to the repository.
Alex - I hadn't thought about calling a shell - thanks for pointing this
The main use case is that I'm calling a combination of command line tools
to pull in data that can be represented as text and I need to do some
postprocessing such as aggregations or comparisons of the same data at
I've traditionally been using a combination of awk, sed, grep and small
python snippets and the various internal command line tools my company has
to access and process the data.
These are mostly ad hoc, but it's always nice to be able to replicate the
process on a fresh data set at a later point without much effort.
Maybe I should also mention that I'm coming from a mostly
Scala, some Clojure, Common LISP and now PicoLisp. I've been most impressed
by PicoLisp and it's general philosophy of simplicity and not imposing any
restrictions on its user - it's been a very humbling, but rewarding
experience so far.
Thanks again for the warm welcome everyone and I'm always interested in
learning how others incorporate Pico into their workflow.
On Thu Apr 17 2014 at 10:16:16 AM, Alexander Burger <a...@software-lab.de>
> Hi Simon,
> > What I'm really trying to do is have an easy way to invoke arbitrary
> > commands that may be piped, process the result in pico and maybe use that
> > as the input for another command.
> > I haven't found a generic example yet that doesn't specify the command
> > specifically that allows arbitrary piping and still gives you access to
> > intermediary results.
> The most general way is to use the 'in' function in combination with an
> invocation of the system shell ('bash' usually). This has more overhead
> than direcly calling commands, but allows you to use all features of the
> For example
> (in (list "sh" "-c" (pack "cmd1 -i" Var1 " -x " Var2 " | cmd2"))
> (while (line)
> ... ) )
> Here the 'while' loop assumes that there are no empty lines. Instead you
> may want to do
> (until (eof)
> ... )
> It is hard to give a general rule, it depends a lot on what you want to
> do. Perhaps you can post a concrete problem?
> ♪♫ Alex
> UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe