BNW/sourcecodes, branch main

Make all shell scripts executable.

2026-08-24T19:33:26+00:00

The code needs the shell scripts to be executable, otherwise the code will raise an error (Permission Denied).

Use new `runTerminalCommand()` wrapper to run commands.

2026-08-24T19:26:00+00:00

Add a wrapper around `proc_open(...)` to use for terminal commands.

2026-08-24T18:18:34+00:00

Bugfix: Fix path.

2026-08-18T18:23:15+00:00

Bugfix: Check that key exists before use.

2026-08-18T15:05:32+00:00

Bugfix: Move variable closer to usage.

2026-08-18T15:03:21+00:00

Initialise the `$TextFile` variable within the handling of the "POST" request rather than in the global scope.

Fix undefined $TextinFile/$keyval in bn_after_upload_gom.php

2026-08-17T19:53:37+00:00

$TextinFile was passed to move_uploaded_file() as its $to argument, but its assignment (and the $keyval/$sid/$dir it depends on) was commented out, so $TextinFile was always null/undefined here -- an upload through this page could never succeed even on PHP 7.4, and on PHP 8.1+ it also triggers "Passing null to parameter #1 ($to)... is deprecated". $keyval was similarly used (e.g. in the hidden My_key form field) before it was ever assigned, causing an "Undefined variable" warning that could leak into an unquoted HTML attribute if display_errors is on. Unlike bn_file_load_gom.php (a fresh-upload entry point that mints a new random key), this page is only reached via a redirect from modify_structure_learning.php with an existing My_key already in the query string. Restored the commented-out block, adapted to read $keyval from $_GET (matching how the rest of this file already does it further down) instead of generating a new one, so $TextinFile is a real path before the upload block runs. Verified empirically against PHP 8.3.28: simulating an upload request now correctly reaches move_uploaded_file() with a real path and falls into the file's own pre-existing "Sorry, error uploading" handling instead of silently failing on a null argument. Reviewed by: Frederick M Muriithi

Guard arithmetic on file/shell-output-derived values against non-numeric strings

2026-08-17T19:53:21+00:00

PHP 8 throws a fatal TypeError for arithmetic (+ - * /) on a non-numeric string ("Unsupported operand types"); PHP 7.4 only warned and treated it as 0. Several files perform arithmetic directly on values parsed from intermediate state files (nnode.txt, nrows.txt, structure_input*.txt) or from `dot -Tplain` output, with no is_numeric() check — safe as long as those files are well-formed, but a crash risk if a file is missing/empty/truncated or a `dot` output line doesn't parse as expected. Affected: runtime_check.php ($node, $nrows), remove_variables.php and create_tiers_gom_part1.php ($maxplist=$node-1), mat_structure.php (matrix cell multiplication), and the four network_layout_{evd,inv}[,_2].php files ($r_index=$node+N and the dot-output-derived $cell arithmetic in the _2 variants). Fix pattern: coalesce to 0 via `is_numeric($x) ? $x : 0` before the arithmetic, matching PHP 7.4's original fallback-to-0 behavior instead of crashing. Verified empirically against PHP 8.3.28 with runtime_check.php and mat_structure.php: previously, a missing/empty source file caused TypeError: Unsupported operand types: string - int (or string * int) after the fix, the same missing-file scenario produces only the pre-existing "undefined array key" warnings (same as PHP 7.4) and the function completes and returns a value instead of crashing. Reviewed by: Frederick M Muriithi

Guard fopen() results with a false-check before fwrite/fprintf/fclose

2026-08-17T19:53:08+00:00

On PHP 7.4, calling fwrite()/fprintf()/fclose() with a false handle (a failed fopen(), e.g. from a bad path, missing directory, or permissions issue) just emits a warning and no-ops. On PHP 8.0+, these functions require a resource argument and throw an uncaught TypeError instead, turning what used to be a silent degradation into a fatal crash of the whole request. This patch wraps every fopen()-then-write call site in the codebase (18 files) with an `if ($handle !== false) { ... }` check, matching the existing pattern used elsewhere in the codebase. Where the same $fpvar handle is threaded through shared helper functions (enter_ban_list/banlist/whitelist, duplicated across remove_variables_processing.php, remove_variables_processing_default.php, modify_structure_learning.php and tier_description_processing_gom.php), the guard was added inside those functions too for consistency, even though the call sites are currently dead/commented-out in three of the four files — so the same landmine doesn't reappear if that code is ever re-enabled. Verified empirically against PHP 8.3.28: fopen() on an unwritable path followed by fwrite() on the resulting `false` throws TypeError: fwrite(): Argument #1 ($stream) must be of type resource, false given without the guard; with the guard, the call is skipped instead of crashing. The normal (successful fopen) path was also re-run through mat_structure.php's structure_change() and still produces identical output to before the change. Reviewed by: Frederick M Muriithi

Guard valid_keyval()/valid_input() against null input (PHP 8.1 deprecation)

2026-08-17T19:52:48+00:00

These two functions are the single most common entry point in the codebase — ~30+ files call them as valid_keyval($_GET["My_key"]) or valid_input($_POST[...]) with no isset() guard at the call site. When the key is absent, PHP passes null straight into trim(), which is a non-nullable string parameter. As of PHP 8.1 this triggers a "Passing null to parameter #1 ($string) ... is deprecated" notice on every one of those call sites, on every request missing the param. Coalescing to '' inside the two functions themselves fixes this once, for every caller, instead of patching every call site individually. Verified empirically against PHP 8.3.28: valid_keyval(null) / valid_input(null) no longer emit the trim() deprecation notice and still return '' as before (same effective behavior as PHP 7.4). Reviewed by: Frederick M Muriithi