Mahesh,<div><br></div><div>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.</div><div><br></div><div>Yurii.<br><br>On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style="word-wrap:break-word"><div><blockquote type="cite">I love escripts but find myself intuitively avoiding them for a couple reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file</blockquote><br></div><div>Amen.</div><div>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.</div><div>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…</div><div><br></div><div>Cheers</div><div><br></div><div>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 :-)  )</div><div><br><div><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div><div style="margin:0in 0in 0.0001pt"><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:15px"><b><i><div style="margin:0px;font-style:normal;font-weight:normal;font-family:Calibri"><a href="http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png" target="_blank"><b><i>Mahesh Paolini-Subramanya</i></b></a></div></i></b></span></font></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">That Tall Bald Indian Guy...</span></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><div style="margin:0px;font-family:Calibri;color:rgb(1,108,226)"><span style="text-decoration:underline"><a href="https://plus.google.com/u/0/108074935470209044442/posts" target="_blank">Google+</a></span><span style="color:rgb(31,73,125)">  | <a href="http://dieswaytoofast.blogspot.com/" target="_blank"><span style="color:rgb(1,108,226)">Blog</span></a></span><span style="text-decoration:underline"> </span><span style="color:rgb(31,73,125)">  | <span style="color:rgb(1,108,226)"><a href="https://twitter.com/dieswaytoofast" target="_blank">Twitter</a></span></span><span style="color:rgb(31,73,125)">  | </span><a href="http://www.linkedin.com/in/dieswaytoofast" target="_blank">LinkedIn</a></div></span></div></div>
</div>
<br><div><div>On Jan 11, 2013, at 9:55 AM, Garrett Smith <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="HuI2qUZw68EJ">g...@rre.tt</a>> wrote:</div><br><blockquote type="cite">On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen<br><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="HuI2qUZw68EJ">raimo+erlan...@erix.<wbr>ericsson.se</a>> wrote:<br><blockquote type="cite">On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:<br><blockquote type="cite">Since I've been writing a bunch of rebar.config.script code lately,<br>I've suffered the agony of trying to write concise and readable<br>code without having to do tons of copy-paste, weird unwrapping<br>funs etc.<br><br>What I think would make this sort of thing easier, and also<br>escript programming in general, is if OTP could provide some<br>modules with concise naming and let-it-fail semantics.<br><br>Just off the top of my head, I scribbled down a few functions that<br>I think would make *my* life easier. I pushed them to github to<br>get some discussion going.<br><br><a href="http://github.com/uwiger/shorthand" target="_blank">http://github.com/uwiger/<wbr>shorthand</a><br><br>The modules are:<br><br>f.erl - shorthand functions for file.erl<br>fn.erl - ditto for filename.erl<br>e.erl - ditto for erl_eval.erl<br><br>The least beneficial is perhaps filename:erl, but my fingers and<br>eyes ache from all the filename:join(filename:<wbr>dirname(F), …)<br>code.<br><br>Otherwise, I think the biggest benefit is to stick to let-it-crash<br>programming, which I find is usually the default when I write<br>scripts. The original functions are always available if you want<br>to take a closer look at return values.<br><br>(For the file:script() counterparts, I also always pass the name<br>of the script as a binding).<br><br>Comments?<br></blockquote><br>I think it is a nice idea that would improve scripting.<br><br>But how to agree on module names and content is harder. There is a limited<br>number of 1 and 2 character module names, and once in OTP they are written<br>in stone.<br></blockquote><br>Aye. I don't know how critical this use case is (scripting<br>simplification/improvements) to justify new modules in OTP space. And<br>I'm not sure there *is* a case that would be sufficiently ubiquitous.<br><br>I've resigned myself to writing little project specific<br>functions/libraries like this to deal with project specific problems.<br>E.g. this stuff drives me nuts:<br><br>{ok, X} = foo:x(),<br>{ok, Y} = foo:y(),<br>combine(X, Y)<br>...<br><br>So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this:<br><br>combine(foo_x(), foo_y())<br><br>But who knew that I needed those particular variants? And what about<br>changes? It's my project, so I don't mind little wrappers, especially<br>since functions clarify intent.<br><br>E.g. when I see this:<br><br>ProjectFile = filename:join(ProjectDir, ProjectName)<br><br>I'll almost create a function like this:<br><br>project_filename(Dir, Name) -> filename:join(Dir, Name).<br><br><blockquote type="cite">For f.erl I miss e.g is_dir from filelib, which would introduce the notion<br>of merging old module functionality. Using the name 'fl' for filelib<br>functions would just be hard to remember.<br><br>Aliasing filename:basename to fn:base is a bit unintuitive since the<br>original Unix command is called 'basename' and for e.g file:list_dir<br>you have aliased it to f:ls (as for many other) to make them more Unix:ish.<br>I think it would be better to keep to unix command names where possible.<br>[Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]<br></blockquote><br>It seems one could make these arguments ad nauseam. To me it's just<br>easier (and preferable frankly) to roll my own as the need arises.<br><br><blockquote type="cite">An alternative approach might be to have a helper module named 'es'<br>containing all scripting aliases...<br></blockquote><br>I love escripts but find myself intuitively avoiding them for a couple reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file<br><br>Setting bash aside (not Ulf's use case) the main barrier for me is in<br>the perceived complexity of getting a release-of-sorts into an<br>escript. If I could write up one of these wrapper libraries, or pull<br>it down from somewhere easily, I might use escript everywhere. It's<br>not hard to write the wrappers (you write them as you need them, it<br>takes literally less than a minute for each function) and they're<br>tailored to your requirements.<br><br>It may be trivial to package up the required bytes into an escript<br>today. If it is, I've love to know!<br><br>And I don't know how this fits into rebar specific scripting :)<br><br>Garrett<br>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="HuI2qUZw68EJ">erlang-q...@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></blockquote></div><br></div></div></div></blockquote></div>