[MINGW64] [gettext] ': not a valid identifierline 89: export: `dashless

[bit2shift]

For some obscure reason, git submodule outputs:

': not a valid identifierline 89: export: `dashless

from the mingw64 shell, but not from the mingw32 and msys shells.
It occurs on all repos, even those without submodules.

which git returns /usr/bin/git on all the 3 shells.
which perl returns /usr/bin/perl on all the 3 shells.

I've been unsuccessful at finding the root cause of this glitch. It's driving me nuts.

EDIT: a workaround for the moment is available in #735 (comment).

[mati865]

For me it happens in both MINGW32 and MINGW64 shell.

WORKAROUND: Downgrade git to 2.9.1.

[yukoff]

@Alexpux, it turned out #741 doesn't resolve the issue actually - it was a coincident I hadn't mingw-w64-x86_64-gettext/mingw-w64-i686-gettext installed at the time of testing (and the problem seem to come from these two), so despite that added patches didn't seems to do something with the problem itself (at least not at the first sight) I thought it was was fixed somehow ;)

So #741 is just an update of the git version.

[bit2shift]

The problem with removing mingw-w64-x86_64-gettext is breaking a lot of other packages that depend on it, even indirectly eg. mingw-w64-x86_64-gcc or mingw-w64-x86_64-cmake.

[bit2shift]

Found the culprit: /mingw64/bin/envsubst.exe

EDIT: Made a little shim redirecting to /usr/bin/envsubst.exe and this is what I've caught from git submodule:

--variables usage: $dashless $USAGE
usage: $dashless $USAGE

In the end, it's a bug in mingw64's envsubst

[bit2shift]

@Alexpux please reopen this.

[yukoff]

@bit2shift I didn't mean removing of mingw-w64-x86_64-gettext is a solution, it was done so just for illustration purposes ;)

[DragoonX6]

This seems to break(ish) git rebase and rebase interactive.
It seems to work fine at a glance, but I don't know what further implications it has.
For now I work around this issue by reverting to git 2.9.
Here is the output I get when running git rebase -i:

': not a valid identifierline 96: export: `shortrevisions
': not a valid identifierline 96: export: `shortonto
': not a valid identifierline 96: export: `todocount
': not a valid identifierline 96: export: `shortrevisions
': not a valid identifierline 96: export: `shortonto
': not a valid identifierline 89: export: `new_count

I tried fiddling around with the git scripts a bit, but I don't know how to debug it.

[bit2shift]

@DragoonX6 did you remove|disable /mingw64/bin/envsubst.exe?

[DragoonX6]

I did not touch it.

$ envsubst -V
envsubst.exe (GNU gettext-runtime) 0.19.7
Copyright (C) 2003-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

[bit2shift]

@DragoonX6 so you completely disregarded my comment from 6 days ago about /mingw64/bin/envsubst.exe

[DragoonX6]

Oh, my bad, I missed that. Is your shim simply an override added to the path?

[bit2shift]

It was just to see what arguments were being passed through.
You can instead rename /mingw64/bin/envsubst.exe to something else and then install MSYS2's gettext (pacman -S gettext).
After that, running which envsubst should say /usr/bin/envsubst.

[DragoonX6]

Alright that works as a workaround for now.

[chhe]

@bit2shift Thanks for the workaround. I can confirm that it works. Although I have no idea what it might break.

[pmat-fr]

Any update on this one? Did a pacman -Syu today and the issue is still there, at least on mingw64. I can also confirm the workaround seem to do the trick.

[raxetul]

Issue exists still.

[madscientist42]

Issue exists with mingw32 variant when you install 32-bit version of the MSYS2 toolset as well.

There seems to be several problems lurking in everything right at the moment. If you do a pacman -Syu, you get zapped by this and more.

[projectgus]

I've figured out what's happening, although I don't have a fix yet:

git's shell script library includes gettext.sh and then uses the eval_gettext shell function defined there.

Specifically, git-sh-setup calls $(eval_gettext "usage: \$dashless \$USAGE"). The eval_gettext function evaluates (at /mingw32/bin/gettext.sh:88) this line:

gettext "$1" | (export PATH `envsubst --variables "$1"`; envsubst "$1")

This is the specific line which creates the "export" error you see in the stderr output.

