[erlang-questions] suggestion: shorthand functions

Garrett Smith <>
Tue Jan 15 18:47:49 CET 2013


Hi Loïc,

I use run_erl/to_erl as a proxy for OS signals. You can also use
to_erl as a tty terminal via pipes, but that's not the case I'm
talking about.

Here's a simple example, requesting an orderly shutdown of the VM:

1. Start the VM as a daemon using run_erl

$ mkdir -p /tmp/myapp
$ run_erl -daemon /tmp/myapp/ tmp/myapp/ erl [your erl start args here]

2. Send a shell command to the VM by way of to_erl and run_erl

$ echo "init:stop()." | to_erl /tmp/myapp/

You can tail the logs on /tmp/myapp/ to see what's going on. run_erl
is basically an Erlang shell that exposes read and write access over
pipes (FIFOs).

$ to_erl /tmp/myapp/

If you want to get values from the process, you can write to the log
(similar to Java's SIGQUIT behavior) or to a file. E.g.

$ echo 'myapp:write_status("/tmp/myapp/status").' | to_erl /tmp/myapp/

If the app requires tighter interactivity with a CLI this approach
starts to break down. Then you're back to distributed Erlang or
roll-your-own interface (REST, simple RPC server, etc.)

My *main* beef with distributed Erlang is epmd. It starts lazily and
when killed (e.g. someone uninstalls the program and user that
*happened* to start it) each of your local nodes goes dark.

I recall seeing some activity around improving epmd somehow (don't
remember) but IMO the problem is that it's a shared resource that
isn't explicitly managed (started by the first Erlang node to need
it).

It'd be nice if you could have some of the distributed Erlang
goodness, but with explicit ports and addressing - no NATing.

Also, IMO Erlang should fail to start in distributed mode if epmd is
*not* already running (with optional override). This would force epmd
to be explicitly managed as an external dependency, which is what it
in fact is.

Garrett

