Re: GitForWindows vs. Cygwin
It doesn't use cygwin, therefore it's not related. Since this is a cygwin mailing list, that means the first two replies were correct — this isn't the place to discuss it. When the vast majority of the code in the MSYS2 runtime is exactly the same as the code in the Cygwin runtime, and Git for Windows uses msys-2.0.dll in a number of places (which is essentially a renamed copy of cygwin1.dll) the question was fair. Particularly given Cygwin has its own git package, it's only natural to wonder how that differs from Git for Windows, and how it differs from the probably lesser- known msys2-git package (which is built in very nearly the same configuration as the Cygwin git package, posix style). Only GfW and Msys2 Git projects can answer how Cygwin components are used by their projects. Most (all?) of Cygwin winsup and (all of?) newlib are available under permissive BSD(-style) licences that allow all uses of the code. It's possible that the developers of those GfW and Msys2 Git packages have moved on from those projects and the current maintainers don't have the basis to answer. One might expect some of those maintainers to be subscribed to this list and able to answer, but they may not, and just check web archives, or they may choose not to get into this discussion here, although they could perhaps suggest a more appropriate forum, or take the discussion off-list. I've been watching this thread closely, but I had decided not to post since it seemed like this discussion is unwanted by a part of the community. On the surface, this discussion is about Git, so the most on-topic place to discuss is the Git public mailing list. I personally don't think the Cygwin mailing list is off-topic. Because most(all?) Windows Git distros use Cygwin code, it might be even more useful to ask here (though I assume Johannes subscribes to Git ML and he would be able to answer all the intricacies pretty accurately). So far, Tony Kelman's descriptions were pretty spot on (that's why I didn't respond to his call for corrections -- I couldn't think of any). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Quotes around command-line argument that has unicode characters are not removed
Greetings, Dmitry Katsubo!
> Dear Cygwin community,
> I observe the following on my Cygwin:
This is not cygwin, this is bare Windows.
> when I put quotes around file that has
> non-ASCII symbols, these quotes are passed to argv of the process literally,
> otherwise they are removed. I would expect that there is a consistency.
Parameter unquoting done by the shell.
CMD does that differently from POSIX shells.
> I have written a small C program that displays arguments, and run it three
> times:
Run it in bash. I'm pretty sure you will see your results more consistent.
> #1 For the file with space, taken into quotes ("the file.txt") -- OK
> #2 For the file with non-ASCII characters (Château.txt) -- OK
> #3 For the file with non-ASCII characters, taken into quotes ("Château.txt")
> -- WRONG
> d:\cli> uname -a
> CYGWIN_NT-6.1-WOW PC 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin
> D:\cli> chcp
> Active code page: 866
> D:\cli> dir
> ...cut...
> 2018-03-22 00:43 0 Château.txt
> 2018-03-22 00:01 393 test.c
> 2018-03-22 00:01 150,230 test.exe
> 2018-03-21 00:15 186 test.pl
> 2018-03-22 00:43 0 the file.txt
> 2018-03-22 00:4016 текст плюс.txt
>6 File(s)150,825 bytes
>2 Dir(s) 41,972,293,632 bytes free
> D:\cli> test "the file.txt"
> param 0 = test
> param 1 = the file.txt
> File 'the file.txt' was opened
> D:\cli> test Château.txt
> param 0 = test
> param 1 = Château.txt
> File 'Château.txt' was opened
> D:\cli> test "Château.txt"
> param 0 = test
> param 1 = "Château.txt"
> Failed to open '"Château.txt"': No such file or directory
> As one can see, the last run fails. I am a bit puzzled: how can I pass the
> name
> of the file with space and Unicode symbols? I need to do it in uniform way,
> as I
> am calling a Cygwin program from native Windows program, as in [1].
> D:\cli> test "текст плюс.txt"
> param 0 = test
> param 1 = "текст плюс.txt"
> Failed to open '"текст плюс.txt"': No such file or directory
> I have search a bit, but I couldn't find a direct answer. From post [1] and
> [2]
> I see that compiler inserts the code to do some argument pre-processing like
> @pathnames [3], but what are exactly the rules? Is quote pre-processing done
> in
> dcrt0.cc:177 [4]?
> Any feedback is appreciated.
> [1] https://sourceware.org/ml/cygwin/2016-05/msg00082.html
> [2] http://daviddeley.com/autohotkey/parameters/parameters.htm
> [3] https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-at
> [4] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L177
> === test.c ===
> #include
> #include
> #include
> int main(int argc, char* argv[])
> {
> for (int i = 0; i < argc; i++)
> {
> printf("param %d = %s\n", i, argv[i]);
> }
> FILE* f = fopen(argv[1], "r");
> if (f != NULL)
> {
> printf("File '%s' was opened\n", argv[1]);
> fclose(f);
> } else {
> printf("Failed to open '%s': %s\n", argv[1], strerror(errno));
> }
> return 0;
> }
--
With best regards,
Andrey Repin
Thursday, March 22, 2018 14:21:25
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Quotes around command-line argument that has unicode characters are not removed
On Thu, 22 Mar 2018 01:15:00 +0100
Dmitry Katsubo via cygwin <...> wrote:
> Dear Cygwin community,
>
> I observe the following on my Cygwin: when I put quotes around file that has
> non-ASCII symbols, these quotes are passed to argv of the process literally,
> otherwise they are removed. I would expect that there is a consistency.
>
> I have written a small C program that displays arguments, and run it three
> times:
>
> #1 For the file with space, taken into quotes ("the file.txt") -- OK
> #2 For the file with non-ASCII characters (Château.txt) -- OK
> #3 For the file with non-ASCII characters, taken into quotes ("Château.txt")
> -- WRONG
>
> d:\cli> uname -a
> CYGWIN_NT-6.1-WOW PC 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin
>
> D:\cli> chcp
> Active code page: 866
>
> D:\cli> dir
> ...cut...
> 2018-03-22 00:43 0 Château.txt
> 2018-03-22 00:01 393 test.c
> 2018-03-22 00:01 150,230 test.exe
> 2018-03-21 00:15 186 test.pl
> 2018-03-22 00:43 0 the file.txt
> 2018-03-22 00:4016 текст плюс.txt
>6 File(s)150,825 bytes
>2 Dir(s) 41,972,293,632 bytes free
>
> D:\cli> test "the file.txt"
> param 0 = test
> param 1 = the file.txt
> File 'the file.txt' was opened
>
> D:\cli> test Château.txt
> param 0 = test
> param 1 = Château.txt
> File 'Château.txt' was opened
>
> D:\cli> test "Château.txt"
> param 0 = test
> param 1 = "Château.txt"
> Failed to open '"Château.txt"': No such file or directory
>
> As one can see, the last run fails. I am a bit puzzled: how can I pass the
> name
> of the file with space and Unicode symbols? I need to do it in uniform way,
> as I
> am calling a Cygwin program from native Windows program, as in [1].
>
> D:\cli> test "текст плюс.txt"
> param 0 = test
> param 1 = "текст плюс.txt"
> Failed to open '"текст плюс.txt"': No such file or directory
>
> I have search a bit, but I couldn't find a direct answer. From post [1] and
> [2]
> I see that compiler inserts the code to do some argument pre-processing like
> @pathnames [3], but what are exactly the rules? Is quote pre-processing done
> in
> dcrt0.cc:177 [4]?
>
> Any feedback is appreciated.
>
> [1] https://sourceware.org/ml/cygwin/2016-05/msg00082.html
> [2] http://daviddeley.com/autohotkey/parameters/parameters.htm
> [3] https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-at
> [4] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L177
>
> === test.c ===
> #include
> #include
> #include
>
> int main(int argc, char* argv[])
> {
> for (int i = 0; i < argc; i++)
> {
> printf("param %d = %s\n", i, argv[i]);
> }
> FILE* f = fopen(argv[1], "r");
> if (f != NULL)
> {
> printf("File '%s' was opened\n", argv[1]);
> fclose(f);
> } else {
> printf("Failed to open '%s': %s\n", argv[1], strerror(errno));
> }
> return 0;
> }
>
> --
Hello, Dmintry,
consider these test cases:
Native (msvcrt) binary:
---
$ x86_64-w64-mingw32-gcc test.c -o test-win.exe
$ ldd test-win.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fa0590)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL
(0x7fa030e)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7fa028f)
msvcrt.dll => /cygdrive/c/Windows/system32/msvcrt.dll (0x7fa0322)
---
Cygwin-flavor binary:
-
$ gcc test.c -o test-cygwin.exe
$ ldd test-cygwin.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fa0590)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL
(0x7fa030e)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7fa028f)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
-
Create a file with non-ascii chars in the name:
---
$ touch "текст плюс.txt"
---
Run both binaries in mintty with bash:
--
$ ./test-win "текст плюс.txt"
param 0 = D:\wroot\test.cygwin\Quotes around command-line argument that has
unicode characters are not removed\test-win.exe
param 1 = ▒ .txt
File '▒ .txt' was opened
$ ./test-cygwin "текст плюс.txt"
param 0 = ./test-cygwin
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened
--
Run the binaries in cmd.exe with bash:
--
$ ./test-win "текст плюс.txt"
param 0 = D:\wroot\test.cygwin\Quotes around command-line argument that has
unicode characters are not removed\test-win.exe
param 1 = ЄхъёЄ яы■ё.txt
File 'ЄхъёЄ яы■ё.txt' was opened
$ ./test-cygwin "текст плюс.txt"
param 0 = ./test-cygwin
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened
--
Re: Quotes around command-line argument that has unicode characters are not removed
Greetings, Mikhail Usenko! > In bare cmd.exe native-msvcrt binary is working OK with quoted non-ascii > arguments, while cygwin-flavor binary is not. But I don't know exactly which > level here: cmd.exe or msvcrt.dll/cygwin1.dll is responsible for > such a behavior. Locale settings affecting Cygwin binary. If you set LANG=ru_RU.CP866 (f.e.) before invoking cygwin testcase in native CMD, you will likely see it working better. Alternatively, you could try chcp 65001 -- With best regards, Andrey Repin Thursday, March 22, 2018 16:22:13 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
de1 problem
3 [main] bash 1360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Compilation stopped. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GitForWindows vs. Cygwin
Hello list, I think there is information the OP can use, but no one has apparently experienced it. Also, it's not likely he'd have gotten good information from the other respective mailing lists, so I think it is fine he asked here. However, I am not very smart and my opinion does not matter, so I apologize for the noise on the list. On Tue, Mar 20, 2018 at 5:52 PM, KARL BOTTS wrote: > > Can anyone enlighten me about the relationship of "Git for Windows" to > Cygwin? > > I have no intention to use GFW myself: I use Cygwin git. But now other people > around here are discovering GitHub, MSysGit and or GitForWindows. Pretty > soon, we are going to wind up with multiple git flavors installed on the same > host, which worries me. > > I know that MSysGit is basically a stale fork of Cygwin. I tried it a long > time ago (during a period when the git in Cygwin was not getting updated > often), and it caused me trouble. As I recall, the bash in it was only v3, > and I was used to v4, and some of my scripts didn't run right, and MSysGit > messed up my HOME dir. Anyhow, I got rid of MSysGit. And now that the git in > Cygwin is keeping current, I am quite content. > > But now I hear of this GitForWindows thing. Which seems to have replaced > MSysGit, with a GUI thrown in. But is it _still_ a stale fork of Cygwin, or a > fork at all? Is it descended from MSysGit? I have been googling all over, > but not finding good answers. > > I just want to watch out for the damn thing, and try to keep it away... > What you need to watch out for is having a cluttered PATH. If you install, say, the WinAVR toolchain, it includes either an MSYS distribution or select pieces of Cygwin (bundling MSYS[2] is more popular, from memory). These old tools will cause problems if you try to run autotools for a native project from within Cygwin. Other distributions, like the Haskell Stack, have the same problem. If you install MSYS2 and Cygwin and both are in your path but you keep both up to date, you won't have this problem. Cheers, R0b0t1 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: de1 problem
Greetings, Raissa SHEMA! > 3 [main] bash 1360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.com > Compilation stopped. Please update your Cygwin, this issue was resolved over a decade ago. For details, see http://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings -- With best regards, Andrey Repin Thursday, March 22, 2018 19:43:44 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Odd hang in python waiting for child; strace wakes hung process?
On Mar 21 23:41, Brian Inglis wrote: > On 2018-03-21 16:07, Dan Kegel wrote: > > On Wed, Mar 21, 2018 at 11:54 AM, Achim Gratz wrote: > >> Well, with the sporadic hanging/defunct processes at work my routine is > >> to send CONT to all Cygwin processes, then HUP/KILL to anything that's > >> still not live or gone and then another round of CONT. This works > >> _most_ of the time, anything more stubborn I /bin/kill -f usually. > > > > Since I wrote, both bots hung again. This time I verified: > > 0) both had the defunct git process as expected > > 1) kill -CONT the-pid doesn't do anything, nor does kill -9. It's truly > > wedged. > > 2) the process stays in its spin hang until you ^C strace -p the-pid > > 3) ^C-ing the strace causes the process to terminate (strace alone doesn't) > > 4) taskkill /pid the-task /f also kills the process successfully. > > > > So I could write a script that watched for defunct git processes > > and taskkilled their parent. Build jobs would fail, but at least > > the bot would stay up. Of course it would be much nicer if > > the cygwin python process didn't get wedged. > > > > Alternately, I suppose I could try running native python... > > or cygwin's python3... but dangit, kill -9 should work. > > Seems to be looping on access failure to a Windows mailslot; not sure what > this > feature is normally used for: dmesg/syslog messages/AF_UNIX sockets? /dev/kmsg is implemented using a mailslot under the hood. This feature is only used to log exceptions and for nothing else since nobody ever found another reason to use it for. It would be interesting to learn if the perl hangs have the same reason. I guess we can simply remove /dev/kmsg support completely and drop the mailslot code. I'm pretty sure nobody would miss it. Hardly anybody knows it exists... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 04:24, Andrey Repin wrote: Greetings, Dmitry Katsubo! Dear Cygwin community, I observe the following on my Cygwin: This is not cygwin, this is bare Windows. That may be so, yet there may be an issue here for someone packaging Cygwin programs for use as native Windows applications. That is to say, there could potentially be something here that the Cygnal project could address: http://www.kylheku.com/cygnal/ Cygnal is an ultra-light fork of the Cygwin DLL that is intended for users like Dmitry Katsubo, who run Cygwin programs out of the Windows environment directly, after building them in Cygwin. when I put quotes around file that has non-ASCII symbols, these quotes are passed to argv of the process literally, otherwise they are removed. I would expect that there is a consistency. Parameter unquoting done by the shell. CMD does that differently from POSIX shells. As I seem to recall, CMD doesn't do anything, period! It passes the command line as one big string. It has to since that's the OS mechanism. The quoting conventions come from how various run-time libraries deal with that string. An influential convention is that of the MS Visual C run-time library; it behooves other run-times to be compatible with that for consistency with programs whose main() was compiled with MSVC. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X Server 1.19.6-2 , xset does not add ghostscript fonts for xfig
Ken Brown writes: > What a mess! Indeed. > There's a comment just yesterday at > > https://bugzilla.redhat.com/show_bug.cgi?id=1551219#c8 > > suggesting that there will be some Fedora changes in the urw font > package coming this week. So let's wait for the dust to settle, and > then I hope we can just copy whatever solution Fedora comes up with. That works for me. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Odd hang in python waiting for child; strace wakes hung process?
Dan Kegel writes: > 1) kill -CONT the-pid doesn't do anything, nor does kill -9. It's > truly wedged. No, you send CONT to all processes (like 'pkill -CONT .'), it seems that this gets whatever was wedged enough of a kick to retry or time out and then it (often, not always) it seems to start reaping processes again and the start to vanish. You can tell you have one of these when just doing a ps takes much longer than usual when it hits those processes. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Odd hang in python waiting for child; strace wakes hung process?
On Thu, Mar 22, 2018 at 9:59 AM, Corinna Vinschen wrote: > I guess we can simply remove /dev/kmsg support completely and drop > the mailslot code. I'm pretty sure nobody would miss it. Hardly > anybody knows it exists... I'd be happy to test (though building cygwin is not in the cards for me for now). But would it break this guy's use case (running syslog-ng on cygwin)? http://kb.kaminskiengineering.com/node/382 https://web.archive.org/web/20110209222803/http://www.syslog.org/logged/running-syslog-ng-on-windows/ - Dan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 12:24, Andrey Repin wrote: > > This is not cygwin, this is bare Windows. This is executable linked against cygwin1.dll. I personally call such binaries "Cygwin programs". However it is run from Windows. > Parameter unquoting done by the shell. > CMD does that differently from POSIX shells. CMD does nothing when you execute a program from it. Command-line is passed literally. I've download procmon.exe [1] and filtered by process name "cmd.exe". When I run D:\cli> test abc "текст\" плюс.txt" (suppose that CMD will at least remove backslashes) I see the following in the log: test abc "текст\" плюс.txt" [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon -- With best regards, Dmitry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] ghostscript 9.23-1
The following packages have been uploaded to the Cygwin distribution: * ghostscript-9.23-1 * libgs9-9.23-1 * libgs-devel-9.23-1 GNU Ghostscript is a PostScript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This is an update to the latest upstream release. Ken Brown Cygwin's Ghostscript maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: setup (2.891)
A new version of Setup, release 2.891, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) Changes compared to 2.889: - 'Use HTTP/FTP Proxy' connection type now uses the WinINet API As a consequence, the '--user-agent' option now affects this connection type as well - Remove the 'Direct(legacy)' connection type and associated cruft There have been no reported problems with it's replacement, the 'Direct' connection type, since it's introduction in 2.878 (See https://cygwin.com/ml/cygwin-announce/2017-05/msg00053.html) If this is the currently configured connection type, it will be silently migrated to 'Direct' - Improve file:// URL handling All well-formed file URLs should now work. Malformed file URLs we previously accepted should also still work. Thanks to SZAVAI Gyula for these changes. - Various fixes for regressions in 'Install from Local Directory' mode Addresses: https://cygwin.com/ml/cygwin/2018-03/msg00027.html Thanks to Ken Brown for these changes. - Add support for setup-minimum-version: in setup.ini - Preliminary support for 'provides:' and 'conflicts': in setup.ini - Add a --version option Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.891release candidate - please test
On 16/03/2018 21:52, Robert Cohen wrote: - Hi Jon, I tested setup-2.891.x86_64 with an install from local directory, and I got the same result as setup-2.889-12-g1cf567.x86_64.exe, where it installed the additional packages that I selected, but at the end it gave this message: Package: _/libfontconfig-common fontconfig_dtd.sh exit code 2 Do you think this may be because I'm installing from an already-downloaded directory and It may work ok if I repeat the download and install process using the new setup executable, or would another solution be needed for this, as alluded to in your earlier reply to this same error message? Thanks for testing. Yes, as I wrote in [1], this isn't more a missing feature and/or missing dependency information, than a bug in setup. [1] https://cygwin.com/ml/cygwin/2018-03/msg00108.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.891release candidate - please test
On 18/03/2018 18:23, Houder wrote: cd /var/log file setup.log *log-* [...] grep '^M^M' setup.log-8.full 2018/03/18 14:06:50 Problem 1/1 nothing provides liblz4_1 needed by libarchive13-3.3.2-1 Solution 1/1 (default) - do not ask to install bsdtar-3.3.2-1 # apparently, problem reporting by libsolv causes an additional CR ... why? Q: Would it be possible to prevent the additional CR from showing up in the log file? It is visible when the log file is examined by means of vi(m). It looks like this is just a bug (we are logging the string after it's had the line terminators turned into CRLF for putting into a Windows text box, but the logging mechanism expects LF line terminators) Thanks for testing, and thanks for pointing this out. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup-x86_64.exe v2.889 doesn't select additionally downloaded packages when installing from local directory
On 3/7/2018 3:15 PM, Jon Turney wrote: Yeah, this looks like an ordering problem between libxml2 and libfontconfig-common. $ cat /etc/postinstall/fontconfig_dtd.sh if [ -x /usr/bin/xmlcatalog ] ; then /usr/bin/xmlcatalog --noout --add "system" "fonts.dtd" /usr/share/xml/fontconfig/fonts.dtd /etc/xml/catalog fi $ cat /etc/postinstall/libxml2.sh if test ! -f /etc/xml/catalog; then /bin/mkdir -p /etc/xml /usr/bin/xmlcatalog --noout --create /etc/xml/catalog fi Not sure how to fix this. I think there's no actual dependency of libfontconfig-common on xmlcatalog, but we lack a triggering mechanism to say "run this script when this other package is installed" /etc/postinstall/fontconfig_dtd.sh could check whether /etc/postinstall/libxml2.sh exists. If so, it could run it and then add '.done' so it isn't run again. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 14:25, Andrey Repin wrote: > Greetings, Mikhail Usenko! > >> In bare cmd.exe native-msvcrt binary is working OK with quoted non-ascii >> arguments, while cygwin-flavor binary is not. But I don't know exactly which >> level here: cmd.exe or msvcrt.dll/cygwin1.dll is responsible for >> such a behavior. Thanks, Mikhail! I generally agree with you. If you follow the links I've provided in my original mail, you can see that cmd.exe does not do any argument splitting. I also see that from this method signature [1]: build_argv (char *cmd, char **&argv, int &argc, int winshell) which basically takes a string as input and returns an array of strings plus number of arguments as output. So this is either done by msvcrt.dll or by cygwin1.dll and they have different ways of doing that, which is OK provided it is documented and done consistently. I refer back to dcrt0.cc where the woodoo is done. In particular in line 165 [2] it checks that execution was performed from bare Windows, and behaves differently. On 2018-03-22 12:24, Andrey Repin wrote: > Run it in bash. I'm pretty sure you will see your results more consistent. When "test.exe" is run from bash, it behaves correctly because as you said bash did the most of dirty work. I also tried to workaround like below, but it does not work: D:\cli> bash -c "./test 'текст плюс.txt'" bash: ./test 'текст плюс.txt': No such file or directory > Locale settings affecting Cygwin binary. > > If you > set LANG=ru_RU.CP866 > (f.e.) > before invoking cygwin testcase in native CMD, you will likely see it > working better. Thanks for this advise, Andrey. I see that it reacts, but works worth :) I think it advises to output characters in CP866, but console is UTF-8: D:\cli> set LANG=ru_RU.CP866 D:\cli> test "текст плюс.txt" param 0 = test param 1 = ⥪▒▒ .txt Failed to open '⥪▒▒ .txt': No such file or directory But.. ta-da! I made it working like that: D:\cli> set LANG=ru_RU.UTF-8 D:\cli> test "текст плюс.txt" param 0 = test param 1 = текст плюс.txt File 'текст плюс.txt' was opened Hooray, it worked! > Alternatively, you could try > chcp 65001 That does not help: D:\cli> chcp 65001 Active code page: 65001 D:\cli> test "текст плюс.txt" param 0 = test param 1 = "текст плюс.txt" Failed to open '"текст плюс.txt"': No such file or directory [1] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L297 [2] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L165 -- With best regards, Dmitry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 18:10, Kaz Kylheku wrote: > That may be so, yet there may be an issue here for someone packaging > Cygwin programs for use as native Windows applications. > > That is to say, there could potentially be something here that the Cygnal > project could address: > > http://www.kylheku.com/cygnal/ > > Cygnal is an ultra-light fork of the Cygwin DLL that is intended for users, > who run Cygwin programs out of the Windows environment directly, after > building them in Cygwin. Thanks for the hint. I confirm that just substituting cygwin1.dll makes the test working: D:\cli> test "текст плюс.txt" param 0 = test param 1 = текст плюс.txt File 'текст плюс.txt' was opened I was not able to find any relevant difference in dcrt0.cc, but perhaps the difference is in initial setting of locale (Cygnal initialization). -- With best regards, Dmitry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup -g ???
On 14/03/2018 15:26, David Allsopp wrote: [reformatted for top-posting] Lee wrote: -- Forwarded message -- From: Jon Turney Date: Fri, 3 Nov 2017 15:26:27 + Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor To: The Cygwin Mailing List On 03/11/2017 14:45, Vadim Zeitlin wrote: Our build has started on AppVeyor, a continuous integration provider, started failing since a couple of days as a makefile command running a Python script started failing with exit code 127 without any more information. This is a strange situation as I can't reproduce the problem locally, but something definitely seems to be wrong with this package on the AppVeyor machine as Python just doesn't seem to be executable, e.g. the output of these commands in our batch file driving the build: Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's setup. Due to setup terribleness, without this flag, it will install the requested packages, and any missing dependencies of them, but not upgrade any of the dependencies which are already installed to the current (and perhaps needed) version... See also [1]. [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html Should we still be using the -g (--upgrade-also) flag on setup? I believe so (or at least hope so). I think it's the case that setup should now know to upgrade a dependency if you install a new package which requires a newer version of it, but I hope that's not become the same as setup effectively acting with --upgrade-also every time you run it (that would be a real nuisance, unless the entire Cygwin package universe is going to be recompiled on every new Cygwin release). This is basically correct. setup is now capable of being told about dependencies where upgrading an already installed package is required, but this information isn't currently collected (For example, some packages now exist (e.g. vim [1]), which were built with gcc 6.4.0-5 and cygport 0.31.0-1. These packages almost certainly use ssp/fortify functions in the cygwin DLL, and so require a cygwin package >=2.10.0-1 (technically, the requirement is cygwin API >=0.320), but the dependency recorded is only on the cygwin package at any version) That's something someone could usefully work on, if they were so inclined. So, yes, if you are using --packages, you should continue to use -g (unless you know what you are doing and/or like to live dangerously) [1] https://cygwin.com/ml/cygwin/2018-03/msg00176.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.891release candidate - please test
--- From: Jon Turney ... Thanks for testing. Yes, as I wrote in [1], this isn't more a missing feature and/or missing dependency information, than a bug in setup. [1] https://cygwin.com/ml/cygwin/2018-03/msg00108.html --- Hi Jon, Thanks for clarifying that. For now, would it make sense for me to manually run /etc/postinstall/fontconfig_dtd.sh, or /etc/postinstall/libxml2.sh, or both after setup is complete, or should I just ignore the error? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Issues with setting or not setting HOME environment variable
I currently do not set the HOME environment variable. I get the impression you're not supposed to do that. When I run a mintty shell, it correctly puts me in "/home/", which is what I want. I'm running into a problem with Eclipse egit, as I think it's looking for the "HOME" environment variable to determine where the .gitconfig file is. If it doesn't find "HOME" set, I have a feeling it's looking for "HOMEDRIVE", which is set to something I can't easily control. Is there some way I can set "HOME" to my Windows home location, but still have Cygwin do the right thing and go to "/home/"? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
texlive-collection-basic requires Perl to be removed
This package contains this file: /etc/preremove/texlive-collection-basic.sh which in turn calls: /usr/libexec/update_tlpdb which is a Perl script. I understand that "texlive-collection-basic" requires "perl_base", but if a user removed Perl first then uninstallation of texlive would fail. Perhaps "update_tlpdb" could be rewritten as a shell script. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
