bash 4.3.48(1) and repo: processing of commands halts at first semicolon
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='l$
uname output: Linux 20180329x99-a 4.13.0-38-generic #43~16.04.1-Ubuntu
SMP Wed $
Machine Type: x86_64-pc-linux-gnu
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.
Please see below reproduction steps.
Repeat-By:
Using bash 4.3.11(1)-release, installed with Ubuntu 14.04 LTS, the command
repo forall -c "pwd; git log -n 1 --format=fuller ; echo"
produces correct output: for each and every git repository encountered,
the above command outputs
1) The current directory
2) Information about the latest commit in the repository
3) A blank line
Using bash 4.3.48(1)-release, installed with Ubuntu 16.04 LTS, the command
repo forall -c "pwd; git log -n 1 --format=fuller ; echo"
produces incomplete output: for each and every git repository
encountered, the above command outputs
1) The current directory
and nothing else. (Subcommands after the semicolon do not get invoked.)
The above were all tested with the exact same versions of "repo" and "git":
repo version v1.12.37
(from https://gerrit.googlesource.com/git-repo)
repo launcher version 1.23
(from /usr/local/bin/repo)
git version 2.7.4
Python 2.7.12 (default, Dec 4 2017, 14:50:18)
[GCC 5.4.0 20160609]
Regards,
Tow
Re: bash 4.3.48(1) and repo: processing of commands halts at first semicolon
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.
