Re: Integrating bash into a GTK+ application

[Tristan Van Berkom <vantr touchtunes com>]

I know that emacs does something like that 
(ecexute's a shell in an emacs buffer) so you
could probably re-use alot of code from that.

((hmmmm or maybe (it)), (was(written, with), (a, lisp)));

not sure realy.

Come to think of it... I never compiled emacs; but
I'm still betting that emacs is open-source.

Actualy, you could probably write this app as
a plugin to xemacs (that might defeat the purpose
though; I dont see any anti-bashers useing emacs ;P)

You'll also need some kind of "sounds like" routine
i.e "move" sounds like "mv". There must be alot of
algorythems for that available. also you wont be able
to support _ALL_ commands (most of them being programs
to begin with _including_ "mv"). some of them differ
from system to system i.e. "ifconfig" Is on redhat/mandrake
and I forget the FreeBSD equivalent.
You might want to have a list of all files found in $PATH
and a database with all the "supported" commands to
check against list.

I guess I'm rambleing on again...

$ cd /pub
$ more beer

Good luck!
        -Tristan


Horror Vacui wrote:
> I'm writing a program that should display a bash window, and be able to
> read from and write to this window, without interfering much. I'm in
> process of learning programming, so I don't know what's the best way to
> achieve this. I could do it in some roundabout-way, but since I intend
> to write a useable program and not only something to learn on, I'd like
> to do it the right way.
>
> A bit of description: I'm participating in a number of Linux-newbie
> lists, and a very common kind of question you get asked is "Tell me how
> to do this, but please without the command-line". The command line is
> great, but hard to learn, and many people could use help there. The idea
> is to write something like an xterm with an additional graphical UI,
> which should provide things like keyword search (so you can type "I want
> to move files" and get presented with a reasonable choice of related
> commands), organisation of available options in the most common and
> likely to be used, and specialised, with additional help and
> explanations. Actions in the GUI should immediately be visible in the
> bash window as they're selected, so people don't get locked into my
> GUI's way of doing it, but learn and come to a point where they don't
> need it any more. Therefore, it's important that the bash be a genuine
> bash, and not some kind of look-alike that'll behave in a non-standard
> way and teach people wrong lessons.
>
> I already have a kind of one-quarter functional skeleton-draft of the
> GUI part, and don't think it's good to work further on that before I
> have at least one-quarter functional bash.
>
> Thanks in advance.
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list