Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Gopher

Members
  • Content Count

    2
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Gopher

  1. In my fiddling, I found myself wanting to replace the shell with my own. This is straight-forward enough to do; you can change the environment variable "SHELL" from "/bin/sh" to point to your own program by typing "set SHELL=<pathtoyourshell>" and then "exit" at the standard OpenOS SH prompt.

    I wanted to do this automatically, though, in an autorun script, and that proved a bit trickier. You can change the environment variable by calling os.setenv("SHELL","pathtoyourshell"), but even an autorun script has a shell already running behind it which will continue when the script ends.

    I thought of several things that seemed like they should work, such as using computer.pushSignal to send a faked ctrl+c event before exiting back to the shell, but nothing seemed to work for one reason or another. After poking the os with a stick for a while, I eventually came up with this approach that works nicely:

    local os=require("os")
    
    if os.getenv("SHELL")=="/bin/sh" then
      print("Memory initial:",computer.freeMemory())
      local term=require("term")
      os.setenv("SHELL",require("process").running())
      local oldread=term.read
      term.read=function(...) term.read=oldread return "exit" end
      return
    end
    
    This snippet checks if the shell variable is pointing to the default shell; if it is, it replaces that shell with the path to itself. Then, it backs up and overrides term.read function and exits the program. This will return control to the shell, which will immediately call your new read function. This function immediately restores the original read function, so it will only be called once, but it returns "exit" which will cause the parent shell to exit immediately. The OS will respond to this by launching a new shell, and thanks to the new SHELL env value, this will run your program again, this time without sh running behind it, holding on to memory and resources.

    I put this together to use on a custom program for robots, to let my programs access more of their limited memory, but it could also be used to good effect for any shell replacement, or contexts where you don't want users to exit your program and return to the shell.

    Note, if you do this in an autorun file, your program /will/ run whenever the disk is inserted. If you wind up with a defective autorun setup, or otherwise just need access through sh to the disk's contents, you'll have to boot the computer with the disk/hd removed and disable autorun before reinserting it. You can disable autorun by running the lua program and entering this:

    lua> filesystem.setAutorunEnabled(false)
    
    then you can insert your disk and it will appear in /mnt/ without running it's autorun script.
  2. I can confirm that at least since 1.2.3, the unbuffered config setting works exactly as advertised. The only case where updating files doesn't seem to have effect immediately is with libs, which are buffered not by the mod but by the package api. A reboot will reload all libs, or you can add this to the top of the program you're testing the lib with to force the api to reload each time:

    --discard the loaded version
    package.loaded["mylib"]=nil
    --require will now search for and reload it
    mylib=require("mylib")
    
    :edit: note that if loading the API sets up event listeners, like several of the built-in OS libraries do, then you should just reboot, as you'll end up with multiple versions of the lib actively in memory and running, which can cause all manner of undesired side-effects.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.