If the basename of the file has spaces in it, validation/lemmatisation of an invalid file never returns errors

[giordano]

Describe the problem

If an ATF file has spaces in its basename, running validation or lemmatisation on it never returns errors. This is likely a server-side issue, but we should be able to mitigate it on our side.

To Reproduce

Create an ATF with this content:

&X001001 = JCS 48, 089
#project: cams/gkab
#atf: lang akk-x-stdbab
#atf: use unicode
#atf: use math
@tablet
@obverse

1.  [MU] 1.03-KAM {iti}AB GE₆ U₄ 2-KAM
#lem: šatti[year]N; n; Ṭebetu[1]MN; mūša[at night]AV; ūm[day]N; n

2.  [{m}]{d}60--EN-šu₂-nu a-lid
#lem: ūmišu[day]N; Šamaš[1]DN

$ single ruling
# I've added various things for test purposes

#note: Note to line.

4.  <30> <(ina)> 12 GU U₄-ME-šu₂ GID₂-MEŠ{{ir-ri-ku}}
#lem: Sin[1]DN; ina[at]PRP; n; Gula[1]'CN; ūmūšu[day]N; +arāku[be(come) long]V$irrikū; +arāku[be(come) long]V$irrikū +.+. . 

5.  [GU₄].U₄ ina MAŠ₂ GENNA ina MIN<(MAŠ₂)>
#lem: Šihṭu[Mercury]CN; ina[in]PRP; Suhurmašu[Goatfish]CN +.+. . ; Kayyamanu[Saturn]CN; ina[in]PRP; Suhurmašu[Goatfish]CN

6.  [AN] ina ALLA <<ALLA>>
#lem: Ṣalbatanu[Mars]CN; ina[in]PRP; Alluttu[Crab]CN +.+. . 

7.    $BI x X |DU.DU| |GA₂×AN| |DU&DU| |LAGAB&LAGAB| DU@g GAN₂@t 4(BAN₂)@v
#lem: u; u; X; X; X; X; X; X; X; n

$ (a loose dollar line)

@reverse
$ reverse blank

@translation parallel en project
@obverse
1.  Year 63, Ṭebetu (Month X), night of day 2:^1^

@note ^1^ A note to the translation.

2.  Anu-belšunu was born.
3.  That day, the Sun was 9;30˚ in the Goat.
4.  The Moon was 12˚ in the Bucket: his days will be long.
5.  Jupiter was at the head of the Scorpion: someone will take the prince's hand.
6.  [The child] was born in the Bucket in the region of Venus: he will have sons.
7.  Mercury was in the Goat; Saturn was in the Goat;

and filename filename with spaces.atf. Run validation: the "Validation successful" pop up is always shown, even though there are errors.

Expected behavior

Get the "Validation identified errors. See log for details" pop up

Additional context

The symptoms are similar to #89. The cause may be the same or similar (maybe get_validation_errors is similarly not able to correctly parse the errors), but we need a reproducer for that one to confirm.

[ageorgou]

To illustrate, here is a sample log of a file named with spaces.atf:

[nisaba] info: Request 2rwE3x is done.
[nisaba] info: request.log
[nisaba] info: oracc-exec.sh[2]: 2rwE3x /tmp/datayJaljQ atf cams/gkab 00atf/with spaces.atf
oracc-exec.plx[v001]: 2rwE3x /tmp/datayJaljQ atf cams/gkab 00atf/with spaces.atf
oracc_exec: pwd=/home/oracc/tmp/sop/2rwE3x
xsystem /home/oracc/sbin/osc-create.sh 2rwE3x cams/gkab
tempdir=/home/oracc/tmp/sop/2rwE3x; projdir=/home/oracc/cams/gkab
create_project cams/gkab
chmod: cannot access 'cams/gkab': No such file or directory
/home/oracc/sbin/osc-create.sh: line 8: cd: cams/gkab: No such file or directory
/home/oracc/tmp/sop/2rwE3x
ls: cannot access 'cams/gkab/01bld': No such file or directory
cams/gkab/01bld is not a link ... autofixing ...
cbd after removing link dirs
ls: cannot access '02www/cbd': No such file or directory
xsystem unzip /tmp/datayJaljQ
Archive:  /tmp/datayJaljQ
  inflating: 00atf/with spaces.atf   
xsystem /home/oracc/bin/ox -l /home/oracc/tmp/sop/2rwE3x/oracc.log -cvmD 00atf/with
xsystem zip -j /home/oracc/tmp/sop/2rwE3x/response.zip /home/oracc/tmp/sop/2rwE3x/request.log /home/oracc/tmp/sop/2rwE3x/oracc.log
  adding: request.log
[nisaba] info: oracc.log
[nisaba] info: 
[nisaba] info: ATF validation returned no errors.

The oracc.log file is empty, which is how we identify successful validation. In the case of lemmatisation, the file only has one line with part of the file name, until the first space (normally, it would have the full file name). We still identify that as no errors, which does have to do with our parsing, but I suspect that line is malformed and not intentional.