Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 17057: /trunk/plugins/lua/: Makefile.a
On 1/20/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> LEGO wrote:
> > I find out about lua while trying to get Scite to compile on my mac...
> > and guess what... I did not make it to have scite running on my mac.
>
> Just using SciTE on Win32 for quite a while, installation wasn't a problem.
> That's why I like binary Win32 installers a lot ;-)
> I'm using it as a quick loading editor for the small everyday ASCII files.
For most MAC applications you just need to drag an icon into your hard
drive. for most unix code you just need to install darwinports and do
"port install xxx" on the shell, trust me SciTE is a very rare case
(Until I or someone else get it "ported").
So far SciTE is realy the only thing I miss of my "before I used a Mac" days.
> > There are libraries with which to add this kind of features to lua, if
> > they aren't at least it's easy to extend.
>
> Again, in my eyes scripting is about easily extending Ethereal with functions not yet available.
> Example problem could be: Send an E-Mail if a special packet was captured.
> "lua solution": Find a suitable SMTP library, find out how to add it to lua and then find out how
> to use it within lua
> ... doesn't seem to be the "easiest way" ;-)
Nope, I get your point. But let me tell you that sending a mail when
you see a "special" packet is something you do not want to do. I see
more problems than solutions coming out from that.
> > I do not know if having a language that can do syscallls embeded into
> > ethereal would be a good idea. Remember that on linux (AFAIK) if you
> > want to capture you must be root so adding such features by default
> > would be like having a setuid shell available to the users.
>
> Work on capturing using (setuid'ed) dumpcap for (t)ethereal is on the way, so this hopefully won't be a problem in the "near" future as Ethereal itself (especially epan) won't need to be running "root'ed" any longer, see also: http://wiki.ethereal.com/Development/PrivilegeSeparation
>
> Having a script language without the ability to do syscalls (and alike) seems to be limiting the general scripting usage a lot.
>
> Hmmm, lua can also do the "trick" anyway: os.execute (command)
> http://www.lua.org/manual/5.0/manual.html#5.7: "It passes command to be executed by an operating system shell"
As far as you load the os library. What about
os.execute("echo a bad packet has arrived | mail -s 'bad packet'
someone@xxxxxxxxxxxxx")
I think that could be a problem^H^H^H^H^H^H^Hsolution to the "Send an
E-Mail if a special packet was captured" problem.
> > OK, there are things like erlang, scheme or lisp that are different in
> > naure and you need to "think different" to code in them but I see
> > perl, python and lua as different languages that express preety much
> > the same concepts.
>
> That way you could argue "why not using C". A lot of work while programming is not
> about the concepts of the language itself, but the work required to learn the surroundings, e.g.
> installation, find docs, learn which extension module is suitable and how to work with it,
> surround design flaws and all that stuff.
I see Lua as preety straightforward... even as a language: the gramar
is minimal, the reference manual is less than 40 pages. It has some
weird things but nothing compared to perl or python.
why not using C?
As you might know C is (human) time-consuming, bug prone and hard to debug.
> > For every answer I looked for while looking into embeding python I got
> > more questions... It is probably my problem but if I cannot get my
> > answers I get frustrated after little time.
>
> No, that's a very common problem to people (including myself) and I already guessed that it was your main reason, the lua instructions looking pretty easy for this task :-)
>
> I had a short look into the python docs regarding the C embedding and was confused as well :-(
The main issue here is that Lua was designed to be embeded, while
python was made into an embedable language (BTW I'm not aware of any
program with python embeded).
> > It's in my very nature to move in many directions, so it's probable I
> > take rigth ones... and wrong ones as well.
> >
>
> I show the same behaviour "to move in many directions", especially on some special saturday nights ;-)
>
>
> As I said before, using an existing scripting language is far better than creating a new one (no need to reinvent the wheel).
<noise>Reinventing the wheel to have air inside rubber protecting the
hard core from shock was preety useful... Imagine controlling a car
with hard wheels while breaking. </noise>
> The selection of the "right" scripting language will be biased on many things and a "straightforward" approach is often simply the right choice :-)
>
> So as you are doing all the work for now, it's obviously up to you ;-)))
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
