<div dir="ltr">Thank you, Michael!  In fact, it appears as though Slurm is storing the entire commandline as a single "word":<br><font face="monospace">(! 1111)-> sacct -j 2871474 -o "SubmitLine%-100"<br>SubmitLine<br>----------------------------------------------------------------------------------------------------<br>sbatch --export=NONE --wrap=uname   -a --exclusive<br></font><br>So, its storing properly, now I need to see if I can figure out how to preserve/add the quotes on the way out of the DB...<div><br>David</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 4, 2022 at 11:15 AM Michael Jennings <<a href="mailto:mej@lanl.gov">mej@lanl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 04 May 2022, at 10:00:57 (-0700),<br>
David Henkemeyer wrote:<br>
<br>
>I am seeing what I think might be a bug with sacct.  When I do the<br>
>following:<br>
><br>
><br>
>*> sbatch --export=NONE --wrap='uname -a' --exclusive*<br>
>*Submitted batch job 2869585*<br>
><br>
>Then, I ask sacct for the SubmitLine, as such:<br>
><br>
><br>
><br>
><br>
>*> sacct -j 2869586 -o<br>
>"SubmitLine%-70"SubmitLine----------------------------------------------------------------------sbatch<br>
>--export=NONE --wrap=uname -a --exclusive*<br>
><br>
>As you can see, the quotes around 'uname -a' are gone.  Hence, that submit<br>
>line is not a valid sbatch commandline:<br>
><br>
><br>
>*> sbatch --export=NONE --wrap=uname -a --exclusivesbatch: error: Batch job<br>
>submission failed: Invalid job array specification*<br>
><br>
>Like I said, I suspect this is a bug with sacct.  But I want to make sure.<br>
>Can I somehow "peek" inside the accounting DB to see if the quotes are<br>
>there?<br>
><br>
>Perhaps there is an interaction with my bash shell, that's stripping the<br>
>quotes?  This seems unlikely to me.<br>
<br>
It's not actually unlikely; that's exactly what's happening.  Check<br>
out the BASH man page section on EXPANSION and look for the term<br>
"quote removal."  It's part of shells' normal operations. :-)<br>
<br>
The real question is in how the command is being stored; are you<br>
seeing 4 words or 5?  Shells like BASH internally track token sets in<br>
terms of "words," and those words can have embedded spaces.  But<br>
embedded spaces and word-separation spaces are indistinguishable<br>
without additional metadata.<br>
<br>
In other words, what you're really asking are two questions:<br>
  - Does the accounting DB store the submit line in a way that<br>
    preserves embedded spaces in arguments?<br>
  - If so, can that value be retrieved in a way that quotes those<br>
    arguments with embedded spaces (possibly by quoting *all*<br>
    arguments) in a way that can be reused as shell input?<br>
<br>
We can see this in action with the following example using BASH's<br>
support for arrays.  Just like with `$*` vs. `$@`, array expansion<br>
unquoted or inside double-quotes expands to a single word with<br>
elements separated by the first character of `$IFS` (space by default)<br>
when `$*` or `${ARRAYNAME[*]}` is used but to individual separate<br>
words instead when `$@` or `${ARRAYNAME[@]}` is used.  However, it's<br>
impossible to see the difference between embedded single spaces inside<br>
a word/element and the single spaces BASH puts between them when<br>
they're displayed:<br>
<br>
   $ (declare -ax TESTME=( 1 2 '3 4 5' 6 7 8 ) ; echo ${TESTME[*]} ; echo "${TESTME[@]}" ; declare -p TESTME)<br>
   1 2 3 4 5 6 7 8<br>
   1 2 3 4 5 6 7 8<br>
   declare -ax TESTME=([0]="1" [1]="2" [2]="3 4 5" [3]="6" [4]="7" [5]="8")<br>
<br>
Notice that the 1st 2 lines look identical to one another, even though<br>
internally they're not.  As you can see in the final line, there are<br>
still spaces in the 3rd array element (`[2]="3 4 5"`).<br>
<br>
The distinction becomes clearer if more than one space at a time is<br>
embedded into the 3rd element, like so:<br>
<br>
   $ (declare -ax TESTME=( 1 2 '3    4    5' 6 7 8 ) ; echo ${TESTME[*]} ; echo "${TESTME[@]}" ; declare -p TESTME)<br>
   1 2 3 4 5 6 7 8<br>
   1 2 3    4    5 6 7 8<br>
   declare -ax TESTME=([0]="1" [1]="2" [2]="3    4    5" [3]="6" [4]="7" [5]="8")<br>
<br>
So if you want to find the answers to the above questions (at least<br>
the 1st one), pass 'uname    -a' instead of 'uname -a' and see what<br>
you get back from your `sacct` query! :-)<br>
<br>
HTH,<br>
Michael<br>
<br>
--<br>
Michael E. Jennings <<a href="mailto:mej@lanl.gov" target="_blank">mej@lanl.gov</a>> - [PGPH: he/him/his/Mr]  --  <a href="http://hpc.lanl.gov" rel="noreferrer" target="_blank">hpc.lanl.gov</a><br>
HPC Systems Engineer   --   Platforms Team   --  HPC Systems Group (HPC-SYS)<br>
Strategic Computing Complex, Bldg. 03-2327, Rm. 2341    W: +1 (505) 606-0605<br>
Los Alamos National Laboratory,  P.O. Box 1663,  Los Alamos, NM   87545-0001<br>
<br>
</blockquote></div>