RCommand: fix csh-specific \$status in execout()/file transfer; default remote shell to bash

Second round of live testing surfaced that the login-sequence fix alone
wasn't enough: execout() -- the function every single remote command
execution goes through -- appended "; echo CMDSTAT=\$status" to check
exit status. \$status is csh/tcsh-specific; bash has no such variable
(it's simply unset there), so this silently produced an empty
"CMDSTAT=" with no digit, matching none of execout()'s success/failure
patterns and failing every remote command with "No status returned"
-- confirmed via a live standalone repro (RCommand + execout("echo
test") against a real bash connection: failed before this fix, works
correctly after). Same pattern existed in the two file-transfer sites
(shellput's dd-based upload, shellget's cat-based download). Fixed all
three using the now-correctly-tracked p_remoteBash: "\$?" for bash,
"\$status" for csh/tcsh/anything else. The downstream CMDSTAT=0/1/2
pattern matching needed no changes -- it only checks the *expanded*
numeric result, identical either way.

Also flipped RefMachine::shell()'s default from "csh" to "bash", per
explicit direction: fewer hard dependencies going forward (neither this
build machine nor niobium have tcsh installed, confirmed live), while
keeping full csh/tcsh support for any machine that sets "shell: csh" or
"shell: tcsh" explicitly in its CONFIG file. Only affects registered
remote machines (RefMachine::shell() reads a per-machine CONFIG file) --
RCommand's own constructor default and the local ("system") connection
path both still default to "csh" unchanged, since Point 1 (the local
shell) remains explicitly out of scope for now.

Known remaining gap, not fixed here: execbg() (used by Launch.C for
background job launches) also has a csh-specific pattern ("Exit*") for
detecting a background command's completion status. Lower urgency than
execout() was -- execbg()'s own documented design already treats
background-job status as best-effort/not fully reliable even for csh,
so a bash mismatch there degrades gracefully (falls through to "assume
success" on seeing the prompt) rather than hard-failing the way
execout() did. Worth a follow-up, not blocking.

Verified end-to-end against a real bash SSH connection (temporary local
key-based auth, removed after testing): login, command execution, and
the original csh path and local "system" path all confirmed still
working with no regressions.

Author: andy

src/comm/rcommand/RCommand.C

@@ -2737,7 +2737,13 @@ bool RCommand::execout(const string& command, string& output,
   bool status = false;
   string cmdstat = command;
 
-  cmdstat.append("; echo CMDSTAT=$status");
+  // $status is csh/tcsh's exit-status variable; bash/sh use $? instead --
+  // $status is simply unset in bash, so this would silently always
+  // produce an empty "CMDSTAT=" with no digit, matching none of the
+  // patterns below and failing every single remote command with "No
+  // status returned". Confirmed via a live standalone repro against a
+  // real bash remote connection.
+  cmdstat.append(p_remoteBash ? "; echo CMDSTAT=$?" : "; echo CMDSTAT=$status");
 
   if (timeout != 0)
     exp_timeout = timeout;
@@ -2806,13 +2812,20 @@ bool RCommand::execout(const string& command, string& output,
   // mpp2 so maybe this fix can be conditionalized based on the machine.
   RCommand::expMungedOutputFix();
 
-  char* line = strstr(exp_buffer, "$status\r\n");
+  // Matches whichever status-variable text was actually echoed back as
+  // part of the command's own terminal echo (see cmdstat construction
+  // above) -- "$status" (7 chars) for csh/tcsh, "$?" (2 chars) for bash.
+  const char* statusVarEcho = p_remoteBash ? "$?" : "$status";
+  int statusVarLen = p_remoteBash ? 2 : 7;
+  string nlPattern = string(statusVarEcho) + "\r\n";
+  string crPattern = string(statusVarEcho) + "\r";
+  char* line = strstr(exp_buffer, nlPattern.c_str());
 
   if (line != NULL)
-    output = line+9;
-  else if ((line = strstr(exp_buffer, "$status\r")) != NULL)
+    output = line + statusVarLen + 2;
+  else if ((line = strstr(exp_buffer, crPattern.c_str())) != NULL)
     // this fixes some weird problem that occured on a Dell Linux workstation
-    output = line+10;
+    output = line + statusVarLen + 3;
   else if (status)
     output = "";
   else
@@ -4094,7 +4107,8 @@ bool RCommand::shellput(const char** fromFiles, const string& toFile)
       sprintf(buf, "%d", nread);
       string nreadstr = buf;
 
-      cmdstat = "dd ibs=1 of=" + fullToFile + " count=" + nreadstr + "; echo CMDSTAT=$status";
+      cmdstat = "dd ibs=1 of=" + fullToFile + " count=" + nreadstr +
+                (p_remoteBash ? "; echo CMDSTAT=$?" : "; echo CMDSTAT=$status");
 
       if (!expwrite(cmdstat)) return false;
       // scan until start of file to be transferred
@@ -4270,7 +4284,8 @@ bool RCommand::shellget(const char** fromFiles, const string& toFile)
         ofstream os(fullToFile.c_str());
 
         if (os) {
-          cmd = "cat " + globbedFile + "; echo CMDSTAT=$status";
+          cmd = "cat " + globbedFile +
+                (p_remoteBash ? "; echo CMDSTAT=$?" : "; echo CMDSTAT=$status");
           if (!expwrite(cmd)) return false;
 
           // the commented out logic was failing because I found that

src/tdat/resources/RefMachine.C

@@ -292,7 +292,19 @@ string RefMachine::sourceFile(void) const
 
 string RefMachine::shell(void) const
 {
-  string shell = "csh";
+  // "bash" by default -- csh/tcsh is a real, still-supported option (set
+  // "shell: csh" or "shell: tcsh" in this machine's CONFIG file for a
+  // machine/account that genuinely needs it), just no longer assumed.
+  // Historically this defaulted to "csh" unconditionally, which meant
+  // ECCE required tcsh to be installed -- on the *local* machine running
+  // ECCE (RCommand::shellCommand()'s locShell-based -fc/-f/-i local-
+  // wrapper invocation, not yet updated to be dialect-aware -- see
+  // CLAUDE.md) and, via this exact field, on every remote machine too --
+  // even though nothing about ECCE's own job-launch mechanics actually
+  // needs csh specifically. Fewer hard dependencies, fewer places this
+  // breaks on a machine that simply doesn't have csh/tcsh installed
+  // (confirmed live: neither this build machine nor niobium do).
+  string shell = "bash";
 
   string configName = RefMachine::configFile(refname());