Bug 153 - Include output from an executable.
Summary: Include output from an executable.
Status: REOPENED
Alias: None
Product: Slony-I
Classification: Unclassified
Component: slonik (show other bugs)
Version: devel
Hardware: PC Linux
: low enhancement
Assignee: Slony Bugs List
URL:
Depends on:
Blocks:
 
Reported: 2010-08-25 20:16 UTC by Stuart Bishop
Modified: 2016-08-27 11:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Bishop 2010-08-25 20:16:58 UTC
I find it very useful to be able to use the shell to include chunks of slonik script generated by scripts:

$ slonik <<EOM
`./preamble.py`
echo 'Do stuff';
EOM

Hello from preamble
Do stuff


It would be great if I did not have to use the shell to do the inclusion, and instead if slonik supported the back tick syntax internally.

$ cat foo.sk
`./preamble.py`
echo 'Do stuff';
EOM
$ slonik foo.sk
Hello from preamble
Do stuff
Comment 1 Christopher Browne 2010-08-26 09:07:22 UTC
You'd like slonik to take ``, expand it via system() (or similar), and then execute it?

This seems like a rather large expansion of scope for what's intended to be a "Little Language."

There's some thinking out there that slonik is already a bit too big, and that we should be considering eliminating it in favour of just running the underlying stored functions.

There's a bit of a problem with that for some operations that have a lot more functionality than "just stored functions" (notably: store node, lock set, execute script, wait for event, set add table), but, in any case, there's certainly thinking towards "simplify slonik."

One of the failures, as it were, of the project is that we were expecting that a management GUI would emerge, so that the need for slonik might wither away.  Obviously not the case ;-).  I'm not particularly keen on trying to turn slonik into a more full-fledged programming language, though.
Comment 2 Stuart Bishop 2010-08-26 20:42:03 UTC
> You'd like slonik to take ``, expand it via system() (or similar), and then
> execute it?

Yes. This allows me to embed commands that can only be determined at
run time in a slonik script. The preamble is the most common example
of this - I can run identical scripts on our staging and production
environments. I first picked up the idea of using shell expansion from
examples on the web, so I'm not the only one doing things this way.

> This seems like a rather large expansion of scope for what's intended to be a
> "Little Language."
>
> There's some thinking out there that slonik is already a bit too big, and that
> we should be considering eliminating it in favour of just running the
> underlying stored functions.
>
> There's a bit of a problem with that for some operations that have a lot more
> functionality than "just stored functions" (notably: store node, lock set,
> execute script, wait for event, set add table), but, in any case, there's
> certainly thinking towards "simplify slonik."

So I have developers running non-replicated systems, buildbots running
non-replicated on ec2, replicated staging systems, replicated
production systems. Our database schema is highly agile, with database
patches being added by developers and a tool that applies these
patches. It has to be automated so a management GUI is useless to me.
I have the choice of generating slonik scripts, or generating SQL that
invokes the stored functions. Using the raw stored functions seemed
very problematic - slonik handles the surprising details such as
connecting to the right node to run a function, when to commit, when
to wait for propagation,  how to recover from failure etc. slonik
seems the less surprising, less error prone and more readable
approach.


> One of the failures, as it were, of the project is that we were expecting that
> a management GUI would emerge, so that the need for slonik might wither away.
> Obviously not the case ;-).  I'm not particularly keen on trying to turn slonik
> into a more full-fledged programming language, though.

My systems have to be automated and are running on the other side of
the planet, so a management GUI is pretty much useless to me. I agree
slonik should not become a full-fledged programming language - better
to embed the high level commands into an existing scripting language.
libslonik?
Comment 4 Steve Singer 2013-06-06 12:13:50 UTC
Please ignore the previous comment/commit, it applies to the wrong bug