[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] /bin/sh calls in msginit.c on Windows
From: |
Bruno Haible |
Subject: |
Re: [bug-gettext] /bin/sh calls in msginit.c on Windows |
Date: |
Sun, 05 May 2019 16:15:38 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; ) |
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