iB::Topic::MyDSL info parser

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » Non-DSL Topics » Programming and Scripting » MyDSL info parser

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (16) </ ... 10 11 12 13 14 [15] 16 >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: MyDSL info parser, prototype

< Next Oldest | Next Newest >

lucky13

Group: Members
Posts: 1478
Joined: Feb. 2007

Posted: April 30 2008,16:47

It executes one command. You can always run
aterm -e somescript

where somescript contains the commands you want executed.

--------------
"It felt kind of like having a pitbull terrier on my rear end."
-- meo (copyright(c)2008, all rights reserved)

^thehatsrule^ Offline

Group: Members
Posts: 3275
Joined: July 2006

Posted: April 30 2008,17:36

You could always pass them to the shell to execute, i.e. aterm -e sh -c "echo 1 && echo 2; echo $? > retval.txt; read"

I don't think you can use the return code from os.execute since it would get it from aterm - not the commands you specified.
It's not elegant, but it's an alternative that I think would work for now :P

afaik most(all?) of the mirrors do regular rsync updates to ibiblio... so it should be OK.

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: April 30 2008,17:52

Quote

You can always run
aterm -e somescript

I was thinking about that, although I need to decide the best way to create the script (probably use the existing tempfile). I don't really want it to be a separate script file.

Quote

You could always pass them to the shell to execute, i.e. aterm -e sh -c "echo 1 && echo 2; echo $? > retval.txt; read"

That looks like a variation of writing to a temp file from lua and then executing the temp file...except using sh instead of lua. Is that right?

Quote

I don't think you can use the return code from os.execute since it would get it from aterm - not the commands you specified.

Yeah, I ran into that issue when trying to get the return value from mydsl-load, which was causing an error dialog even on success. I plan to do checks on the files themselves, after the os.execute has run, in order to give the user a visual clue of the success of the download/installation. I just haven't bothered with it yet.

Quote

afaik most(all?) of the mirrors do regular rsync updates to ibiblio... so it should be OK.

I was hoping that would be the case. Since the script now uses /opt/.dslrc for the "download only" fuction, it might make sense to use that mirror for the database as well.

Thanks for the input guys. It's always appreciated, and usually helpful.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

^thehatsrule^ Offline

Group: Members
Posts: 3275
Joined: July 2006

Posted: April 30 2008,18:20

Quote

That looks like a variation of writing to a temp file from lua and then executing the temp file...except using sh instead of lua. Is that right?

Not quite... it does something like
1. run the first command "echo 1"
2. if the last command was successful, run the 2nd command "echo 2"
3. save the return code from the previous statement "echo 1 && echo 2" to a file called retval.txt
4. "read" does nothing - it's just to keep the window open

Quote

Did you try changing the DISPLAY variable like what I suggested in the other post? [ah, not yet] Just tested it and it seems to work under 3.x.

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: May 01 2008,03:12

I don't see why you'd want to unset the DISPLAY variable. The error dialog that mydsl-load provides is a desired behavior. The error dialog I was getting was one that was part of this script. It was not working properly, however, because of the issue you mentioned...applications running in an X terminal do not return to the shell that started the terminal.

Your idea of redirecting the output of the last command is a good one, but I'm not sure if it will work in this case. It might at least require unsetting the DISPLAY variable in order to prevent a second terminal, meaning I'd still need to have my own error dialog, which is the exact thing I'm looking to prevent. Since that function is already in place in DSL, I'd prefer to use it rather than mimic it. I'll have to run some tests. Any way I look at it, though, it seems like there will be some redundancy...either in presenting the dialog or doing the md5sum test myself.

Although, with the read command + unsetting DISPLAY, the user will be presented with the success or failure message in that term, without the need for a FLTK message or md5sum check. Interesting idea....I wish I hadn't typed all that out before realizing what you were getting at....

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

76 replies since Jan. 13 2008,15:39

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (16) </ ... 10 11 12 13 14 [15] 16 >/

Damn Small Linux Board » Non-DSL Topics » Programming and Scripting » MyDSL info parser