Chet:
Thank you for the pointers. I tried to read through the "repo" code all
morning. I don't really know Python, but what I can see is that:
1) It appears to not invoke any specific shell. It seems to fork a new
process, which would duplicate whatever shell it started with.
2) It has a "DoWork" function that manipulates stdin and stdout,
processing commands and their outputs. I did not see it trying to break
up long strings of commands.
I am debugging what appears to be a problem on our end. Using the "-x"
setting you suggested, it looks like an intermediate script on my end,
which for reasons unknown to me only runs for 4.3.48, is breaking up the
multi-command string into a single string followed by tokens that I
presume would be treated as extraneous arguments, rather than additional
commands.
I am going to investigate things further on my end; you can put this
matter on hold for now. Thank you for your help and sorry for the noise.
Tow
On 07/03/2018 09:59 AM, Chet Ramey wrote:
On 7/3/18 10:34 AM, Chet Ramey wrote:
On 7/2/18 5:58 PM, toww wrote:
Bash Version: 4.3
Patch Level: 48
Release Status: release
Description:
There seems to be a new incompatibility or incorrect string parsing in how
the Google "repo" utility interacts with the bash shell. Previously I could
invoke the "repo" command, passing to it a string to execute multiple
commands separated by semicolons (';' characters), and all commands would
execute. Now with the latest bash 4.3.38, only the first command executes,
and processing stops at the semicolon.
It would help to see the exact set of commands that repo uses to invoke the
shell, the options it passes to shell invocation. It would help more to
have a reproducer that doesn't involve `repo'.
You could also check whether repo is invoking /bin/sh instead of /bin/bash,
and, if so, whether bash is installed as /bin/sh.
