Re: [bug-gettext] /bin/sh calls in msginit.c on Windows

[Bruno Haible]

Hi Michele,

> The reason why a patch is needed for Windows is because I have a
> couple of warnings when running msginit.exe:
> 
> C:\Dev\test\bin>msginit.exe -i dictionary.pot -o language.po -l it_IT
> msginit.exe: subprocess C:\Dev\test/lib/gettext/user-email failed: No
> such file or directory
> msginit.exe: subprocess
> C:\Dev\test/share/gettext/projects/team-address failed: No such file
> or directory
> 
> language.po created.

OK. Let me remove these error messages then. I'll commit a changeset:

  msginit: Avoid error messages when run on mingw.

  Reported by Michele Locati <address@hidden>.

  * gettext-tools/src/msginit.c (project_id, project_id_version, get_user_email,
  language_team_address): Don't even attempt to run the shell script.

I'm not inclined to create special code for MSYS or Cygwin environments,
because that would further increase the testing effort (2 or 3 environments
to test instead of one). It's preferrable from my point of view (as tester)
if msginit's behaviour is the same in all three mingw environments.

> About WSL:
> 
> WLS is installed via the Microsoft Store, and its filesystem is saved
> at a location like this:
> 
> %LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs
> 
> Where %LOCALAPPDATA% usually is C:\Users\<username>\AppData\Local
> 
> What shouldn't be done is working on Linux files in that directory.
> 
> What's absolutely legal is to take advantage of the Windows/Linux
> interoperability.
> 
> With the wsl.exe Windows command you can run Linux commands, as well
> as opening a bash shell (which offers the very handy wslpath command).
> 
> Here's a sample cmd.exe + bash shell session:
> 
> 
> C:\Users\miche>echo %OS%
> Windows_NT
> 
> C:\Users\miche>wsl pwd
> /mnt/c/Users/miche
> 
> C:\Users\miche>wsl
> address@hidden:/mnt/c/Users/miche$ uname -a
> Linux Chronos10 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06
> 19:16:00 PST 2019 x86_64 x86_64 x
> 86_64 GNU/Linux
> address@hidden:/mnt/c/Users/miche$ cmd.exe /C echo %OS%
> Windows_NT
> address@hidden:/mnt/c/Users/miche$ wslpath -a
> wslpath: Invalid argument
> Usage:
>     -a    force result to absolute path format
>     -u    translate from a Windows path to a WSL path (default)
>     -w    translate from a WSL path to a Windows path
>     -m    translate from a WSL path to a Windows path, with '/' instead of '\'
> 
> EX: wslpath 'c:\users'
> address@hidden:/mnt/c/Users/miche$ exit
> logout
> 
> C:\Users\miche>wsl $(wslpath 'C:\\Dev\\test/lib/gettext/user-email')
> Is the following your email address?
>   m@
> Please confirm by pressing Return, or enter your email address.
> 
> m@
> 
> 
> Please remark that
> C:\\Dev\\\test/lib/gettext/user-email is the value of
> relocate (LIBDIR "/gettext/user-email");
> except that I manually doubled the backslashes.
> 
> 
> > 2. The user experience is likely unexpected and unsatisfying, because
> >    wsl.exe is really a different world than the rest of Windows.
> 
> I'm sorry I don't understand what you mean... I'd use wsl just to run
> the POSIX scripts project-id, user-email, and team-address.

By "environment" I mean:
  - The look of the WSL console may be different from the PowerShell or
    Emacs that the user is using.
  - The name of the user in the WSL world may be different than the one
    used in Windows.
  - The user maybe has not used WSL for years, thus the initial guess of the
    user-email script may be outdated and therefore surprising.
  - The language that the 'user-email' script uses to communicate with
    the user (based on the LANG environment inside WSL) can be a different
    one than in Windows.
And so on. This is a too large can of worms for this little bit of
functionality.

Bruno