The specific difference between /mingw32/bin/envsubst.exe and /usr/bin/envsubst.exe output is:

$ export ONE=1
$ export TWO=2
$ /mingw32/bin/envsubst.exe -v 'test $ONE $TWO'
ONE
TWO

$ /usr/bin/envsubst.exe -v 'test $ONE $TWO'
ONE
TWO

OK, that all looks OK. But...

$ /usr/bin/envsubst.exe -v 'test $ONE $TWO' | hexdump -C
00000000  4f 4e 45 0a 54 57 4f 0a                           |ONE.TWO.|
00000008
$ /mingw32/bin/envsubst.exe -v 'test $ONE $TWO' | hexdump -C
00000000  4f 4e 45 0d 0a 54 57 4f  0d 0a                    |ONE..TWO..|
0000000a

mingw32's envsubst uses CRLF line endings not LF. The export command in sh can ignore LF in the argument list but fails when it sees CR (I think it's literally trying to evaluate <CR>dashless).

I can think of three possible approaches to fix this:

• Make MSYS's sh ignore CRs (either in export commands, or in all input tokens...)
• Change the line termination of mingw32's envsubst.exe output.
• Make mingw32 gettext.sh strip CRs from envsubst output before passing to sh.

I don't know enough about MSYS2 internals to know which of these (if any) is a good idea.

[mati865]

@projectgus great research!

Pinging @mingwandroid.

[bit2shift]

@projectgus you could've​ saved yourself a considerable amount of time had you read all the comments and proceeded immediately to test the output of both envsubst.

[projectgus]

