Skip to content
Snippets Groups Projects
Select Git revision
  • dailybuild_linux-x64
  • dailybuild_win32
  • master default protected
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

sbbs

  • Clone with SSH
  • Clone with HTTPS
  • Rob Swindell (on Windows 11)'s avatar
    Rob Swindell authored
    This solves the problem of exit() values (e.g. non-zero return codes) not
    getting propagated to callers when nest-called (e.g. via bbs.exec()).
    
    I think it was kk4qbn that pointed this out via IRC: an exit(1) call from
    prextrn.js did not stop the external program from running (as it should, for
    any non-zero exit code). This only happened when the prextrn.js called another
    JS script (e.g. via bbs.exec() or as was the case here, indirectly via "EXEC"
    @-code in the YesNoBar text.dat string (which executed yesnobar.js). This
    nested JS script invocation via sbbs_t::js_execfile() would clobber the stored
    js.scope property value (where the "exit_code" property is written).
    
    Script invoked in their own context (e.g. via js.exec()) wouldn't have this
    issue in the first place.
    c3b47aca
    History
    Name Last commit Last update