GTKdialog programming: displaying data in Table. (Solved)

[GuestToo]

i think bash and Busybox's ash (at least the older version of Busybox) have different and incompatible syntax for shell script functions

if you are sure your program is not going to be used on a version of Puppy that only has ash, not bash, then you can use the bash syntax without problems

personally, i try to make my programs as generic as possible, so i avoid using shell functions that might confuse Busybox, but each programmer has his/her own choices to make ... there's nothing really wrong with choosing to write programs that will only work with bash, and will not work with Busybox's ash

just something to consider when writing programs for Puppy ... it may not really apply in this particular case

[MU]

My Bash book shows functions differently, no "function", just "name()" (bourne?).
Q; Is the file actions a function library? It seems different, more like a sub app.

Don't know, googled, found this, used it:
http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-8.html

I've also noticed Linux & Bash tend to use files alot instead of variables.
Q; Different shells etc. to pass data between, & no O.S. level global user variable handling?

I don't understand that, can you ask it different?

I assume this is one of those "ignore it errors": fill_entry_by_command(): No such file or directory
Perhaps complaining about passing the zero "listpw \$User 0"?
Q; Does the function call arguments have to be padded?

Yes, it has to do with this function.
I think because the password-field is empty when you start.
As the app works, I did not investigate further.

How long did it take you to kick this out?

approx 1 hour, after drinking my first coffee
Mark

[sunburnt]

GuestToo; How far back a version of Puppy doesn't have Bash?

MU (or GuestToo);
In looking at "env" it looked like it is what I was refering to, system wide global variables.
I was testing it & env made a new variable with a value, but a second Xterm wouldn't show it.

So if I make new variables in /etc/profile, everything can use them.
Export only works downward, there's no "global" command to share values.
So apps., scripts, etc. can't make new global variables that eveything can use?
You'd think there'd be a repository for global variables (a super shell?), not just trickle down.

So therefore Linux, Bash, etc. use files to pass values globally.
Making for alot of HD activity & is very slow compared to variables in memory.

[MU]

A "global" variable will not help us.

The table is generated by reading a file, that uses such code:

echo "column1" "column2"

Using this method, the columns are seperated by a space.
Or using my first suggestion,:
`getpw`

Here the function getpw (the old one) reads /etc/pw, and adds <item> in the beginning of each line, and </item> in the end.
Then this is "echoed".
But this method seems to work only, before the final dialog is created, you can not use it to alter a already visible dialog.
That is, why I dropped this method later.

Apart from these practical limitations, using environment-variables is good, of course.
But also those can be altered only in a subshell as far as I know.
Mark

[sunburnt]

Mark; The Q was more generic than it applying to this, though it relates.
The real focus was that variables only export down to sub processes.
There's no persistant global variables that are useful to any process at any time.
An app. made variable, it's closed & the variable's still readable by any processes, new, parent, etc.
Hense a "Super shell" or daemon service that provides truly global variables.

But I'm off our current track as it were...

I had a problem getting the SAVE file Size addon to work, but amazingly I fixed it!

Many thanks for the help & more so for this method of making GTKdialog work!

[MU]

KDE or Gnome use another method, a daemon to exchange messages between programs.
Their daemons will be replaced in future by the "dbus" daemon, that will be the new standard so that there are no longer different methods.
KDE 4beta uses it, XFCE uses it.
I had no closer look yet, but it looks quite promising.

Imagine it like this:
the daemon is a program running in background, listening on a port.
If a program sends a message in a certain protocol, it is stored in memory, and can be requested by other programs.
As the daemon is a backgroundprocess, it rsides in memory, so no disk-activity is required.

I once tried to make a extremely simplified method of doing such thing, using a pipe instead of ports:
http://www.murga.org/~puppy/viewtopic.php?t=8086

Mark

[sunburnt]

I saw Linux's mkfifo but I haven't look at it, a FIFO is typicaly for I/O.
But it could be used for any asynchronus communication or data passing.
The man. page didn't say how many levels total, presumably there's a limit.
This certainly has the capability (actually it's overkill) for global variables.
The trouble is most all apps. don't use it of course (need consistancy).
A suitable daemon could be written with almost anything, Bash included.
But only software written in the future & rewritten apps. would use it.

P.S.
I'm trying to find a way to accurately tell Puppy1 from Puppy2, I think Barry told me a way.

Also, any quick idea of how to right justify the text in the entry box?

[MU]

justify right: don't know.

Puppyversion:
cat /etc/puppyversion

Mark

[sunburnt]

Thanks Mark; That's what I was using, but the contense vary's with the version.

Barry talked about only Puppy2 having the file: /etc/rc.d/PUPSTATE, easy way to check.