Programming and Scripting :: MyDSL info parser



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

where somescript contains the commands you want executed.
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.
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.
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
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.
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.
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....
Next Page...
original here.