I did read those, and I ran envsubst a few times at first with different input (I wouldn't have had a clue where to start without all the good detective work already done in this thread). But I couldn't see what the difference between the two envsubst calls was until I worked backwards and found the eval_gettext shell function, which is when the penny dropped. Apologies if my comment was telling you things you already knew.

[projectgus]

@mingwandroid If you have any suggestions of where/how to fix this one, I'm happy to try and come up with a PR as well if this is helpful.

[MaulingMonkey]

bit2shift's workaround left me with a broken git that couldn't clone repositories unfortunately, reporting bad object errors whenever I tried to do so.

A workaround that is working for me, however, is patching gettest.sh to invoke /bin/envsubst instead of envsubst - thanks to SpaceManiac in #rust for the suggestion!

[bit2shift]

@MaulingMonkey you must be using some weird MSYS2 configuration (eg. modifications to $PATH), because you're the only one with that problem.
Check your $PATH on all 3 MSYS2 consoles (MINGW32, MINGW64 and MSYS) to make sure both /bin and /usr/bin are present.

[bit2shift]

@MaulingMonkey also make sure you're not being affected by #30 (hint: rust).

[SpaceManiac]

"both /bin and /usr/bin" being present is useless, the two directories are the same (msys's path mapping maps /bin to be equivalent to /usr/bin). Any value of $PATH where /mingw64/bin precedes /usr/bin, as it should, will have the problem where the wrong envsubst is invoked by /mingw64/bin/gettext.sh. The problem has nothing to do with Rust and manifests on any use of git submodules or git stash.

[bit2shift]

Well, I can't reproduce the problem both of you are having.
It's funny, none of the people who upvoted, and tested my workaround with success, seem to be using rust.
Yet, both of you, @MaulingMonkey and @SpaceManiac, who happen to use rust, are the ones reporting a problem with it.
I'd look into it if I were you.

[MaulingMonkey]

I ran into trouble before even firing up cargo RE: #30. That said, it looks like my compounding failures were from trying to use msys's git with a network share CWD, not your workaround - sorry!

$ mkdir /i/temp
$ cd /i/temp
$ git clone https://github.com/octocat/Spoon-Knife.git
Cloning into 'Spoon-Knife'...
remote: Counting objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
error: failed to read delta-pack base object 0350da31ba1fff7f40d7b57a533381722c0f9fc7
fatal: unpack-objects failed

$ mkdir /c/temp
$ cd /c/temp
$ git clone https://github.com/octocat/Spoon-Knife.git
Cloning into 'Spoon-Knife'...
remote: Counting objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
Unpacking objects: 100% (16/16), done.

Edit: And my fairly vanilla install process for posterity:

• Via http://www.msys2.org/ I grabbed http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe and installed it.
• Let the installer launch a terminal after installation.
  • pacman -Sy pacman-mirrors
  • pacman -S git make diffutils tar mingw-w64-x86_64-python2 mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc
• Fire up a new terminal via C:\msys64\msys2_shell.cmd -mingw64
  • git clone ... things and watch it break on network shares.

[avih]

FWIW, I currently use this workaround which works fine for invoking git from the shell: Add to ~/.bashrc :

alias git="PATH=/usr/bin git"

This excludes the MINGW32/64 paths (and everything not in MSYS2 main path) when running git, and so it doesn't end up running a non-MSYS envsubst.

It's possible to use different variants of this hack, and it might not work for shell scripts which do git stuff, but for the shell this is enough.

[brian-lamb-software-engineer]

I can say that the renaming of envsubset.exe and installing gettext solved it for me, i was getting error ': not a valid identifierline 88: export: ``dashless (single backtick before dashless) every time i ran git stash, and probably saw it other times.

I really dont think it showed up until i added .bashrc or .bashprofile modifications, so it may be something that belongs in other distros made its way to the configs or something, not really sure there. I dont have time to debug it much. However i really hope that renaming envsubst.exe doesnt come back to bite me.

[avih]

FWIW, I currently use this workaround which works fine for invoking git from the shell: Add to ~/.bashrc ...

I now use a better solution which also works with shell scripts which use git. I created /mingw64/bin/git shell script with the following content:

#!/bin/sh
PATH=/bin git "$@"

which does the same thing, but more robust (/bin is the same as /usr/bin in MSYS2 environments, so it's just shorter, but the point is that now it's a script so it works also when other shell scripts invoke git - which otherwise are oblivious to the previous alias solution).

This also works with redirections, e.g. cat my.patch | git am (the alias solution also works with redirections).

[Optiligence]

It could be packaged this way for now as an official workaround. Can you prepare a PR?

[avih]

Can you prepare a PR?

Assuming this was meant for me, I'd prefer someone else more versed in MSYS2 setup would do that. It should take few secs if you know what you're doing, but quite a bit more if I did that because I haven't PR'ed MSYS2 packages in the past.

[OldWolf2]

Can I suggest that the change to mingw64/bin/gettext.sh be made the official solution? It's kinda ridiculous that an out-of-the-box installation of MSYS2 64-bit has a problem like this.

[jpaugh]

Having this issue on git rebase with git version 2.17.0. I do not have this problem on "Git For Windows" version 2.16.0.windows.2. The MinGW environment in Git For Windows is heavily tweaked, so that last fact might not be indicative of anything. Reinstalling gettext did the trick, but projectgus gets to the heart of the real issue. Someone with the right knowledge of MSYS internals could probably fix this easily.

[wolf99]

Happening on git stash with git 2.17.0.

[stahta01]

I am trying to do one of the possible ways suggested to fix the problem.
1st try at fixing failed; going to try once more.

MinGW Patch

Change the line termination of mingw32's envsubst.exe output.

[tofutim]

git 2.16.2 here

timuy@DESKTOP-QINEVD6 MINGW64 ~/Projects/sgminer-gm
$ git submodule init
': not a valid identifierline 88: export: `dashless
Submodule 'jansson' (https://github.com/akheron/jansson.git) registered for path 'submodules/jansson'

timuy@DESKTOP-QINEVD6 MINGW64 ~/Projects/sgminer-gm
$ git submodule update
': not a valid identifierline 88: export: `dashless
Cloning into '/home/timuy/Projects/sgminer-gm/submodules/jansson'...
': not a valid identifierline 88: export: `sha1
': not a valid identifierline 88: export: `displaypath
Submodule path '': checked out 'bc743ad2d9807b00e7dc0b5d3524d0a47a14f3c3'

$ envsubst -V
envsubst.exe (GNU gettext-runtime) 0.19.8.1
Copyright (C) 2003-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

[Alexpux]

@tofutim do you update all packages to latest?

[tofutim]

Let me try that, though I found the bashrc trick did solve the problem.

[AlanGrunwald]

I'm seeing this issue on a 64-bit cygwin installation with stash. Using version 2.21.0

PATH=/usr/bin git stash list completes without warnings,