Cannot run `git submodule init` on Cygwin from script with strict error checking

I'm running git 2.28.0 on Cygwin. I have a script with:

set -aeu

at the beginning (as all scripts should have). In the script I'm trying to run:

git submodule init

When running via "bash -x script.sh", I get:

+ git submodule init
++ basename /usr/libexec/git-core/git-submodule
++ sed -e 's/-/ /'
+ dashless='git submodule'
+ USAGE='[--quiet] [--cached]
   or: git submodule [--quiet] add [-b <branch>] [-f|--force] [--name
<name>] [--reference <repository>] [--] <repository> [<path>]
   or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] init [--] [<path>...]
   or: git submodule [--quiet] deinit [-f|--force] (--all| [--] <path>...)
   or: git submodule [--quiet] update [--init] [--remote]
[-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase]
[--[no-]recommend-shallow] [--reference <repository>] [--recursive]
[--[no-]single-branch] [--] [<path>...]
   or: git submodule [--quiet] set-branch (--default|--branch
<branch>) [--] <path>
   or: git submodule [--quiet] set-url [--] <path> <newurl>
   or: git submodule [--quiet] summary [--cached|--files]
[--summary-limit <n>] [commit] [--] [<path>...]
   or: git submodule [--quiet] foreach [--recursive] <command>
   or: git submodule [--quiet] sync [--recursive] [--] [<path>...]
   or: git submodule [--quiet] absorbgitdirs [--] [<path>...]'
+ OPTIONS_SPEC=
+ SUBDIRECTORY_OK=Yes
+ . git-sh-setup
++ unset CDPATH
++ IFS='
'
+++ git --exec-path
++ . /usr/libexec/git-core/git-sh-i18n
+++ TEXTDOMAIN=git
+++ export TEXTDOMAIN
/usr/libexec/git-core/git-sh-i18n: line 10: GIT_TEXTDOMAINDIR: unbound variable

(TL;DR: This basically boils down to GIT_TEXTDOMAINDIR being unbound, i.e. uninitialized/non-existant.)

When I exported GIT_TEXTDOMAINDIR with bogus value from my script before calling "git submodule init":

export GIT_TEXTDOMAINDIR=/bogus/value

I got (only error shown):

/usr/libexec/git-core/git-sh-i18n: line 20: GIT_TEST_GETTEXT_POISON: unbound variable

I set it to `false`, restarted and then got:

/usr/libexec/git-core/git-sh-i18n: line 28:
GIT_INTERNAL_GETTEXT_TEST_FALLBACKS: unbound variable

I set it to empty value, restarted and then got:

/usr/libexec/git-core/git-sh-setup: line 91: LONG_USAGE: unbound variable

This is when I gave up.

Same script run with git 2.21.0 on Linux has no problems, but I haven't compare differences between two versions, so I don't know why it stopped working.

Hi Jędrzej,

On Fri, 11 Sep 2020 at 09:20, Jędrzej Dudkiewicz wrote:

I think there's something odd about the way you're calling `git submodule init`: it should normally be a separate execution that wouldn't inherit the `-aeu` or `-x` settings from the parent Bash process. It looks like perhaps you're `source`ing or dotting in the `git-submodule` script? Whatever it is, I think the issue is down to the way you're using `git submodule`, rather than a problem with Git or the Cygwin Git build.

I did just try to reproduce the problem using Git v2.28.0-1 on Cygwin, and wasn't able to:

``` $ cat test.sh set -aeu rm -rf testdir mkdir testdir cd testdir git init git submodule init

$ bash -x test.sh
+ set -aeu
+ rm -rf testdir
+ mkdir testdir
+ cd testdir
+ git init
Initialized empty Git repository in /home/adam/testdir/.git/
+ git submodule init

$ echo $? 0 ```

HTH

Adam

On Fri, Sep 11, 2020 at 1:30 PM Adam Dinwoodie <adam@dinwoodie.org> wrote:

Sorry for not including the test script. Here it is:

----8<----8<----8<-- CUT HERE--8<----8<----8<----8<---- #!/bin/bash

set -aeu

export SHELLOPTS

set -x

git submodule init ----8<----8<----8<-- CUT HERE--8<----8<----8<----8<----

I use "export SHELLOPTS" because I want these flags to be effective in subshells. As a workaround I'm currently calling "set +u" before each execution of "git submodule init" and my script works, but it isn't very nice and IMHO shouldn't be required (i.e. it would be extremely nice if someone fixed it).

On Fri, Sep 11, 2020 at 01:46:43PM +0200, Jędrzej Dudkiewicz wrote:

You don't need 'export SHELLOPTS' to make those flags effective in _subshells_:

  $ cat test.sh 
  #!/bin/sh
  
  set -ex
  
  (
          false
          echo "after false"
  )
  exit 0
  $ ./test.sh
  + false
  1
  $ echo $?
  1

What 'export SHELLOPTS' does is make those flags effective even in separate shell scripts executed by your script, but, as you just found out, that's not really a good idea, because those scripts are beyond your control.

The right workaround would be to apply those shell options only to your script, i.e. to remove that 'export SHELLOPTS'.

Having said that, unlike 'git submodule', 'git-sh-setup' is meant to be dot-sourced into users' shell scripts, and, therefore, should work with the shell options set in users' scripts, including even 'set -u'.

The patch below may or may not make it work; it's well over two years old, and I haven't tested it at all since then.

  ---  >8  ---

Subject: [PATCH] git-sh-setup, git-sh-i18n: make our shell libraries work with
 'set -u'

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 git-sh-i18n.sh  |  6 +++---
 git-sh-setup.sh | 14 +++++++-------
 2 files changed, 10 insertions(+), 10 deletions(-)

SZEDER Gábor <szeder.dev@gmail.com> writes:

Is it and should it?

git-sh-setup was meant to be an implementation detail for our own scripts and we know don't use "-u -e". We never cared about backward compatibility for such use by end-users when we made any update to the git-sh-setup scriptlet. We freely changed existing features and squatted on good names for variables and functions we used in it, because it is designed as a private helper library.

Having said that, we do protect from end-user misconfiguration like exporting CDPATH, and protecting ourselves from exporting SHELLOPTS is not something I would oppose.

Thanks.

On Fri, Sep 11, 2020 at 12:07:51PM -0700, Junio C Hamano wrote:

It has a manpage that it installed by 'make install-doc', and 'man git' advertises it, so I use it in most of my git-foo shell scripts, e.g. for 'require_clean_work_tree'.