On Tue, Jan 15, 2013 at 9:43 AM, Loïc Hoguin <> wrote:
> Can you give an example of such a run_erl use? I have no idea how the tool
> works.
>
>
> On 01/15/2013 03:24 PM, Garrett Smith wrote:
>>
>> Hi Mahesh,
>>
>> Sounds like Yuri's driver is distributed Erlang.
>>
>> There are a bunch of apps out there that implement their command line
>> interfaces (CLI) as distributed Erlang nodes that spin up, interact
>> with another local node, then shut down. RabbitMQ does this.
>>
>> I *hate* it! (anger issues)
>>
>> - It's slow -- slower than *Java* for CLI operations
>>
>> - It's brittle -- distributed Erlang can fail for a number of reasons
>> that are hard to diagnose
>>
>> - It introduces a third OS process -- epmd, a little
>> single-point-of-failure devil that is the devil
>>
>> I personally advocate run_erl, which exposes a shell to to_erl over
>> pipes. It's trivial to send commands to an Erlang process from bash or
>> Python or anything you like.
>>
>> Some have criticized this approach as also being brittle. All I can
>> say is that I've used this for years across thousands of servers and
>> I'm very happy with it.
>>
>> That said, I often spend my Sunday mornings over coffee wondering how
>> OS signal support isn't supported in Erlang.
>>
>> Garrett
>>
>> On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya
>> <> wrote:
>>>
>>> Ah, you misunderstand.
>>> I'm not running around saying Perl Now! Perl Forever!
>>> Instead, what we do is separate the problem domains (to the extent
>>> possible,
>>> of course).
>>> There is some set of functionality in the erlang application that needs
>>> to
>>> be exposed to our business processes - think "add a user", "disable a
>>> client", "add billing credits", etc.
>>> These are encapsulated and exposed via escript, and then embedded in perl
>>> via 'system' / 'qx' / backquotes / whatever.
>>> The same applies for activities like "rebalance node", "move user to
>>> debug
>>> node", etc. :-)
>>>
>>> cheers
>>> Mahesh Paolini-Subramanya
>>> That Tall Bald Indian Guy...
>>> Google+  | Blog   | Twitter  | LinkedIn
>>>
>>> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii <> wrote:
>>>
>>> Mahesh,
>>>
>>> This is certainly a good point about bash/perl/python/whatever, but these
>>> become quite useless the moment you need to talk to some erlang node from
>>> your escript.
>>>
>>> Yurii.
>>>
>>> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya
>>> wrote:
>>>>
>>>>
>>>> I love escripts but find myself intuitively avoiding them for a couple
>>>> reasons:
>>>>
>>>> - In most cases, bash is more portable and solves system level
>>>> problems more directly
>>>>
>>>> - I don't have the escript foo required to wrench my program it into a
>>>> single script file
>>>>
>>>>
>>>> Amen.
>>>> perl (bash, python, whatever) is optimally suited for orchestrating
>>>> between 'application space' and 'business space', as well as
>>>> orchestration
>>>> across loosely coupled systems and activities.
>>>> Yes, you could force most of this into erlang-world, but to what point?
>>>> IMHO, we do live in a polyglot world, and we may as well take advantage
>>>> of
>>>> it…
>>>>
>>>> Cheers
>>>>
>>>> p.s. Mind you, there is an entirely different argument to be made about
>>>> systems where you only have access to erlang (or Ada. or whatever :-)  )
>>>>
>>>> Mahesh Paolini-Subramanya
>>>> That Tall Bald Indian Guy...
>>>> Google+  | Blog   | Twitter  | LinkedIn
>>>>
>>>> On Jan 11, 2013, at 9:55 AM, Garrett Smith <> wrote:
>>>>
>>>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen
>>>> <> wrote:
>>>>
>>>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:
>>>>
>>>> Since I've been writing a bunch of rebar.config.script code lately,
>>>> I've suffered the agony of trying to write concise and readable
>>>> code without having to do tons of copy-paste, weird unwrapping
>>>> funs etc.
>>>>
>>>> What I think would make this sort of thing easier, and also
>>>> escript programming in general, is if OTP could provide some
>>>> modules with concise naming and let-it-fail semantics.
>>>>
>>>> Just off the top of my head, I scribbled down a few functions that
>>>> I think would make *my* life easier. I pushed them to github to
>>>> get some discussion going.
>>>>
>>>> http://github.com/uwiger/shorthand
>>>>
>>>> The modules are:
>>>>
>>>> f.erl - shorthand functions for file.erl
>>>> fn.erl - ditto for filename.erl
>>>> e.erl - ditto for erl_eval.erl
>>>>
>>>> The least beneficial is perhaps filename:erl, but my fingers and
>>>> eyes ache from all the filename:join(filename:dirname(F), …)
>>>> code.
>>>>
>>>> Otherwise, I think the biggest benefit is to stick to let-it-crash
>>>> programming, which I find is usually the default when I write
>>>> scripts. The original functions are always available if you want
>>>> to take a closer look at return values.
>>>>
>>>> (For the file:script() counterparts, I also always pass the name
>>>> of the script as a binding).
>>>>
>>>> Comments?
>>>>
>>>>
>>>> I think it is a nice idea that would improve scripting.
>>>>
>>>> But how to agree on module names and content is harder. There is a
>>>> limited
>>>> number of 1 and 2 character module names, and once in OTP they are
>>>> written
>>>> in stone.
>>>>
>>>>
>>>> Aye. I don't know how critical this use case is (scripting
>>>> simplification/improvements) to justify new modules in OTP space. And
>>>> I'm not sure there *is* a case that would be sufficiently ubiquitous.
>>>>
>>>> I've resigned myself to writing little project specific
>>>> functions/libraries like this to deal with project specific problems.
>>>> E.g. this stuff drives me nuts:
>>>>
>>>> {ok, X} = foo:x(),
>>>> {ok, Y} = foo:y(),
>>>> combine(X, Y)
>>>> ...
>>>>
>>>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get
>>>> this:
>>>>
>>>> combine(foo_x(), foo_y())
>>>>
>>>> But who knew that I needed those particular variants? And what about
>>>> changes? It's my project, so I don't mind little wrappers, especially
>>>> since functions clarify intent.
>>>>
>>>> E.g. when I see this:
>>>>
>>>> ProjectFile = filename:join(ProjectDir, ProjectName)
>>>>
>>>> I'll almost create a function like this:
>>>>
>>>> project_filename(Dir, Name) -> filename:join(Dir, Name).
>>>>
>>>> For f.erl I miss e.g is_dir from filelib, which would introduce the
>>>> notion
>>>> of merging old module functionality. Using the name 'fl' for filelib
>>>> functions would just be hard to remember.
>>>>
>>>> Aliasing filename:basename to fn:base is a bit unintuitive since the
>>>> original Unix command is called 'basename' and for e.g file:list_dir
>>>> you have aliased it to f:ls (as for many other) to make them more
>>>> Unix:ish.
>>>> I think it would be better to keep to unix command names where possible.
>>>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]
>>>>
>>>>
>>>> It seems one could make these arguments ad nauseam. To me it's just
>>>> easier (and preferable frankly) to roll my own as the need arises.
>>>>
>>>> An alternative approach might be to have a helper module named 'es'
>>>> containing all scripting aliases...
>>>>
>>>>
>>>> I love escripts but find myself intuitively avoiding them for a couple
>>>> reasons:
>>>>
>>>> - In most cases, bash is more portable and solves system level
>>>> problems more directly
>>>>
>>>> - I don't have the escript foo required to wrench my program it into a
>>>> single script file
>>>>
>>>> Setting bash aside (not Ulf's use case) the main barrier for me is in
>>>> the perceived complexity of getting a release-of-sorts into an
>>>> escript. If I could write up one of these wrapper libraries, or pull
>>>> it down from somewhere easily, I might use escript everywhere. It's
>>>> not hard to write the wrappers (you write them as you need them, it
>>>> takes literally less than a minute for each function) and they're
>>>> tailored to your requirements.
>>>>
>>>> It may be trivial to package up the required bytes into an escript
>>>> today. If it is, I've love to know!
>>>>
>>>> And I don't know how this fits into rebar specific scripting :)
>>>>
>>>> Garrett
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu



More information about the erlang-questions mailing list