Re: Problem - Possibly Cygwin
On 1/25/2019 8:29 AM, Marco Atzeri wrote: Am 25.01.2019 um 14:24 schrieb Mitch Rosefelt: Hi All: I've run into a problem in which cygwin is part of the error message. I don't know that cygwin is part of the problem, but I'm having great difficulty figuring this out, so I'm posting it here with the hope that someone will know the fix. Thanks much. = After installing react-devtools <https://github.com/facebook/react-devtools/tree/master/packages/react-devtools> into my Node JS environment, I am no longer able to run expo-cli. Everything was working fine until I did that. I’m now getting the error below. In addition to not being able to run expo, my Powershell permissions were also changed to "restricted" (fixed). I even restored my registry to the previous day in an effort to fix this. I have uninstalled/reinstalled node and yarn. The error indicates Cygwin, which I don't have installed on my computer (does not show up in a registry search), however, searching my computer, I see that Cygwin was installed with Git:C:\Program Files\Git\usr\share\cygwin C:\Program Files\Git\usr\bin\cygwin-console-helper.exe C:\Program Files\Android\Android Studio\bin\lldb\lib\distutils\cygwinccompiler.py C:\Program Files\Git\usr\lib\perlS\core_per|\File\Spec\cygwin.pm C:\Program Files\Git\usr\share\cygwin\cygwin.ldif C:\Program Files\Git\usr\share\tern1info\63\cygwin C:\Program Files\Git\usr\lib\terminf0\63\cygwin Any help will be GREATLY appreciated. have you tried with a clean PATH for every application ? I don't think that will help. The expo.ps1 is using a shell expression and the interpreter isn't liking the syntax. It's trying to determine if Cygwin is installed and if it is get a Windows path for the basedir variable. It chokes on the ')' in the structure of the comparison. That error doesn't indicate Cygwin is installed or found. You'll have to ask the expo vendor. -- cyg Simple -- 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: CYGWIN slow when accessing network share
On 1/22/2019 4:27 PM, J. David Boyd wrote: I've tried Googling for this, with pretty much 0 results. On my windows 10 machine (32 or 64 bit Cygwin) ls of anything that is a network share seems to be really slow, taking 20 - 30 seconds to complete. Saving a file there takes about 10 -20 seconds as well. My windows 7 machine (32 bit Cygwin) doesn't do that. They are both running same version of cgywin, except that saving with the windows 7 doesn't slow down. Where should I start to find a resolution for this? Anyone have a web url where the problem has been discussed? Search the Cygwin FAQ for the word BLODA. You've something different on the two systems that interferes with the network traffic. -- cyg Simple -- 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: Can anybody point me to wish84
On 1/23/2019 9:26 AM, Fergus wrote: Can anybody supply or point me to the Cygwin .tar.xz (or probably .tar.bz2, it will be that ancient) for wish v.8.4? Please, if at all possible, an email attachment or explicit pointer rather than a HowTo would be so much appreciated. You should be able to build it from source downloaded from http://tcl.tk/software/tcltk/8.4.html. What specifically requires that you have that version? Could it be modified to use the most current version? -- cyg Simple -- 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: OpenSSH server on latest Windows 10
On 1/9/2019 4:59 PM, Erik Soderquist wrote: On Tue, Jan 8, 2019 at 11:56 PM Jari Fredriksson wrote: It is indeed removed. There is no ”Cygwin sushi” service any more. I have encountered this as well, but it seems very inconsistent. People on this list who have tried to intentionally reproduce it have been unable to. At the same time, one of my systems is still broken from the Windows Update, and I have been unable to get cygwin ssh working again, and have zero interest in trying the Microsoft ssh. I have delayed updating other systems because of this. IIRC, this was discussed last year with suggestions to rename the Cygwin service as a work around the issue. -- cyg Simple -- 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: Virtual device in Windows 10
On 1/1/2019 2:18 AM, Gary Graham wrote: I downloaded an updated version of the Cygwin tools and tried again C:\cygwin64\bin>socat -d -d pty,link=/dev/ttyV0,waitslave tcp: 192.168.0.11:8023 2019/01/01 01:14:27 socat[10780] N PTY is /dev/pty0 2019/01/01 01:14:27 socat[10780] N opening connection to AF=2 192.168.0.11:8023 2019/01/01 01:14:28 socat[10780] N successfully connected from local address AF=2 192.168.0.18:55426 2019/01/01 01:14:28 socat[10780] N starting data transfer loop with FDs [5,5] and [6,6] 2019/01/01 01:14:28 socat[10780] N read(5, 0x600056500, 8192): Input/output error (probably PTY closed) 2019/01/01 01:14:28 socat[10780] N socket 1 (fd 5) is at EOF 2019/01/01 01:14:28 socat[10780] N socket 1 (fd 5) is at EOF 2019/01/01 01:14:28 socat[10780] N socket 2 (fd 6) is at EOF 2019/01/01 01:14:28 socat[10780] N exiting with status 0 Can you tell why the PTY is closing ? Both ends of the processes a Cygwin process? PTY is only available to Cygwin. -- cyg Simple -- 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: Problem with effective permissions -rw----rw-+
On 12/22/2018 5:26 AM, chris@pinky.co.uk wrote: I'm facing a problem with effective permissions, where the group permission is unset; chrisd@edmund:tmp > touch dummy;ls -l dummy;getfacl dummy -rwrw-+ 1 chrisd None 0 Dec 22 10:22 dummy # file: dummy # owner: chrisd # group: None user::rw- group::rw- #effective:--- group:Administrators:rwx#effective:--- mask::--- other::rw- chrisd@edmund: > umask 000 Any ideas on how to resolve so that it reverts to group:rw- What does cacls give? -- cyg Simple -- 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: Problem with effective permissions -rw----rw-+
On 12/22/2018 5:26 AM, chris@pinky.co.uk wrote: I'm facing a problem with effective permissions, where the group permission is unset; chrisd@edmund:tmp > touch dummy;ls -l dummy;getfacl dummy -rwrw-+ 1 chrisd None 0 Dec 22 10:22 dummy # file: dummy # owner: chrisd # group: None user::rw- group::rw- #effective:--- group:Administrators:rwx#effective:--- mask::--- other::rw- chrisd@edmund: > umask 000 Any ideas on how to resolve so that it reverts to group:rw- What does cacls give? -- cyg Simple -- 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: Windows - special device question message 6168
On 12/22/2018 10:40 AM, Gary Graham wrote:
Greetings,
I am trying to use a command that works on Linuz, but I want to use this on
Windows.
SOCAT>socat pty,link=/dev/ttyV0,waitslave tcp:192.168.x.xx:8023
2 [main] socat 6168 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
2018/12/22 09:33:54 socat[6168] E unlink("/dev/ttyV0"): Read-only file
system
As you can see, I am having trouble sorting out the name or permissions to
link ttyV0.
This name is not mentioned on the special device page at:
https://cygwin.com/cygwin-ug-net/using-specialnames.html
Just a warning
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
cyg Simple
--
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: how is cygstart different from cmd /c or how to have cygstart start 'inline'?
On 12/21/2018 2:33 AM, L A Walsh wrote:
Got a program that starts under cygstart, but I'd
like to be able to start it without starting up the program
in a new window..so was trying cmd /c.
I compared env's and noted both PATH and TMP had been
converted back to the backslash using case, so I
did that manually:
if ((usecmd)); then
export TMP=$(cygpath -w $TMP)
my newpath=""
my sep=""
readarray -t pathar < <(echo -E "$PATH"|tr ":" "\n")
for p in "${pathar[@]}"; do
n=$(cygpath -w "$p")
newpath="$newpath$sep$n"
#echo -E "newpath=$newpath"
sep=";"
done
export Path=$newpath
fi
But no luck in launching (cygstart case works):
cd "$ldir" && {
if ((usecmd)); then
'c:/windows/system32/cmd.exe' /c "$lpath" "${args[@]}"
else
cygstart "$lpath" "${args[@]}"
fi
}
I use:
mailto:cygsim...@users.sourceforge.net
# https://sourceforge.net/p/cygsimple
# File: cmd
`cygpath "$COMSPEC"` "$@"
and
#!/usr/bin/env bash
# Copyright (C) 2018, cygSimple
# mailto:cygsim...@users.sourceforge.net
# https://sourceforge.net/p/cygsimple
# File: start
cmd /c start `cygpath -w -- "${@//&/^&}"`
The file /usr/local/bin/start uses the file /usr/local/bin/cmd because
of PATH.
I use another such file to start the Windows version of gvim.
#!/usr/bin/env bash
# Copyright (C) 2018, cygSimple
# mailto:cygsim...@users.sourceforge.net
# https://sourceforge.net/p/cygsimple
export PATH=/c/opt/vim/vim74:"$PATH"
start /c/opt/vim/vim74/gvim `cygpath -w -- "$@"` &
So what else does cygstart do that I might setup
before a "cmd /c"
to get the target to run?
Don't know.
Or anyway to have cygstart run the command with its output in the
current window?
A windows program will have a different console by default. A console
program could can communicate to the same console as it is started in
unless it uses pty (e.g. /c/windows/system32/ftp).
--
cyg Simple
--
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: Exclude System entries with "ls" or "find"
On 12/18/2018 7:58 AM, Eliot Moss wrote: However, you can run DOS attrib from Cygwin, just like any Windows program, and parse its output. So it would be possible to use a combination of Windows and Cygwin tools to do what you're seeking, though not necessarily with high efficiency, etc. That depends on the Windows program and whether or not it the data gets to Cygwin. -- cyg Simple -- 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: grep 3.0-2 not stripping CRs on Windows
On 12/17/2018 8:05 AM, Steven Penny wrote: On Mon, 17 Dec 2018 13:22:48, Ondřej Surý wrote: # No amount of options makes the grep find the text in the file $ ./grep-3.0-2.exe 'foo$’ crlf.txt $ ./grep-3.0-2.exe -U 'foo$' crlf.txt $ ./grep-3.0-2.exe -a 'foo$’ crlf.txt Your commands are failing because you are not accounding for the carriage returns. as was said, this change was intentionally done for the purpose of making scripts MORE portable: And the portability is what we want to keep. https://cygwin.com/ml/cygwin/2017-02/msg00155.html if you want to keep your grep command, you need to remove CR first: $ printf 'alpha\r\nbeta\r\n' > CRLF.txt $ tr -d '\r' < CRLF.txt | grep 'a$' This is the POSIX method to get portability and Cygwin is POSIX for Windows. Therefore the bits of documentation for MS-DOS and MS-Windows isn't in affect for Cygwin grep. In other words the following is in affect but can be misinterpreted because Cygwin runs on MS-Windows but isn't considered such. "This option has no effect on platforms other than MS-DOS and MS-Windows." alpha beta -- cyg Simple -- 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: [ANNOUNCEMENT] Updated: mintty 2.9.5
On 12/6/2018 2:22 AM, Thomas Wolff wrote: Am 06.12.2018 um 01:18 schrieb Andrey Repin: Greetings, Thomas Wolff! Am 05.12.2018 um 21:21 schrieb Achim Gratz: Thomas Wolff writes: Other * Ensuring /bin in PATH for user commands. Blindly prepending /bin to the existing PATH is asking for trouble with certain setups. Just to clarify, this is only applicable to user-defined commands added to the extended context menu (option UserCommands), in order to ensure basic tools are available. If you see problems there, please be more specific. Yes, I see problem there. I have Cygwin in my regular %PATH% at the place I want it. I.e. when using tools and commands, I expect them to behave in a certain way. Changing it have potential to produce unexpected results. The issue that caused me to apply this change: if you start mintty from a desktop shortcut, cygwin /bin is not in the PATH of mintty (unless you would set it globally in Windows, which is discouraged). It will be inside your login shell, of course, but user commands are spawned from mintty directly. I could append rather than prepend /bin, but then another tool like `sed` might be in the path and user commands behave unexpectedly. I could also check whether it's in PATH already, and then prepend. Please make it optional. And rather than prepend doing an append might avoid the conflicts described by Andrey. -- cyg Simple -- 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/5/2018 5:25 PM, David Karr wrote: On Wed, Dec 5, 2018 at 11:44 AM cyg Simple wrote: On 12/5/2018 1:33 PM, David Karr wrote: On Wed, Dec 5, 2018 at 9:43 AM cyg Simple wrote: Your query got me interested in looking and I believe that winpty needs to be at the front of all the commands so that it can communicate with mintty properly. To overcome the need to remember you could add an alias to execute the command; `alias FOO="winpty FOO"'. Sigh. What a mess. I can't get this to work. It was easy enough when a single script has to execute "kubectl", having "winpty" prefix that call, but I'm trying to write a script that calls that other script, and even in a pipeline. If I have "winpty" prefix the call to the script that calls "kubectl", it says: winpty: error: cannot start '...': Not found in PATH When I changed it so it references the absolute path, it then says "%1 is not a valid Win32 application. (error 0xc1)". So, this makes it clear that winpty can only directly execute Windows applications, which makes sense. So how can I call a Windows application from more than just the top-level script? What does cygcheck say about your winpty? You are using the Cygwin compiled version, correct? By "say", I assume you mean the output from running "cygcheck winpty"? This is what I get: Yes that is what I meant by my colloquial phrase. Found: C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe C:\cygwin64\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.dll C:\Windows\system32\ADVAPI32.dll C:\Windows\system32\msvcrt.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\USER32.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\LPK.dll C:\Windows\system32\USP10.dll I see nothing wrong here, time to ask winpty community what might be wrong. -- cyg Simple -- 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/5/2018 1:33 PM, David Karr wrote: On Wed, Dec 5, 2018 at 9:43 AM cyg Simple wrote: Your query got me interested in looking and I believe that winpty needs to be at the front of all the commands so that it can communicate with mintty properly. To overcome the need to remember you could add an alias to execute the command; `alias FOO="winpty FOO"'. Sigh. What a mess. I can't get this to work. It was easy enough when a single script has to execute "kubectl", having "winpty" prefix that call, but I'm trying to write a script that calls that other script, and even in a pipeline. If I have "winpty" prefix the call to the script that calls "kubectl", it says: winpty: error: cannot start '...': Not found in PATH When I changed it so it references the absolute path, it then says "%1 is not a valid Win32 application. (error 0xc1)". So, this makes it clear that winpty can only directly execute Windows applications, which makes sense. So how can I call a Windows application from more than just the top-level script? What does cygcheck say about your winpty? You are using the Cygwin compiled version, correct? -- cyg Simple -- 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/5/2018 10:11 AM, David Karr wrote: On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri wrote: Am 04.12.2018 um 21:41 schrieb David Karr: "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)" I installed a version of "kubectl" for windows, and I use it extensively in Cygwin bash for scripting command-line automation. In general, this works perfectly fine. I even use the same scripting in a Linux VM. I'm seeing an issue with one script that works fine in the Linux VM, but not in Cygwin. The command line is approximately this: kubectl exec pod -c container -i -t -- grep "string" stuff.properties 2>&1 | sed -e 's/^propname=//' In Linux, this works perfectly fine. In Cygwin, it says "stdout is not a tty". I haven't updated my local Cygwin installation for quite a while. I'd prefer not to, unless there is a strong chance this kind of thing would be fixed. as kubectl is not a Cygwin program, it is not aware of cygwin pty. You can try to use winpty to overcome the problem. https://github.com/rprichard/winpty It turns out that not only had I already used winpty for similar functionality, it was actually in place in the pipeline when I tried to do this. When I turned on debugging output, it showed that kubectl was already being wrapped by winpty when it reported "stdout is not a tty". However, this was one shell script wrapper deeper than I usually call it. Does it matter whether winpty is called from the shell script I'm calling, or from the script being called by the script I'm calling? Your query got me interested in looking and I believe that winpty needs to be at the front of all the commands so that it can communicate with mintty properly. To overcome the need to remember you could add an alias to execute the command; `alias FOO="winpty FOO"'. -- cyg Simple -- 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/4/2018 3:52 PM, Marco Atzeri wrote: Am 04.12.2018 um 21:41 schrieb David Karr: "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)" I installed a version of "kubectl" for windows, and I use it extensively in Cygwin bash for scripting command-line automation. In general, this works perfectly fine. I even use the same scripting in a Linux VM. I'm seeing an issue with one script that works fine in the Linux VM, but not in Cygwin. The command line is approximately this: kubectl exec pod -c container -i -t -- grep "string" stuff.properties 2>&1 | sed -e 's/^propname=//' In Linux, this works perfectly fine. In Cygwin, it says "stdout is not a tty". I haven't updated my local Cygwin installation for quite a while. I'd prefer not to, unless there is a strong chance this kind of thing would be fixed. as kubectl is not a Cygwin program, it is not aware of cygwin pty. You can try to use winpty to overcome the problem. https://github.com/rprichard/winpty Or grab the source and try to build a Cygwin version. Looks like there are a number of dependencies though but primarily golang. -- cyg Simple -- 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: Bash heredoc on FD 3
On 12/4/2018 7:13 AM, Houder wrote: On Sun, 02 Dec 2018 10:43:17, Steven Penny wrote: Using this file: $ cat hello.sh awk -f /dev/fd/3 3< File to which symlnk /dev/fd/3 refers has "gone"; different from Linux, where the file is "deleted", but still "available". (note: dash uses a different implementation) Dash is faster in processing the data but can be made to fail if you add -d to the ls commands you're using. -- cyg Simple -- 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: Bash heredoc on FD 3
On 12/3/2018 10:43 AM, cyg Simple wrote: On 12/2/2018 1:43 PM, Steven Penny wrote: Using this file: $ cat hello.sh awk -f /dev/fd/3 3< awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or directory) I tried also with Debian and both Dash and Bash work as expected. What is causing Cygwin Bash to fail here? Same for me and interestingly: $ ls -ld /dev/fd/* ls: cannot access '/dev/fd/3': No such file or directory ls: cannot access '/dev/fd/31': No such file or directory lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/1 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/2 -> /dev/pty2 And: $ dash -c '/bin/ls -l /dev/fd/' total 0 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 1 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 2 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 3 -> /proc/27356/fd $ dash -c '/bin/ls -l /dev/fd/' total 0 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 1 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 2 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:51 3 -> /proc/18740/fd So in Bash the process is no longer available. Adding -d to the above: $ dash -c '/bin/ls -ld /dev/fd/*' /bin/ls: cannot access '/dev/fd/3': No such file or directory lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/1 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/2 -> /dev/pty2 -- cyg Simple -- 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: Bash heredoc on FD 3
On 12/2/2018 1:43 PM, Steven Penny wrote: Using this file: $ cat hello.sh awk -f /dev/fd/3 3< awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or directory) I tried also with Debian and both Dash and Bash work as expected. What is causing Cygwin Bash to fail here? Same for me and interestingly: $ ls -ld /dev/fd/* ls: cannot access '/dev/fd/3': No such file or directory ls: cannot access '/dev/fd/31': No such file or directory lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/1 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:39 /dev/fd/2 -> /dev/pty2 -- cyg Simple -- 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: libssh2 1.8.0, 1.8.1-20181201(test)
On 12/1/2018 7:02 PM, Heavenly Avenger wrote: On 12/1/2018 9:17 PM, Ken Brown wrote: On 12/1/2018 5:48 PM, Heavenly Avenger wrote: I have manually added "test:" lines to 1.8.1-20181201 with the following script, because I believe this is the only way to tag packages as test/unstable: Use 'cygport foo.cygport pkg-test' instead of 'cygport foo.cygport pkg'. Ken Thank you! Divines bless your kind heart! Puns aside, I've just re-generated the 1.8.1 test package with: cygport libssh2.cygport prep compile install package-test And re-uploaded them to the link in the original email (https://avenger.ws/cygwin/x86_64/libssh2) I simply had no idea I could do that, and unfortunately the puny search attempts I made didn't return this possibility. The cygport usage strings give you package-test as an option. To see the usage strings you most always usage --help to see it or sometimes just executing the program incorrectly will give you the usage. In this case either: cygport --help OR cygport will give you the usage. -- cyg Simple
Re: Cygwin Git with Windows paths
On 11/27/2018 3:11 AM, Marco Atzeri wrote: Cool down please. If you need a git that understand windows paths you should not use the cygwin one. It is this stance that caused MSYS to exist. It is this stance that caused the git developers to choose MSYS for the Windows support model. However, it is correct to say, when in Cygwin use POSIX paths as Windows paths are not warranted to work. The \ character may even cause a `\t' to be or a \m to be a , etc. as that is what is described by POSIX. And 'C:/' in POSIX speak refers to a directory in the current working directory named `C:'. But Cygwin tries to be nice and play with the strings beginning with [A-Za-z] followed by : as a device designation but if it works it works and if it doesn't work it doesn't work; you must live with the results and work (around) them as needed. To work around the issues I often use /etc/fstab to create a mount point for a troublesome Windows style path. I can then use the POSIX format to alleviate the issue. -- cyg Simple -- 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: tar cygwin64/ from old to new computer?
On 11/27/2018 10:12 AM, Andrey Repin wrote: Greetings, Gilbert St. Firmin! On: Sun, 25 Nov 2018 18:08:35 +0100, Hans-Bernhard Bröker wrote: You're overlooking a chicken-and-egg problem there: your new computer has no 'tar' to unpack that file. Could the native Windows version of 7-zip be used on both old and new computers? Also, perhaps the Windows Image Format (WIM) could be used instead, presuming UUIDs would not be an issue if both computers shared identical machine names and accounts. Just curious. Don't be, just install Cygwin the recommended way. The task of system administrator is to solve problems, not to create them. And trying to circumvent regular installation process is sure asking for trouble one way or another. In other words, try it, if it works for you great, if it doesn't don't come here with your problems until you've attempted the described process. -- cyg Simple -- 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: No thread safety in clock_gettime (hires_ns::prime)
On 11/26/2018 12:01 PM, Corinna Vinschen wrote: On Nov 23 11:27, James E. King III wrote: Using 32-bit cygwin that I set up yesterday. Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause. When exactly will it be a lost cause for Cygwin? I.E. Are you planning to discontinue maintenance for 32bit anytime soon? Anyone needing it could continue to use the existing distribution. I ask only because I agree with your statement that it is a lost cause. -- cyg Simple -- 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: Cygwin Git with Windows paths
On 11/18/2018 1:07 AM, Steven Penny wrote: Cygwin Git can clone with Unix form paths: $ git clone git://github.com/benhoyt/goawk /tmp/goawk Cloning into '/tmp/goawk'... remote: Enumerating objects: 330, done. However it fails with Windows form: $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk' Cloning into 'C:\cygwin64\tmp\goawk'... fatal: Invalid path '/home/Steven/C:\cygwin64\tmp\goawk': No such file or directory and mixed form: $ git clone git://github.com/benhoyt/goawk C:/cygwin64/tmp/goawk fatal: Invalid path '/home/Steven/C:/cygwin64': No such file or directory Note that other Cygwin programs work fine with these forms: $ ls 'C:\cygwin64' bin Cygwin.ico dev home sbin usr Cygwin.bat Cygwin-Terminal.ico etc lib tmp var This causes problems for any non-Cygwin tools that might call Git: http://github.com/golang/go/issues/23155 What exactly are you trying to solve by your query? The golang issue you point to is marked as resolved and many suggestions similar to the ones you've been given in this query exist in it; including a go script to convert the strings on the command line. I probably would use a similar method with a bash script but calling cygpath. Good luck, -- cyg Simple -- 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: Cygwin Aisleriot - missing cyggdkcardimage-0.dll
On 11/17/2018 7:17 AM, Mike Yates wrote: Hi guys This is a long shot but does anyone have an archive of that DLL, required by sol.exe in aisleriot-1.4.0.4-2.tar.bz2 of Feb 2003, still up on SourceForge? As it is nowhere in any recent Cygwin collection, perhaps it should have been included in the tarball? I have tried emailing the Cygwin Aisleriot authors, Jonathan Blandford, Felix Bellaby and Rosanna Yuen but all three emails (of 2001) bounce now, of course. Does anyone know where they are now? I don't think it exists. The only thing Google provides is a reference to this thread[1]. [1] https://cygwin.com/ml/cygwin/2018-05/msg00146.html -- cyg Simple -- 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: perhaps not so minor typo in cygwin.com
On 11/10/2018 3:20 AM, Corinna Vinschen wrote: On Nov 9 20:09, Denis Excoffier wrote: Hello, In http://cygwin.com, please modify: The most recent version of the Cygwin DLL is 2.11.0. into The most recent version of the Cygwin DLL is 2.11.2. Done. Thanks for the heads-up. I was going to suggest maybe perhaps using a computed string for the text but then I run [1] and it doesn't find 2.11.2. Why? [1] https://sourceware.org/cgi-bin/search.cgi?cmd=Search!=short=extended=no=all=10=%22Updated:+Cygwin%22=0=0==/ml/cygwin-announce/%25=2221=sub=DRP -- cyg Simple -- 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: long rebasing delay when updating is nuts
On 11/7/2018 3:48 PM, Kent Dorfman wrote: The subject pretty much says it. This deficiency has been mentioned a few times online before (based on web search), but it seems to be a non-issue with the cygwin project folks. It pretty much depends on how many files need to be updated. Patches are always welcome for review that help improve what you find as a deficiency. Though I'm guessing you have no round tuits to apply toward such a patch since your message complaining about the time it takes to do an update was so terse. Good luck on working a patch. -- cyg Simple -- 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: cygport fails with package starting with number
On 11/7/2018 1:20 PM, Marco Atzeri wrote:
It seems that the behaviour of cygport is changed recently
and rebuilding the 4ti2 package fails on the name 4ti2.
Or is a bash change ?
Maybe this ...
cygport --debug 4ti2.cygport package
>>> 4ti2-debuginfo-1.6.7-2.tar.xz
+ mkdir -p
/cygdrive/d/cyg_pub/devel/4ti2/prova/4ti2-1.6.7-2.x86_64/dist/4ti2/4ti2-debuginfo
/usr/share/cygport/lib/pkg_pkg.cygpart: line 197:
Line 197 of this file is the creation of the debuginfo tar file.
4ti2_debuginfo_CONTENTS: bad substitution
This is coming from the ${!dbg_contents_var} syntax. What is this input
to tar supposed to be? The "bad substitution" is because the variable
isn't an integer.
--
cyg Simple
--
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: Problem with opengrads
On 11/7/2018 2:00 PM, Jose Daniel Baez Noguera wrote: Hi, I have a problem with the program The message of failure is: 1 [main] opengrads 13264 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Sorry for the english. This is a warning. See https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings for suggestions. Follow-up with the distributor of your software. -- cyg Simple -- 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: bzip.org
On 9/21/2018 11:33 AM, cyg Simple wrote: > Sadly our beloved http://www.bzip.org has hit the bit bucket. Does > anyone know where upstream support for bzip2 went? I've created a SF project, uploaded the 1.0.6 pristine source file and created a SF git repository for that source. I would like others to help manage this project, anyone interested please contact me directly. I didn't think this precious source code should just lay in wait for other wolves and just took the initiative to keep it publicly available and open. I don't think we should worry with a web URL at the moment since SF provides a wiki with its projects. In 3 days the uploaded file has been downloaded 15 times so there is definitely interest it this project. -- cyg Simple -- 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: pinentry-curses not available?
On 11/2/2018 3:47 PM, David Dombrowsky wrote: > I don't see a way to download `pinentry-curses` or `pinentry-tty` for > use with `gpg-agent` (using gnupg v2). Are these not maintained? Or > am I just looking at the wrong sources? > > In any case, I got pinentry-1.1.0 to compile against a cygwin-supplied > version of ncurses, and it mostly works (you still need to tell it to > not detach from the tty, not sure what's up with that). This is very > useful when signing git commits, and removing the need for a graphical > console just to input my gpg passphrase. I see from [1] that pinentry-w32 exists which is a replacement for pinentry-curses which was in [2]. Now both of these are version 1.0.0. Based on [3] Marco Atzeri can give or point to reasoning. [1] https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpinentry%2Fpinentry-1.0.0-2=pinentry [2] https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpinentry%2Fpinentry-1.0.0-1=pinentry [3] https://cygwin.com/cygwin-pkg-maint -- cyg Simple -- 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: problem with my Grads Aplication
On 11/2/2018 10:15 AM, Andrey Repin wrote: > Greetings, john doe! > >> On 11/2/2018 8:11 AM, Marco Atzeri wrote: >>> Am 02.11.2018 um 07:32 schrieb john doe: >>>> On 11/2/2018 2:58 AM, Rafika Sri Nurjannah wrote: >>>>> Couldn't compute FAST_CWD pointer. to Grads >>>>> >>>> >>>> https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings >>>> >>> >>> Joe, >>> if you do not reply also to the sender, it is not very useful >>> as it is almost sure that they are not in the mailing list. >>> > >> Marco, is there anyway to know with out guessing if the OP is subscribed >> to the list? > > No, but in case of these mails, you could guess with high degree of certainty. > Normally, I just reply to all, and if somebody don't want to receive > duplicates, they can set reply-to back to the list for list mails. > When I "Reply All" using my T'bird I only get the list mail address regardless. The reply-to is already munged. -- cyg Simple -- 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: problem with my Grads Aplication
On 11/2/2018 3:55 AM, john doe wrote: > On 11/2/2018 8:11 AM, Marco Atzeri wrote: >> Am 02.11.2018 um 07:32 schrieb john doe: >>> On 11/2/2018 2:58 AM, Rafika Sri Nurjannah wrote: >>>> Couldn't compute FAST_CWD pointer. to Grads >>>> >>> >>> https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings >>> >> >> Joe, >> if you do not reply also to the sender, it is not very useful >> as it is almost sure that they are not in the mailing list. >> > > Marco, is there anyway to know with out guessing if the OP is subscribed > to the list? John, there is not a way to know other than to say that these one off FAQ are most likely a candidate for not being on the list. Also unfortunately you must copy and paste the sender's address due to reply-to munging created by the list software. -- cyg Simple -- 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: Stumbled upon relative name resolution across symlinks
On 11/1/2018 6:39 PM, Andrey Repin wrote: > Greetings, All! > > $ pwd > /home/anrdaemon/Documents/NIX/CA-tutorial/test > > $ ls -ld bin ca-profile > lrwxrwxrwx 1 anrdaemon None 61 ноя 2 01:15 bin -> > /home/anrdaemon/Documents/NIX/CA-tutorial/svn-working/scripts > -rwx--x--x 1 anrdaemon None 588 дек 24 2017 ca-profile > > $ cat bin/../ca-profile > cat: bin/../ca-profile: No such file or directory > Try ls `bin/../` You'll see a listing of /home/anrdaemon/Documents/NIX/CA-tutorial/svn-working/. > $ cat $( realpath -Le "bin/../ca-profile" ) > # @version $Id: ca-profile 82 2014-02-08 05:24:12Z anrdaemon $ > ... > > In simpler words, the bin directory is symlinked from elsewhere. > realpath -Le resolves correctly, but all other filesystem functions fail. > > I vaguely recall that there was some discussion on the matter, but search > returns too many results, can't read them all. > My question, basically: is this expected way of things? The answer is yes it is expected and works the same on Linux. > If so, I'd just workaround it. Sad but doable. Don't be sad just do it. ;p -- cyg Simple -- 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: cblas library missing in liblapack-devel
On 11/1/2018 3:54 PM, Falk Tannhäuser wrote: > The package liblapack-devel (LAPACK library for linear algebra > operations, see > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fliblapack-devel%2Fliblapack-devel-3.8.0-1=cblas) > > contains the header file usr/include/cblas.h (among others), library > files as usr/lib/libblas.a, usr/lib/liblapack.a etc. as well as the file > usr/lib/pkgconfig/cblas.pc . The command `pkg-config --libs cblas` > returns "-lcblas". However, no library file libcblas.a is present, causing > building of some software packages depending on this library to fail. > On the other hand, the Win64 toolchain package mingw64-x86_64-cblas (see > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmingw64-x86_64-cblas%2Fmingw64-x86_64-cblas-3.7.0-1=cblas) > does comport the library > usr/x86_64-w64-mingw32/sys-root/mingw/lib/libcblas.dll.a . > Am I missing something during Cygwin installation? Looks like a lapack-devel packaging issue. -- cyg Simple -- 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.exe: How do I download sources for just ONE package when using setup-x86 from the command-line?
On 11/1/2018 12:37 PM, John Doucette wrote: > Hi all, > > My current setup-x86 is version 2.893. > Cygwin is not installed yet, so I am running setup-x86.exe from within > PowerShell on Win7. > > PS C:\> .\setup-x86.exe -V > PS C:\ > Cygwin setup 2.893 > > First I run setup to download all things Devel using: > > PS C:\> .\setup-x86.exe -D -l C:\X027-001-011 -O -s > http://mirrors.kernel.org/sourceware/cygwin -f -C Devel -q > > This correctly downloads all Devel stuff and dependencies as expected, > including the boost-build package. Then I want to download the sources for > just boost-build. Since the dependencies for boost-build have already been > resolved above I use: > > PS C:\> .\setup-x86.exe -D -l C:\X027-001-011 -O -s > http://mirrors.kernel.org/sourceware/cygwin -f -I -P boost-build -q > > This does download the sources for package boost-build, but ALSO downloads > the sources for ALL of the dependencies of boost-build! I.e. sources for > cygwin, gcc, bash, ... etc. The same thing happens if -Y is added to the > command as below. > > PS C:\> .\setup-x86.exe -D -l C:\X027-001-011 -O -s > http://mirrors.kernel.org/sourceware/cygwin -f -Y -I -P boost-build -q > > Trying to directly download the src package in question doesn't work either, > as in: > > PS C:\> .\setup-x86.exe -D -l C:\X027-001-011 -O -s > http://mirrors.kernel.org/sourceware/cygwin -f -I -P boost-build-src -q > > I can accomplish what I want if I use the setup-x86 gui for the second part > of the operation. I.e. First run the first command above to get all of latest > Devel. > > PS C:\> .\setup-x86.exe -D -l C:\X027-001-011 -O -s > http://mirrors.kernel.org/sourceware/cygwin -f -C Devel -q > > Then start up the setup-x86.exe ui. Choose to download only from the same > mirror to the same local folder. Under the View pulldown, select Category. > Click on the circle symbol by All cycling around through Install -> Reinstall > -> Uninstall -> Default resulting in all items being marked as skipped. > Expand the Devel category and select boost-build 1.66.0-1. Then also tick > off the boost-build src box. Select Next, Next ... until download starts. > Only the boost-build sources are downloaded. Make it easy on yourself; download the -src package directly from the mirror release directory. You'll need cygport package to build it. -- cyg Simple -- 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: Cross build of newlib-cygwin release tag cygwin-2_11_1-release.
On 10/30/2018 5:24 PM, cyg Simple wrote: > > > On 10/30/2018 4:32 PM, Corinna Vinschen wrote: >> On Oct 30 16:01, Earnest Boyd wrote: >>> On 10/30/2018 3:31 PM, cyg Simple wrote: >>>> On 10/30/2018 11:03 AM, cyg Simple wrote: >>>>> PING... Does no one have an idea? >>>>> >>>>> On 10/29/2018 12:09 PM, cyg Simple wrote: >>>>>> I'm trying to cross build the Cygwin source on a VirtualBox Arch Linux >>>>>> with GCC-7.3.0 and Binutils 2.31. The process I am using clones the >>>>>> master repository and then does a checkout of the release tag. Here is >>>>>> the configure command from the head of the config.log. >>>>>> >>>>>> ``` >>>>>> $ head /home/cygsimple/src/sf/build/newlib-cygwin/build/config.log | >>>>>> grep newlib-cygwin-2.11.1/configure >>>>>> $ >>>>>> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure >>>>>> --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-linux-gnu >>>>>> --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var >>>>>> --localstatedir=/var >>>>>> ``` >>>>>> >>>> >>>> I tried this on the master Cygwin and get the same error. >>>> >>>> ``` >>>> $ head config.log | grep newlib-cygwin >>>> $ >>>> /usr/local/src/cygsimple/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure >>>> --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-cygwin >>>> --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var >>>> --localstatedir=/var >>>> ``` >>>> >>>> What configuration item should I add to avoid this? >>>> >>> >>> Patching winsup/cygwin/Makefile.in to remove -Werror allows this to >>> build though the warnings continue. But how does Corinna do this? >> >> No special settings. But this: >> >>>>>> c++wrap -pedantic -fomit-frame-pointer -m64 -O2 -g -fno-rtti >> ^ >> Looks weird. We don't use neither pedantic nor m64 and from the above >> it seems you didn't specify them explicitely either. So where are they >> coming from? "pedantic" may explain the error. What linux-cygwin cross >> gcc are you using? Looks like you're not using the right one. > > It's specified in winsup/cygwin/Makefile.in > Well no, -pendantic -fomit-frame-pointer -m64 is set in a CFLAGS environment variable. I can fix that. > The cross is my private build but that doesn't matter, the issue happens > in a native build as well. > -- cyg Simple -- 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: Cross build of newlib-cygwin release tag cygwin-2_11_1-release.
On 10/30/2018 4:32 PM, Corinna Vinschen wrote: > On Oct 30 16:01, Earnest Boyd wrote: >> On 10/30/2018 3:31 PM, cyg Simple wrote: >>> On 10/30/2018 11:03 AM, cyg Simple wrote: >>>> PING... Does no one have an idea? >>>> >>>> On 10/29/2018 12:09 PM, cyg Simple wrote: >>>>> I'm trying to cross build the Cygwin source on a VirtualBox Arch Linux >>>>> with GCC-7.3.0 and Binutils 2.31. The process I am using clones the >>>>> master repository and then does a checkout of the release tag. Here is >>>>> the configure command from the head of the config.log. >>>>> >>>>> ``` >>>>> $ head /home/cygsimple/src/sf/build/newlib-cygwin/build/config.log | >>>>> grep newlib-cygwin-2.11.1/configure >>>>> $ >>>>> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure >>>>> --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-linux-gnu >>>>> --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var >>>>> --localstatedir=/var >>>>> ``` >>>>> >>> >>> I tried this on the master Cygwin and get the same error. >>> >>> ``` >>> $ head config.log | grep newlib-cygwin >>> $ >>> /usr/local/src/cygsimple/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure >>> --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-cygwin >>> --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var >>> --localstatedir=/var >>> ``` >>> >>> What configuration item should I add to avoid this? >>> >> >> Patching winsup/cygwin/Makefile.in to remove -Werror allows this to >> build though the warnings continue. But how does Corinna do this? > > No special settings. But this: > >>>>> c++wrap -pedantic -fomit-frame-pointer -m64 -O2 -g -fno-rtti > ^ ^^^^ > Looks weird. We don't use neither pedantic nor m64 and from the above > it seems you didn't specify them explicitely either. So where are they > coming from? "pedantic" may explain the error. What linux-cygwin cross > gcc are you using? Looks like you're not using the right one. It's specified in winsup/cygwin/Makefile.in The cross is my private build but that doesn't matter, the issue happens in a native build as well. -- cyg Simple -- 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: Grads Problem
On 10/30/2018 3:15 PM, rafaela magalhaes wrote: > Hi, > > I had this error when i tried to start grads in my computer. Could you help > me? > > * 1 [main] grads 7472 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to* > *the public mailing list cygwin@cygwin.com * > *Starting X server under C:\OPENGR~1\Contents\Resources\Xming* > *Starting grads under C:\OPENGR~1\Contents\Cygwin\Versions\202OGA~1.2\i686 > ...* > See https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings Be sure to follow up with the distributor of grads. -- cyg Simple -- 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: Cross build of newlib-cygwin release tag cygwin-2_11_1-release.
On 10/30/2018 11:03 AM, cyg Simple wrote: > PING... Does no one have an idea? > > On 10/29/2018 12:09 PM, cyg Simple wrote: >> I'm trying to cross build the Cygwin source on a VirtualBox Arch Linux >> with GCC-7.3.0 and Binutils 2.31. The process I am using clones the >> master repository and then does a checkout of the release tag. Here is >> the configure command from the head of the config.log. >> >> ``` >> $ head /home/cygsimple/src/sf/build/newlib-cygwin/build/config.log | >> grep newlib-cygwin-2.11.1/configure >> $ >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure >> --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-linux-gnu >> --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var >> --localstatedir=/var >> ``` >> I tried this on the master Cygwin and get the same error. ``` $ head config.log | grep newlib-cygwin $ /usr/local/src/cygsimple/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-cygwin --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var --localstatedir=/var ``` What configuration item should I add to avoid this? >> With this I get the following errors when compiling _cygwin_crt0_common.cc: >> >> ``` >> c++wrap -pedantic -fomit-frame-pointer -m64 -O2 -g -fno-rtti >> -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing >> -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD >> -Werror -fmerge-constants -ftracer -mcmodel=small -std=gnu++98 -c -o >> _cygwin_crt0_common.o >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc >> In file included from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:104:0, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/wchar.h:12:2: >> error: #include_next is a GCC extension [-Werror] >> #include_next >> ^~~~ >> In file included from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/cygtls.h:284:0, >> from ./globals.h:5, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/ntdll.h:1671:60: >> error: use of C++11 long long integer constant [-Werror=long-long] >> fbi.LastWriteTime.QuadPart = fbi.ChangeTime.QuadPart = 0LL; >> ^~~ >> In file included from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:25: >> , >> from ./globals.h:7, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/security.h:112:51: >> error: ISO C++ does not permit named variadic macros >> [-Werror=variadic-macros] >> #define MKSID(name, comment, authority, count, rid...) \ >>^~~ >> In file included from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:28: >> , >> from ./globals.h:7, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/cygwait.h:42:31: >> error: use of C++11 long long integer constant [-Werror=long-long] >>li_howlong.QuadPart = -(1ULL * howlong); >>^~~~ >> In file included from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:80: >> , >> from >> /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/l
Re: trans can not work
On 10/30/2018 11:06 AM, X.y. Xu wrote: > Hi, > When I want to use trans to get or trans some files on PC end. > There is something wrong with it. > Following is the jumping out message: > > C:\trans>trans -g cnpn5828p > 11 [main] trans 5600 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.com<mailto:cygwin@cygwin.com> > > C:\trans>trans -g cnpn5828p > 11 [main] trans 5600 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.com<mailto:cygwin@cygwin.com> > See https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings Be sure to follow up with the distributor of trans. -- cyg Simple -- 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: Cross build of newlib-cygwin release tag cygwin-2_11_1-release.
PING... Does no one have an idea? On 10/29/2018 12:09 PM, cyg Simple wrote: > I'm trying to cross build the Cygwin source on a VirtualBox Arch Linux > with GCC-7.3.0 and Binutils 2.31. The process I am using clones the > master repository and then does a checkout of the release tag. Here is > the configure command from the head of the config.log. > > ``` > $ head /home/cygsimple/src/sf/build/newlib-cygwin/build/config.log | > grep newlib-cygwin-2.11.1/configure > $ > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/configure > --prefix=/usr --host=x86_64-pc-cygwin --build=x86_64-pc-linux-gnu > --target=x86_64-pc-cygwin --sysconfdir=/etc --sharedstatedir=/var > --localstatedir=/var > ``` > > With this I get the following errors when compiling _cygwin_crt0_common.cc: > > ``` > c++wrap -pedantic -fomit-frame-pointer -m64 -O2 -g -fno-rtti > -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing > -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD > -Werror -fmerge-constants -ftracer -mcmodel=small -std=gnu++98 -c -o > _cygwin_crt0_common.o > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc > In file included from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:104:0, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/wchar.h:12:2: > error: #include_next is a GCC extension [-Werror] > #include_next > ^~~~ > In file included from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/cygtls.h:284:0, > from ./globals.h:5, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/ntdll.h:1671:60: > error: use of C++11 long long integer constant [-Werror=long-long] > fbi.LastWriteTime.QuadPart = fbi.ChangeTime.QuadPart = 0LL; > ^~~ > In file included from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:25: > , > from ./globals.h:7, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/security.h:112:51: > error: ISO C++ does not permit named variadic macros > [-Werror=variadic-macros] > #define MKSID(name, comment, authority, count, rid...) \ >^~~ > In file included from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:28: > , > from ./globals.h:7, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/cygwait.h:42:31: > error: use of C++11 long long integer constant [-Werror=long-long] >li_howlong.QuadPart = -(1ULL * howlong); >^~~~ > In file included from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:80: > , > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/wincap.h:30:3: > error: ISO C++ prohibits anonymous structs [-Werror=pedantic] >}; >^ > In file included from ./globals.h:5:0, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287, > from > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: > /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/cygtls.h:58:2: > error: ISO C++ prohibits anonymous structs [-Werror=pedantic] > }; > ^ > In file included
Cross build of newlib-cygwin release tag cygwin-2_11_1-release.
upport 'long long' [-Werror=long-long] static sem_t *open (unsigned long long hash, LUID luid, int fd, int oflag, ^~~~ /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:666:63: error: ISO C++ 1998 does not support 'long long' [-Werror=long-long] static int getinternal (sem_t *sem, int *sfd, unsigned long long *shash, ^~~~ /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:674:17: error: ISO C++ 1998 does not support 'long long' [-Werror=long-long] unsigned long long hash; ^~~~ /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/thread.h:679:28: error: ISO C++ 1998 does not support 'long long' [-Werror=long-long] semaphore (unsigned long long, LUID, int, sem_t *, int, mode_t, unsigned int); ^~~~ In file included from /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/winsup.h:287:0, from /home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/lib/_cygwin_crt0_common.cc:9: ./globals.h:119:2: error: extra ';' [-Werror=pedantic] }; ^ cc1plus: all warnings being treated as errors make[3]: *** [/home/cygsimple/src/sf/build/newlib-cygwin/src/newlib-cygwin-2.11.1/winsup/cygwin/../Makefile.common:41: _cygwin_crt0_common.o] Error 1 make[3]: Leaving directory '/home/cygsimple/src/sf/build/newlib-cygwin/src/build/x86_64-pc-cygwin/winsup/cygwin' make[2]: *** [Makefile:81: cygwin] Error 1 make[2]: Leaving directory '/home/cygsimple/src/sf/build/newlib-cygwin/src/build/x86_64-pc-cygwin/winsup' make[1]: *** [Makefile:9464: all-target-winsup] Error 2 make[1]: Leaving directory '/home/cygsimple/src/sf/build/newlib-cygwin/src/build' make: *** [Makefile:883: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ``` It appears that c++wrap isn't choosing the correct compiler but how can I tell and change that? -- cyg Simple -- 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: cygwin: how to mount linux FS from cygwin
On 10/26/2018 7:28 AM, hauck.adrian451 wrote: > > mssg@ltmssg ~/sshfs-sshfs-3.5.0/build > $ sshfs > -bash: sshfs: no se encontró la orden > > > Can you help me? > https://superuser.com/questions/1264732/how-to-use-sshfs-on-cygwin -- cyg Simple -- 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: WARNING: Couldn't compute FAST_CWD pointer
On 10/24/2018 10:41 AM, john doe wrote: > On 10/24/2018 4:36 PM, Stephen John Smoogen wrote: >> On Wed, 24 Oct 2018 at 10:32, Ng Wai Kin wrote: >>> >>> Windows 10. >> >> That is not enough information to help anyone here. What software is >> showing this and what is the course you are using it in. The problem >> is that the software needs to be updated and recompiled to work with >> newer Cygwin versions, and whoever is the provider did not change the >> error message to say contact them versus this list. >> > > See also the below URL or the archive of this mailing list:: > > https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings > Including the OP in the distribution. -- cyg Simple -- 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: erro
On 10/23/2018 1:17 PM, Andrey Repin wrote: > Greetings, Lee! > >>> https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings > >> Except that the faq is wrong in this case: >> The solution is simply downloading and running Cygwin Setup ... > >> The solution for programs that come bundled with cygwin1.dll (like jtr >> here) is to replace the old cygwin1.dll > > Which is unlikely to succeed for such an old version. Andrey, it's been cygwin1.dll since Version 1.0 which indicates that every version has been backward compatible API. Replacing only cygwin1.dll shouldn't be a problem. The problem comes from if the software dependent on cygwin1.dll also has changes required for newer versions of Windows. -- cyg Simple -- 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: Multiple problems (probably) starting up new installation
On 10/21/2018 6:24 PM, Michael Enright wrote:
> I have a few files that I want to compile and run in a new Windows 10 setup.
> I setup cygwin64 and copied the files to a subdirectory of my home directory.
> I noticed that my prompt indicated that my home directory was
> "/home/Mike Enright". I decided that in the long run that would be
> bad.
> So I followed a tip from Stack Overflow [1]to use /etc/passwd to fix
> this. Apparently the idea is to map the Windows SID to my desired user
> name "menright" instead of "\"Mike Enright\"".
> And also rename the created home directory accordingly.
> So now I have /home/menright and some files under there and
> /etc/password contains a line that maps an SID to menright.
>
Rather than using /etc/passwd just create another account as menright
and install Cygwin in the global user space. I have 3 accounts on my
system and use three files to login to one or the other one. Advantage
is that you can separate different projects based on user.
#! /bin/bash
cmd /c start `cygpath -w -- "${@//&/^&}"`
#! /bin/sh
start sudosu.bat $1
c:\windows\system32\runas /user:%1 "c:\opt\cygwin64\bin\mintty.exe -e
/usr/bin/bash -il"
exit
sudosu menright
sudosu '"Mike Enright"'
HTH
--
cyg Simple
--
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: Is who -b command available? Need to know when computer was started.
On 10/16/2018 11:36 AM, Peder Sverdrup via cygwin wrote: > Hi, > > I am making a script and need to know when the computer was last booted. > This can be done with > > who -b command. I have installed the minimum cygwin and this command is not > available. > > Which package do I need to install in order to have this command available > (or any other command > > that can tell when the computer was last booted). > You can do an online search[1] to determine which package to install to get a binary. In this case who.exe. [1] https://cygwin.com/cgi-bin2/package-grep.cgi?grep=who.exe=x86_64 -- cyg Simple -- 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: Distributing program compiled with gcc on Cygwin to Windows users
On 10/14/2018 5:20 PM, hacker...@protonmail.com wrote:
> Hello,
>
> I have a program that uses X11/Motif and runs fine, within Cygwin/X on the PC
> it was compiled on.
>
> What is the *minimum* required set of Cygwin libs and any other files I need
> to distribute along with, it to end-users who may just have Windows (and not
> Cygwin) installed?
>
> I appreciate your help.
>
> "ldd " on my program gives these dependencies listed below:
As far as Cygwin is concerned the list can be obtained via `ldd FOO.EXE
| grep /usr/bin'. You can determine what else is needed by the
following rooted procedure. Change ROOTED and FOO.EXE to match what you
desire to name it.
/usr/bin/bash
$ mkdir -p /cygdrive/c/ROOTED/{bin,tmp,home,etc}
$ for FILE in `ldd FOO.EXE | grep /usr/bin`; do
$ cp ${FILE} /cygdrive/c/ROOTED/bin
$ done
CMD.EXE
cd -d c:\ROOTED\bin
FOO.EXE
You should be able to use XMing for the clients X Windows manager but
has already been noted you still need to connect to an X client. You
will need to insure the DISPLAY variable is set appropriately for
FOO.EXE to communicate to the X server in CMD.EXE.
--
cyg Simple
P.S. Remember to follow the license requirements of each of the
distributed packages.
--
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: Cygwin windows won't close
On 10/9/2018 1:22 PM, Ziegelmiller, Lyle(AWF) via cygwin wrote: > > We're using "Symantec Endpoint Protection", Version 14. > > I could see an anti-virus program preventing the execution of a Cygwin > window, but not the closing of one. > If you wait for a few minutes is the result different? If you have a different experience based on time expended then the likelihood of an interfering AV program is greater. -- cyg Simple -- 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 and 'provides:'
On 10/8/2018 12:24 PM, Ken Brown wrote: > On 10/8/2018 11:17 AM, cyg Simple wrote: >> On 10/8/2018 11:05 AM, Ken Brown wrote: >>> Here's an example (modeled on what Fedora does): Cygwin has four >>> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and >>> emacs-w32. Users can install any or all of these if they want to be >>> able to run emacs. The differences are in the UI. These packages don't >>> conflict with one another. >>> >> >> How do they overcome the conflict? > > They use different names for the emacs binaries: emacs-nox.exe, > emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe. The "alternatives" > system then creates a symlink /usr/bin/emacs that resolves to whichever > binary the user wants to use by default. It's been this way for many > years, with no problems. > I assumed that this was the case. But the symlink is a conflict and I assume that if one exists already the package management system would not recreate one or would ask the user if it should be overwritten. >>> If some other package requires an emacs binary, I would like it to be >>> able to require "emacs-bin". [This plays the role of "foo" in my test >>> case.] Then I would like to be able to say that all four emacs packages >>> above provide "emacs-bin". >>> >> >> That's fine but how do an installation of multiple emacs-bin not create >> a conflict? > > "emacs-bin" is not a thing that can be installed. It's simply a name > for a requirement, and that requirement can be met by installing any > package that declares that it provides "emacs-bin". At least that's my > understanding of how it works in package managers like rpm. As I said > at the very beginning, it's quite possible that I'm misunderstanding how > 'provides:' is supposed to work. And I understand that emacs-bin is a pseudo name identifying a class of product the package provides. The RPM system allows for defining Requires, Provides, Conflicts and Obsoletes. The Arch Linux pacman allows for depends, makedepends, checkdepends, optdepends, provides, replaces and conflicts. As you can see other package managers see *conflicts* as an important item because of the global namespace issue. -- cyg Simple
Re: setup and 'provides:'
On 10/8/2018 11:05 AM, Ken Brown wrote:
> On 10/8/2018 10:41 AM, cyg Simple wrote:
>> On 10/7/2018 6:02 PM, Ken Brown wrote:
>>> I've been experimenting with setup's support for the 'provides:' tag, and
>>> it's
>>> not behaving the way I expect [*]. I'm not sure if something in setup's
>>> interface with libsolv needs to be tweaked or if I'm just misunderstanding
>>> how
>>> this should work. Here's what I tried:
>>>
>>
>> Shouldn't there be a need for a 'conflicts:' tag as well?
>
> setup does support a 'conflicts:' tag, but I don't see why I should need
> it here.
>
You might not, others might. See below ...
>>> I created a test repo with packages A, B, and C. I made A require foo (not
>>> a
>>> package), and I made B and C provide foo. The attached script does all this
>>> [**]. I then ran setup and selected A for installation.
>>>
>>
>> So C:foo conflicts with B:foo.
>
> I'm not sure what you mean by C:foo and B:foo. My intention is that
> "foo" is an identifier for a single requirement, which can be provided
> by B or C or both. I explicitly want to allow both to be installed, so
> I don't want B and C to conflict with one another.
"A single requirement" is the issue. B and C both provide foo but the
foo in B and C are different and conflict with one another so which one
is correct to satisfy the package A requirement?
>
> Here's an example (modeled on what Fedora does): Cygwin has four
> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and
> emacs-w32. Users can install any or all of these if they want to be
> able to run emacs. The differences are in the UI. These packages don't
> conflict with one another.
>
How do they overcome the conflict?
> If some other package requires an emacs binary, I would like it to be
> able to require "emacs-bin". [This plays the role of "foo" in my test
> case.] Then I would like to be able to say that all four emacs packages
> above provide "emacs-bin".
>
That's fine but how do an installation of multiple emacs-bin not create
a conflict?
>>> The result was that libsolv simply chose B for installation, and setup
>>> showed
>>> this in the "Confirm" dialog. What I expected was that libsolv would
>>> report a
>>> problem ("A requires foo but no selected or installed packages provide it"),
>>> with two possible solutions ("Install B or C"). Is that expectation
>>> unreasonable?
>>>
>>
>> Not unreasonable but what happens if B:foo is already installed and
>> C:foo is the required because the functionality is slightly different?
>
> See above.
You're above didn't answer the question.
--
cyg Simple
Re: setup and 'provides:'
On 10/7/2018 6:02 PM, Ken Brown wrote:
> I've been experimenting with setup's support for the 'provides:' tag, and
> it's
> not behaving the way I expect [*]. I'm not sure if something in setup's
> interface with libsolv needs to be tweaked or if I'm just misunderstanding
> how
> this should work. Here's what I tried:
>
Shouldn't there be a need for a 'conflicts:' tag as well?
> I created a test repo with packages A, B, and C. I made A require foo (not a
> package), and I made B and C provide foo. The attached script does all this
> [**]. I then ran setup and selected A for installation.
>
So C:foo conflicts with B:foo.
> The result was that libsolv simply chose B for installation, and setup showed
> this in the "Confirm" dialog. What I expected was that libsolv would report
> a
> problem ("A requires foo but no selected or installed packages provide it"),
> with two possible solutions ("Install B or C"). Is that expectation
> unreasonable?
>
Not unreasonable but what happens if B:foo is already installed and
C:foo is the required because the functionality is slightly different?
--
cyg Simple
Re: setup-x86.exe v2.893 has stopped working
On 10/2/2018 2:47 PM, Keith Christian wrote: Keith, your top posting is driving me insane. Please interleave or bottom post and please trim unnecessary content. > 32 bit has been working on this 64 bit machine for the last several > years. This is the setup program, why is it suddenly having problems? > Didn't see anything out of the ordinary in setup.log, setup.log.full, > or in the "cygcheck -s -r -v" output. What debugging info is > available for the setup program itself beyond setup.log* ? What about BLODA updates? It seems that maybe other software may be getting in the way. -- cyg Simple -- 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: bzip.org
On 10/1/2018 4:51 PM, Keith Christian wrote: > Author Julian Seward's Wikipedia page contains nothing out of the > ordinary, works at Mozilla according to the Wikipedia page. > > https://en.wikipedia.org/wiki/Julian_Seward > This says nothing about the status of bzip.org. While it's a good historical biography about Julian, it doesn't give a status of where bzip2 is being managed and the maintainers choice of download for the software. -- cyg Simple -- 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: libglut is missing library for MinGW static linking
On 9/27/2018 9:40 AM, Matt D. wrote: > libglut-devel provides libglut.a and libglut.dll.a but linking libglut.a > with either "-lglut" or "-lglut.dll" both depend on either cygglut-3.dll > or libglut-0.dll respectively when compiling for Cygwin or MinGW. > Unless you've directed the build process to use static libraries the default choice is dynamic. So -lglut and -lglut.dll are both one and the same for -lglut will look for -lglut.dll and use it instead. > I understand that this isn't a big deal for Cygwin binaries as it's not > possible to statically link those executables anyways. But glut has the > ability to link statically and this is of benefit on Windows with MinGW > for convenience and ease of distribution. > > To perform static linking against glut, I have to download > "libfreeglut_static.a" as provided by http://freeglut.sourceforge.net. I > can still use libglut but the static library provides the missing > dependencies to mitigate the need for the shared library. > You could use /usr/lib/libglut.a in the same fashion. You can verify if the library actually is a static library using `nm /usr/lib/libglut.a | grep _imp_`; if any _imp_ return from the grep then this isn't a static library. > I can compile as such: > > i686-w64-mingw32-g++.exe -DFREEGLUT_STATIC main.cpp -lglut > -lfreeglut_static -lgdi32 -lwinmm -lglu32 -lopengl32 -L. -oa.out > > The resulting executable is completely static and stand-alone and does > not require a shared library. The key here is the define > "FREEGLUT_STATIC" along with libfreeglut_static provided from the > freeglut website. > > I don't know what Cygwin's policy is on providing static libraries for > MinGW but this is a very good candidate as it already has all of the > necessary declarations defined. You would need to follow the protocol for getting a package accepted. See the FAQ for that information. -- cyg Simple -- 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: bzip.org
On 9/23/2018 4:15 AM, Roland DOT Schwingel AT onevision DOT com wrote: > Hi, > Please keep on the conversation on the list. > >> Sadly our beloved http://www.bzip.org <http://www.bzip.org/>has hit > the bit bucket. Does >> anyone know where upstream support for bzip2 went? > > It appears that bzip.org is just coming back (as announced on the > valgrind list) > So it is, and from there we find: ``` Find the latest version on SourceForge. Author admin Posted on 22 September 2018 ``` But I can't find it in SourceForge search engine and there is no link pointing to the project at the bzip.org page. -- cyg Simple -- 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: bzip.org
On 9/21/2018 5:59 PM, Henry S. Thompson wrote: > This message > > > http://openbsd-archive.7691.n7.nabble.com/bzip2-now-homeless-bzip-org-for-sale-tp349703p349710.html > > suggests there's a recent mirror at a BSD site, but the newest I can > quickly find is > The fact that it is homeless is of course the concern. Sourceware used to host it but it left there sometime ago but version 1.0.2 still exists and so does that git repository base code. > https://ftp.nluug.nl/OpenBSD/6.3/packages/amd64/bzip2-1.0.6p8.tgz > > Hope this helps a bit. Not really, it isn't an official distribution and the version and file name doesn't match just 1.0.6, I don't know if something changed. The wayback machine has a copy of the file from the original bzip.org site. -- cyg Simple -- 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: bzip.org
On 9/21/2018 1:00 PM, Jeffrey Walton wrote: > On Fri, Sep 21, 2018 at 11:33 AM, cyg Simple wrote: >> Sadly our beloved http://www.bzip.org has hit the bit bucket. Does >> anyone know where upstream support for bzip2 went? > > From https://sourceforge.net/p/valgrind/mailman/message/36403434/ : > >> Unfortunately the bzip.org domain is no longer available to the >> bzip2 project. The plan is to move back to sourceware: >> https://sourceware.org/bzip2/ >> https://sourceware.org/pub/bzip2/ I thought it lived on sourceware.org once upon a time. Unfortunately at the moment the version is at 1.0.2 on sourceware and the most current version is 1.0.6. Your idea in the thread is good but someone already squats on bzip2.org and register.com has parked bzip.org on a search page of links to similar software. You mentioned github in the thread and I see that Enthought has a fork that is 5 years old of 1.0.6, I assume because their using it somewhere. There's one issue that is 3 years old with no response to it complaining about bzdiff leaving empty files in /tmp. -- cyg Simple -- 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
bzip.org
Sadly our beloved http://www.bzip.org has hit the bit bucket. Does anyone know where upstream support for bzip2 went? -- cyg Simple -- 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: Mutt and gpg 1.4
On 9/20/2018 5:53 AM, Marco Atzeri wrote: > Am 20.09.2018 um 11:40 schrieb john doe: > >> >> Reading this thread, and given the fact that "gnupg" is not officially >> supported on Cygwin. > > "officially supported" is almost a useless definition. The only "officially supported" items are the items in the Cygwin git repository. There are packages delivered by named maintainers of upstream packages. > The cygwin gnupg package is built from upstream source with no > additional changes, same as the version installed on > Linux or BSD distributions. > Same for all the other packages I package for cygwin. > And the same for most of the packages delivered by Cygwin. >> That left me with two options: >> >> 1) Use cygwinnized gnupg I use this. >> 2) use gpg4win and enigmail I use this too; there is no T'bird for Cygwin as yet, I don't feel like building it myself and this is the only option you have. >> >> Any thoughts? >> The choice is yours. >> Thanks to "Marco Atzeri" and "Doug Henderson" for their answers and >> "cyg Simple" for the above. You're welcome for the official support. This is how Cygwin and most open source software does that. -- cyg Simple -- 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: Mutt and gpg 1.4
On 9/19/2018 1:59 PM, Doug Henderson wrote: > On Wed, 19 Sep 2018 at 09:52, john doe wrote: > >> How can I remove gpg-1.4.23 and all related dependencies through command >> line or how can I prevent, through command line, 'gpg' from being >> installed when installing mutt? > > I configured both the windows gpg and cygwin gpg to use the same > directory for the database files. > > I have since changed from a desktop to a laptop where I don't have > windows gpg installed, so I can't offer details of how I did it. but I > seem to recall that I either changed to shortcut to windows gpg to > point to the cygwin ~/.gpg directory or made ~/.gpg a symlink to the > windows config and database files. The choice may have depended on the > EOL characters used in the files. > My experience is that the lock files remains with the Windows version and the DB actually became unusable with both versions. I'm guessing the Enigmail plugin to T'bird leaves the connects to GPG open which leaves the lock files in place and therefore causes the issues I experience. There is also an environment variable `GNUPGHOME' you could have set. -- cyg Simple -- 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: Mutt and gpg 1.4
On 9/19/2018 11:51 AM, john doe wrote: > Hi, > > When I install 'mutt' through command line '... --packages mutt ...' it > works. > gpg-1.4.23 is installed as dependency. > > I rather use gpg4win already installed on my host. > > How can I remove gpg-1.4.23 and all related dependencies through command > line or how can I prevent, through command line, 'gpg' from being > installed when installing mutt? > I can say from experience that the two do not mix well. The file permissions and locking between the two distributions of gpg do not lend to coexistence. Rather you should be sure to use an export->import process to keep the two databases in sync. Do not point your Windows GPG port and your Cygwin gpg to the same database. Aside from what I've mentioned in the above, Cygwin mutt is tied to Cygwin gpg via the library interface so you can't get rid of it. You just need to keep the two DB happily in sync which may not be an easy process if both are adding to their DB, you'll need to export both, add the differences to one export and import to both. -- cyg Simple -- 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: regex man-page confusion
On 9/19/2018 3:12 AM, Thomas Wolff wrote: > Am 17.09.2018 um 14:49 schrieb cyg Simple: >> On 9/16/2018 5:52 PM, Thomas Wolff wrote: >>> Thanks; on the system with both packages not installed, man -w regcomp >>> says nothing (rather than "No manual entry..."); >>> `manpath` reveals /usr/share/man:/cygdrive/c/Windows/SUA/usr/share/man >>> and in fact, the man page displayed comes from my SUA installation. But >>> $MANPATH is empty, so what makes cygwin `man` access the SUA man >>> pages??? >>> >> As per [1] you need to check your /etc/man_db.conf file. > I hadn't mentioned that but I had checked it, grep -i sua only found > "usually". > > Found the culprit meanwhile: /cygdrive/c/Windows/SUA/usr/lib was in my > PATH. If I remove it, the SUA man page is not displayed anymore. > So the more specific question: What makes cygwin 'man' check the PATH > (not the LD_LIBRARY_PATH) to find which library and - still - why does > that lead it to SUA man pages??? Maybe in the mandb? Or maybe a ~/.manpath file? Or maybe an alias with -M, --manpath specified? Or a SYSTEM environment variable specified? It's complex and something cached the discovered manuals on PATH. Maybe use of -W and -w can help you determine. -- cyg Simple
Re: regex man-page confusion
On 9/16/2018 5:52 PM, Thomas Wolff wrote: > Thanks; on the system with both packages not installed, man -w regcomp > says nothing (rather than "No manual entry..."); > `manpath` reveals /usr/share/man:/cygdrive/c/Windows/SUA/usr/share/man > and in fact, the man page displayed comes from my SUA installation. But > $MANPATH is empty, so what makes cygwin `man` access the SUA man pages??? > As per [1] you need to check your /etc/man_db.conf file. [1] http://man7.org/linux/man-pages/man5/manpath.5.html -- cyg Simple
Re: Fish shell fails with PermissionDenied on rename file, if Cygwin home directory is a Junction.
On 9/11/2018 11:50 AM, Andrew Schulman wrote: >> On 9/10/2018 12:06 PM, Andrew Schulman wrote: >>>> This report originates from a ticket created on Fish Github account here: >>>> https://github.com/fish-shell/fish-shell/issues/2590 >>>> The issue is, that for some reason, running fish shell fails with >>>> PermissionDenied error if the home directory is a Windows Junction. >>> >>> Unfortunately I don't know how to help with this. fish works fine except in >>> this case where the directory ~/.config/fish is somewhere under a Windows >>> junction. Since I don't know how to solve that, I asked Marcin to report >>> the problem here. >>> >> >> A windows `junction` and not a `symlink`? They're not the same thing. > > Note that I'm not the one who has this problem, but my understanding is > that it happens when the ~/.config/fish is somewhere under a Windows > junction, not a symlink. > >> If you truly mean `junction` then the issue is yours to fix. > > It's true that the user could avoid the problem by changing their file > systems so that ~/.config/fish isn't under a junction point. But I don't > think they should have to do that. > > To me it seems like a bug that rename2() is failing when the target file is > under a junction point. > See https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks to determine if you can find a solution. In general though junctions are treated as symlinks while traveling into the directory. However the file system attributes are specific and required as described in the document I pointed to above. -- cyg Simple -- 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: Fish shell fails with PermissionDenied on rename file, if Cygwin home directory is a Junction.
On 9/10/2018 12:06 PM, Andrew Schulman wrote: >> This report originates from a ticket created on Fish Github account here: >> https://github.com/fish-shell/fish-shell/issues/2590 >> The issue is, that for some reason, running fish shell fails with >> PermissionDenied error if the home directory is a Windows Junction. > > Unfortunately I don't know how to help with this. fish works fine except in > this case where the directory ~/.config/fish is somewhere under a Windows > junction. Since I don't know how to solve that, I asked Marcin to report > the problem here. > A windows `junction` and not a `symlink`? They're not the same thing. If you truly mean `junction` then the issue is yours to fix. -- cyg Simple -- 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: Advice on setting Cygwin build parameters for OpenSC.
On 9/6/2018 12:25 PM, Csaba Raduly wrote:
> Hi Andrey,
>
> On Thu, Sep 6, 2018 at 3:59 PM, Andrey Repin wrote:
>> Greetings, dwhobrey!
>>
>>> Thank you for the feedback.
>>> WND would be _WIN32 builds.
>>
>> If you are going for native builds, why using Cygwin in the first place?
>> If you still want to use Cygwin for building, you have to install
>> cross-compilers and properly specify target host.
>
> In OpenSC's build system (configure.ac), the Cygwin-specific parts
> are 10-11 years old.
> "cygwin native = yes" means the old-style Mingw build ( -mno-cygwin )
The -mno-cygwin has been dead for a few several years now. The option
is no longer available in current GCC. You now install the
{x86_64,i686}-w64-mingw32 cross compilers and specify
--host={x86_64,i686}-w64-mingw32 when you configure.
> to create native Win32 programs/libraries,
> whereas "cygwin native = no" means generating Cygwin programs/libraries
> (with CRYPTOKI_FORCE_WIN32 being forcibly - and probably incorrectly -
> defined).
>
So to get Cygwin specific build you just don't specify the --host option.
The change to configure.ac and supporting .m4 files is up to you. But
-mno-cygwin isn't available if you plan to use current GCC regardless.
--
cyg Simple
--
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: Bug Report: Regression in Cygwin 2.11.0-1
On 9/1/2018 5:52 PM, Andrey Repin wrote: > Greetings, David Allsopp! > >>> In terms of this OCAML build system problem: >>> >>> Please fix your build system. Do not mix POSIX and Win32 paths, use POSIX >>> paths only. Backslashes are *no* drop-in replacement for slashes. > >> The "problem" for us is more subtle than this. The program which is >> generating that path is not a Cygwin executable, so it is correctly >> combining a path it has been supplied (the ../stdlib which has been supplied >> via Cygwin's make) with a filename, so it uses a backslash. It's been on my >> TODO for years to enhance to understand that the program it's supplying the >> path back to is a Cygwin executable and so sort it out properly but, well, >> we're a small number of maintainers! That said, WSL is forcing us to address >> it properly... > > You CAN just send back forward slashes. Windows don't care. > If any program would choke, it would be that program's problem after all. Certainly not "that program's problem". The problem becomes mine and yours as we've not followed the design of the program. While Windows at the moment doesn't care there is always the possibility that some fix could break that since the documentation states to use \ in paths and not /. So while we "CAN just send back forward slashes" we need to be prepared for the outcome if something changes in an update to the OS and breaks the assumptions based on observed behavior rather than the documented behavior. -- cyg Simple -- 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: error in "cygpath" behavior
On 8/31/2018 4:57 AM, Corinna Vinschen wrote: > On Aug 30 21:37, Steven Penny wrote: >> It is my understanding that given relative input, "cygpath" shall produce >> relative output unless given "-a" option. However I noticed a discrepancy. >> These >> are all correct: >> >>$ cygpath . >>. >> >>$ cygpath .. >>.. >> >>$ cygpath -w . >>. >> >> This is not: >> >>$ cygpath -w .. >>C:\cygwin64\home\ > > Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally > disagree. The path is always convert to absolute at this point in favor > of correct output. There's also the additional restriction (though > not in this case) that relative Windows paths must not be longer than > MAX_PATH (260) chars. > > I'm certainly open to patches to the underlying cygwin_conv_path > function to change the Windows path to relative if possible. Don't forget the possibility that '..' points to a symlink which Windows will not understand. $ mkdir -p /foo/baz $ ln -s /foo /bar $ cd /bar/baz $ cygpath -w .. -- cyg Simple -- 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: "build-essential" metapackage [WAS: FW: gecko Segmentation fault when compiling]
On 8/29/2018 6:01 AM, Andrey Repin wrote: > > I think we need a "build-essential" metapackage. > I would suggest base-devel as the name of the metapackage. But what exactly should that include? Should there be more than one metapackage that adds more complex tools? -- cyg Simple -- 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: FW: gecko Segmentation fault when compiling
On 8/26/2018 11:28 AM, Marco Atzeri wrote: > Am 26.08.2018 um 16:54 schrieb tl...@twcny.rr.com: >> >> Can you test with just >> PATH="/usr/local/bin:/usr/bin/:/usr/lib/lapack" >> to exclude other programs ? >> >> I just tried that. Same problem. >> >> #2 you have installed every cygwin package including all >> debuginfo packages. Why ? >> >> I'd rather have it and not need it than need it and not have it. > > a bit extreme as solution. you are just making everything slower > and heavier then needed. > Especially when you can add it if you need it. Every path in the list is searched at times so you're slowing down the responses when the PATH is extreme. -- cyg Simple -- 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: incompat in cygwin choice of using '+' as domain and user separator.
On 8/22/2018 6:36 PM, L A Walsh wrote: > Ran in to this trying to use tar to store acls and xattrs: > >> tar caf lawbins.tar scripts scripts- bin > tar: miner.js: Warning: Cannot acl_to_text: Invalid argument > tar: run-crons.sys: Warning: Cannot acl_to_text: Invalid argument > tar: smallprof.out: Warning: Cannot acl_to_text: Invalid argument > tar: tmon.out: Warning: Cannot acl_to_text: Invalid argument > tar: ubytes_to_utf8.new: Warning: Cannot acl_to_text: Invalid argument > > examining one of these: > >> find bin -name tmon.out > bin/tmon.out > >> lsacl bin/tmon.out > [u::rwx,g::rwx,o:r-x,u:Unknown+User:rwx,g:Unknown+Group:rwx,g:Administrators:rwx,g:Bliss\Domain > Admins:rwx,m:rwx/] bin/tmon.out > > I tried tar in an existing dir: > >> mkdir test >> tar caf test.tar test >> ll test > total 0 >> cd test >> tar xaf ../test.tar >> ll > total 0 > drwxrwxr-x+ 1 0 Aug 22 15:26 test/ >> lsacl test > [u::rwx,g::rwx,g:Bliss\lawgroup:rwx,g:Bliss\Domain > Admins:rwx,m:rwx,o:r-x/ > u::rwx,g::rwx,g:Bliss\lawgroup:rwx,g:Bliss\Domain > Admins:rwx,m:rwx,o:r-x] test > > With the above and only standard separator chars, no problem > > I'm guessing, but '+' is a reserved char that's not permitted in > acl_to_text... You're misinterpreting the '+'. It was used in place of ' ' (a space) in "Unknown User" and "Unknown Group". Now why isn't "Domain Admins" also "Domain+Admins" is a question of pondering. -- cyg Simple 0x7183A42BE56022D5.asc Description: application/pgp-keys -- 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: gettext - acl tests - cygwin specific code path
On 8/22/2018 4:13 AM, Corinna Vinschen wrote: > On Aug 21 11:52, cyg Simple wrote: >> I've been reviewing the testing of gettext and I have a failure for all >> of the acl tests. I've found that a file without acl will obtain acl if >> the mode is changed to 605. STC below. >> >> >> $ touch /tmp/tmpfile0 >> $ ls -l /tmp/tmpfile0 >> -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 >> $ getfacl /tmp/tmpfile0 >> # file: /tmp/tmpfile0 >> # owner: myUser >> # group: myGroup >> user::rw- >> group::r-- >> other:r-- >> $ chmod 600 >> $ ls -l /tmp/tmpfile0 >> -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 >> $ getfacl /tmp/tmpfile0 >> # file: /tmp/tmpfile0 >> # owner: myUser >> # group: myGroup >> user::rw- >> group::--- >> other:--- >> $ chmod 605 >> $ ls -l /tmp/tmpfile0 >> -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 >> $ getfacl /tmp/tmpfile0 >> # file: /tmp/tmpfile0 >> # owner: myUser >> # group: myGroup >> user::rw- >> group::--- >> other:r-x >> user:myUser:--- >> > > I just tried this and I can not reproduce the result. I used your above > testcase with fixed chmod invocations. Eventually: > > [...] > $ chmod 605 /tmp/tmpfile0 > $ ls -l /tmp/tmpfile0 > -rwr-x 1 corinna vinschen 0 Aug 22 09:44 /tmp/tmpfile0 > $ getfacl /tmp/tmpfile0 > # file: /tmp/tmpfile0 > # owner: corinna > # group: vinschen > user::rw- > group::--- > other::r-x > > Please retry all steps and add the cacls output after each getfacl > output. Additionally it might be important to see the permissions > of your /tmp dir (ls, getfacl and cacls). Mine has the typical > 01777 perms. For testing I also created tmpfile0 in a directory > with perms 0755, but the outcome was the same, as above. > > Here are my tmpfile0 perms in cacls output, btw., for comparison: > > $ cacls C:/cygwin64/tmp/tmpfile0 > C:\cygwin64\tmp\tmpfile0 NULL SID:(DENY)(special access:) > READ_CONTROL > > MYDOMAIN\corinna:(DENY)(special access:) > FILE_EXECUTE > > MYDOMAIN\corinna:(special access:) > STANDARD_RIGHTS_ALL > DELETE > READ_CONTROL > WRITE_DAC > WRITE_OWNER > SYNCHRONIZE > STANDARD_RIGHTS_REQUIRED > FILE_GENERIC_READ > FILE_GENERIC_WRITE > FILE_READ_DATA > FILE_WRITE_DATA > FILE_APPEND_DATA > FILE_READ_EA > FILE_WRITE_EA > FILE_READ_ATTRIBUTES > FILE_WRITE_ATTRIBUTES > > MYDOMAIN\vinschen:(special access:) >READ_CONTROL >SYNCHRONIZE >FILE_READ_ATTRIBUTES > > MYDOMAIN\vinschen:(DENY)(special access:) >FILE_READ_DATA >FILE_READ_EA >FILE_EXECUTE > > Everyone:R C:\opt\cygwin64\tmp\tmpfile0 CYGHOST\cygSimple:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA
Re: gettext - acl tests - cygwin specific code path
On 8/22/2018 4:15 AM, Corinna Vinschen wrote: > On Aug 21 19:57, cyg Simple wrote: >> On 8/21/2018 4:13 PM, Andrey Repin wrote: >>> Greetings, cyg Simple! >>> >>>> During the testing at least one of the tests does `setfacl -m group:0:1 >>>> tmpfile0`. Obviously this gets a 'permission denied' error as group 0 >>>> doesn't exist. What do you suggest for reasonable replacement for 0? >>> >>> Nothing. Not all systems have a concept of "group 0". Just skip this test. >> >> I'm not interested in skipping the test; after all the path for the test >> is Cygwin specific. It's just not the correct thing to do for the >> Cygwin specific path. I believe 11 to be the correct test and will >> pursue that upstream. Marco suggested maybe 544(Administrator) but that >> doesn't work with a typical user build while doing the same in Linux for >> root group 0 as a typical user I would need to have elevated privilege >> in Windows to use 544. > > Exactly as on another system when using group 0. If these tests are > really only performed on Cygwin, I don't know what the creator intended. Cygwin is treated specifically to do this instead of that. As I review more cases of the specifically treated Cygwin I think the tests are old as setfacl options being used don't exist today. > Otherwise, if you want to reproduce what the testcase did, you should in > fact use an admin group. That depends on the purpose of the test and based on the comments the testing could use any group. It should also check that the /tmp filesystem can support ACL as it assumes /tmp to be locally mounted and skip the testing if not. -- cyg Simple -- 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: gettext - acl tests - cygwin specific code path
On 8/21/2018 4:13 PM, Andrey Repin wrote: > Greetings, cyg Simple! > >> During the testing at least one of the tests does `setfacl -m group:0:1 >> tmpfile0`. Obviously this gets a 'permission denied' error as group 0 >> doesn't exist. What do you suggest for reasonable replacement for 0? > > Nothing. Not all systems have a concept of "group 0". Just skip this test. I'm not interested in skipping the test; after all the path for the test is Cygwin specific. It's just not the correct thing to do for the Cygwin specific path. I believe 11 to be the correct test and will pursue that upstream. Marco suggested maybe 544(Administrator) but that doesn't work with a typical user build while doing the same in Linux for root group 0 as a typical user I would need to have elevated privilege in Windows to use 544. -- cyg Simple -- 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: gettext - acl tests - cygwin specific code path
On 8/21/2018 11:52 AM, cyg Simple wrote: > I've been reviewing the testing of gettext and I have a failure for all > of the acl tests. I've found that a file without acl will obtain acl if > the mode is changed to 605. STC below. > > > $ touch /tmp/tmpfile0 > $ ls -l /tmp/tmpfile0 > -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 > $ getfacl /tmp/tmpfile0 > # file: /tmp/tmpfile0 > # owner: myUser > # group: myGroup > user::rw- > group::r-- > other:r-- > $ chmod 600 > $ ls -l /tmp/tmpfile0 > -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 > $ getfacl /tmp/tmpfile0 > # file: /tmp/tmpfile0 > # owner: myUser > # group: myGroup > user::rw- > group::--- > other:--- > $ chmod 605 > $ ls -l /tmp/tmpfile0 > -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 > $ getfacl /tmp/tmpfile0 > # file: /tmp/tmpfile0 > # owner: myUser > # group: myGroup > user::rw- > group::--- > other:r-x > user:myUser:--- > > > gettext loops through a number of modes and fortunately one of those had > an owner and other without the group. Anytime the other is set without > the owner or group having permission we get an ACL for the user which is > wrong. A `setfacl -b /tmp/tmpfile0` doesn't correct the information > from getfacl. > During the testing at least one of the tests does `setfacl -m group:0:1 tmpfile0`. Obviously this gets a 'permission denied' error as group 0 doesn't exist. What do you suggest for reasonable replacement for 0? I'm thinking 11(Authenticated Users) as the purpose of the test is to determine if the use of `set_acl (file, -1, mode);` will reset to a file without acl. -- cyg Simple -- 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
gettext - acl tests - cygwin specific code path
I've been reviewing the testing of gettext and I have a failure for all of the acl tests. I've found that a file without acl will obtain acl if the mode is changed to 605. STC below. $ touch /tmp/tmpfile0 $ ls -l /tmp/tmpfile0 -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 $ getfacl /tmp/tmpfile0 # file: /tmp/tmpfile0 # owner: myUser # group: myGroup user::rw- group::r-- other:r-- $ chmod 600 $ ls -l /tmp/tmpfile0 -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 $ getfacl /tmp/tmpfile0 # file: /tmp/tmpfile0 # owner: myUser # group: myGroup user::rw- group::--- other:--- $ chmod 605 $ ls -l /tmp/tmpfile0 -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0 $ getfacl /tmp/tmpfile0 # file: /tmp/tmpfile0 # owner: myUser # group: myGroup user::rw- group::--- other:r-x user:myUser:--- gettext loops through a number of modes and fortunately one of those had an owner and other without the group. Anytime the other is set without the owner or group having permission we get an ACL for the user which is wrong. A `setfacl -b /tmp/tmpfile0` doesn't correct the information from getfacl. -- cyg Simple -- 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: scrolling through history in cygwin terminal window line gets garbled
On 8/18/2018 9:27 PM, Steven Penny wrote: > On Sat, 18 Aug 2018 20:47:31, cyg Simple wrote: >> You should give that a try. You can start with conhost and get a cmd >> session. > > it appears we have reached the bounds of your knowledge. trying to launch > conhost.exe on its own is a noop. Maybe for you but not for me. > if you double click the EXE, or you > call it > from the run box, it will not show up in the task manager. if you ARE > seeing it, > its because you have launched one of these: > > - cmd.exe > - powershell.exe > - sh.exe > > and *it* has called conhost.exe. perhaps you should actually try this > before > commenting further. > No for me, again Win10, executing or clicking from File Explorer the conhost.exe program will open a cmd.exe window. -- cyg Simple -- 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: scrolling through history in cygwin terminal window line gets garbled
On 8/18/2018 6:20 PM, Steven Penny wrote: > On Sat, 18 Aug 2018 16:17:49, cyg Simple wrote: >> I'm using Win10 and typically the icon created by setup which starts >> mintty directly as: >> >> C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - >> >> I started conhost from that session and then executed `bash -il' within >> conhost. > > i said from the beginning that i wasnt using mintty - so im not sure why > you > are testing with mintty > > also you dont start conhost - its started automatically when you launch any > shell. > You should give that a try. You can start with conhost and get a cmd session. >> So just for grins I went to the Windows Explorer and started with the >> cygwin.bat file and performed your test again using the .bash_history >> with no issues. This time the TERM=cygwin which comes from >> /usr/share/terminfo/63/cygwin. > > all i can say to this is that you arent using windows 7, so perhaps the > newer > version of conhost has fixed the issue - at this point we would need > another > windows 7 user to confirm the issue - further tests with win 10 wont be > helpful. I agree if there are any. -- cyg Simple -- 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: scrolling through history in cygwin terminal window line gets garbled
On 8/18/2018 11:23 AM, Steven Penny wrote: > On Fri, 17 Aug 2018 23:47:33, cyg Simple wrote: >> Sorry, I can't duplicate this. I even tried with conhost and bash -il >> in the window and just don't see an issue. My TERM value is xterm and >> the data comes from the file /usr/share/terminfo/78/xterm. > > You comment concerned me - so i just tested this again > > this time on a pristine virtual machine - windows 7 > > same issue - note i am launching via "Cygwin.bat" > > I'm using Win10 and typically the icon created by setup which starts mintty directly as: C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - I started conhost from that session and then executed `bash -il' within conhost. So just for grins I went to the Windows Explorer and started with the cygwin.bat file and performed your test again using the .bash_history with no issues. This time the TERM=cygwin which comes from /usr/share/terminfo/63/cygwin. -- cyg Simple -- 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: equivalent to su or sudo?
On 8/17/2018 4:33 PM, David Rothenberger wrote: > Ulli Horlacher wrote: >> I need to run some scripts with full administrator rights (for chown, >> chmod, setfacl). >> Is there a cygwin equivalent to su or sudo? >> > > I use the following shell script to start a command as Administrator. I > mainly just use it to start mintty. > > #!/bin/bash > cmd="$(cygpath -da "$1")"; shift > if [ $# -gt 0 ]; then > powershell Start-Process "$cmd" -ArgumentList \""$@"\" -Verb RunAs > -WindowStyle Hidden > else > powershell Start-Process "$cmd" -Verb RunAs -WindowStyle Hidden > fi > You don't need powershell for that. #!/bin/sh export PS1="% " cygstart --action=runas mintty --title=Admin -e /bin/bash -il The export of PS1 is to mark that the terminal window is in administrative rights. You can modify the shell program to dash, ash zsh or whatever you favorite shell is. Make sure to issue the interactive and login support for the shell. -- cyg Simple -- 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: scrolling through history in cygwin terminal window line gets garbled
On 8/17/2018 9:18 PM, Steven Penny wrote: > On Fri, 17 Aug 2018 16:36:57, Thomas Wolff wrote: >> Please test the following: >> * Set you prompt to some basic string, e.g. PS1=%. Does that change >> anything? >> * Mintty 2.7.5 changed the default wraparound behaviour to become >> compatible with the xterm default. With setting -o OldWrapModes=true, >> does that change anything? >> * Can you cross-test this in xterm? >> * Does it happen in a freshly-started mintty? If it only happens >> later, which programs did you run in the meantime? >> * Make a screen log demonstrating a minimal test case, please. > > This bug has bothered me for years, I would love to see it fixed. Here is a > simple test case: > > $ cat ~/.bash_history > echo ABCDEF ABCDEF ABCDEF ABCDEF > echo 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 > > Result: > > $ echo ABCDEF ABCDEF ABCDEF ABCDEF 234 > > What I tried: > > 1. PS1=% > 2. "TERM" with no "am" or "bw" > 3. "TERM" with both "am" and "bw" > 4. "TERM" with "am" only (couldnt find one with "bw" only) > > If you have a custom terminal that this works with - provide the "infocmp" > output and I will try it. Note that I am not using Mintty, I am just using > sh.exe and conhost.exe, so it seems that mintty is not the culprit but > perhaps > Cygwin DLL or Readline. > Sorry, I can't duplicate this. I even tried with conhost and bash -il in the window and just don't see an issue. My TERM value is xterm and the data comes from the file /usr/share/terminfo/78/xterm. -- cyg Simple -- 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: cygserver - /usr/sbin vs /usr/bin
On 8/14/2018 4:12 PM, Vince Rice wrote: >> On Aug 14, 2018, at 3:05 PM, cyg Simple wrote: >> >> On 8/13/2018 10:41 AM, Corinna Vinschen wrote: >>> … >>> >>> cyglsa.dll requires an install script that would have to be change as >>> well. In contrast, you'd have to make sure your new solution still >>> works for existing installations. What's the gain? Does it *hurt* to >>> have the stuff in /usr/bin like everything else? >>> >> >> No but then why have cygserver.exe in /usr/sbin? Either there should be >> a separation because of required administrative rights or there >> shouldn't be at all. Having it both ways is just confusing even if the >> confusion isn't apparent to you. > > And just because it's confusing to you doesn't mean it's confusing to everyone > else. I for one have never been confused. But you are confused, you are saying that a system binary should be in /usr/bin instead of /usr/sbin and that everyone knows that /usr/bin contains both so be careful not to stumble upon them. You are confused because you must not know the importance of the need for /usr/sbin. But if Cygwin doesn't care to mix and match that then put everything in /usr/bin and get rid of /usr/sbin. That is why I said "Having it both ways is just confusing even if the confusion isn't apparent to you." You've just proven the point. -- cyg Simple -- 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: Documentation for cygwin-console-helper.exe
On 8/13/2018 10:45 AM, Corinna Vinschen wrote: > On Aug 13 08:57, cyg Simple wrote: >> On 8/13/2018 3:53 AM, Corinna Vinschen wrote: >>> On Aug 12 19:53, cyg Simple wrote: >>>> The documentation for cygwin-console-helper.exe is missing, not even a >>>> --help function. >>> >>> cygwin-console-helper.exe is not for the user to use, so why add >>> user docs? The documentation is in the source for the interested >>> dev: >>> >>> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_console.cc;hb=HEAD#l2521 >>> >> >> How the hell am I supposed to find that by looking at >> cygwin-console-helper.cc? > > You aren't. But telling me something in the source code would have probably prevented me from asking. I don't think --help is helpful in this case but words in comments about the reasoning for the executable is and should always be a requirement. What happens when those who know move on to something better; then those that are left behind have to struggle to find the reasons. > The cygwin-console-helper solution is under-the-hood stuff, > a solution for a problem which was supposed to be not user visible. So perhaps the fact that it is user visible is the problem. Perhaps it should move to somewhere like /usr/libexec. > Because, in this case user visible means it doesn't work as desired. Well it works, it is a library helper app that hides the console of a windowed app. It shouldn't be in the user application space. As it is, it is in the open for the user to dwell on what is this app, it does nothing useful when I run it from the console; I might as well delete it. Oh no, now my mintty has a console attached to every window. -- cyg Simple -- 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: cygserver - /usr/sbin vs /usr/bin
On 8/13/2018 10:41 AM, Corinna Vinschen wrote:
> On Aug 13 08:50, cyg Simple wrote:
>> On 8/13/2018 3:49 AM, Corinna Vinschen wrote:
>>> On Aug 10 11:28, cyg Simple wrote:
>>>> Looking at the files delivered by the cygwin upgrade I see
>>>> /usr/sbin/cygserver.exe and /usr/bin/cygserver-config. Shouldn't
>>>> cygserver-config reside in /usr/sbin with cygserver.exe?
>>>>
>>
>> You didn't answer this with your below answer. The cygserver-config
>> requires administrator privilege so it would be better placed with
>> cygserver.exe in sbin, IMO.
>>
>>>> Also in that vain shouldn't cyglsa belong in /usr/sbin?
>>>
>>> Nope. /usr/bin is where the DLLs are, so they can be found
>>> even if PATH isn't set up.
>>>
>>
>> But cyglsa{,64}.dll is a standalone without any other binary. It is
>> only accessed by the OS for the LSA support if the registry key exists.
>> This means the cyglsa-config can be modified to point to the sbin
>> directory instead of the bin directory. Again administrator privilege
>> is required so better placed in sbin, IMO.
>
> cyglsa.dll requires an install script that would have to be change as
> well. In contrast, you'd have to make sure your new solution still
> works for existing installations. What's the gain? Does it *hurt* to
> have the stuff in /usr/bin like everything else?
>
No but then why have cygserver.exe in /usr/sbin? Either there should be
a separation because of required administrative rights or there
shouldn't be at all. Having it both ways is just confusing even if the
confusion isn't apparent to you.
> If you want trhis questionable changes desperately, feel free to provide
> patches on the cygwin-patches ML.
>
When I feel that the answers to my question have been thought out I
would entertain a patch to cygwin-patches. I realize the cyglsa-config
script requires a change should cyglsa*.dll moves and an update option
would need to be provided for those who have configured it already.
--
cyg Simple
--
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: Documentation for cygwin-console-helper.exe
On 8/13/2018 3:53 AM, Corinna Vinschen wrote: > On Aug 12 19:53, cyg Simple wrote: >> The documentation for cygwin-console-helper.exe is missing, not even a >> --help function. > > cygwin-console-helper.exe is not for the user to use, so why add > user docs? The documentation is in the source for the interested > dev: > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_console.cc;hb=HEAD#l2521 > How the hell am I supposed to find that by looking at cygwin-console-helper.cc? https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/cygwin-console-helper.cc;hb=cea37699d1d7f46396323a1997ccd54148517a62 -- cyg Simple -- 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: cygserver - /usr/sbin vs /usr/bin
On 8/13/2018 3:49 AM, Corinna Vinschen wrote:
> On Aug 10 11:28, cyg Simple wrote:
>> Looking at the files delivered by the cygwin upgrade I see
>> /usr/sbin/cygserver.exe and /usr/bin/cygserver-config. Shouldn't
>> cygserver-config reside in /usr/sbin with cygserver.exe?
>>
You didn't answer this with your below answer. The cygserver-config
requires administrator privilege so it would be better placed with
cygserver.exe in sbin, IMO.
>> Also in that vain shouldn't cyglsa belong in /usr/sbin?
>
> Nope. /usr/bin is where the DLLs are, so they can be found
> even if PATH isn't set up.
>
But cyglsa{,64}.dll is a standalone without any other binary. It is
only accessed by the OS for the LSA support if the registry key exists.
This means the cyglsa-config can be modified to point to the sbin
directory instead of the bin directory. Again administrator privilege
is required so better placed in sbin, IMO.
--
cyg Simple
--
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
Documentation for cygwin-console-helper.exe
The documentation for cygwin-console-helper.exe is missing, not even a --help function. No comments in the source code. Only a code.google page for mintty[1] was beneficial to allow me to understand it and then it was a late entry comment that sort of explained the purpose. I will revisit this issue with a source code patch to add comments. [1]https://code.google.com/archive/p/mintty/issues/39 -- cyg Simple -- 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: cygserver - /usr/sbin vs /usr/bin
Ping. On 8/10/2018 11:28 AM, cyg Simple wrote: > Looking at the files delivered by the cygwin upgrade I see > /usr/sbin/cygserver.exe and /usr/bin/cygserver-config. Shouldn't > cygserver-config reside in /usr/sbin with cygserver.exe? > > Also in that vain shouldn't cyglsa belong in /usr/sbin? > -- cyg Simple -- 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
cygserver - /usr/sbin vs /usr/bin
Looking at the files delivered by the cygwin upgrade I see /usr/sbin/cygserver.exe and /usr/bin/cygserver-config. Shouldn't cygserver-config reside in /usr/sbin with cygserver.exe? Also in that vain shouldn't cyglsa belong in /usr/sbin? -- cyg Simple -- 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: solution of this problem
On 8/9/2018 12:58 PM, Jokermed gamar wrote: > 1 [main] john 3876 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.com > stat: hash.txt: No such file or directory > https://www.google.com/search?q=find_fast_cwd%3A+WARNING+site%3Acygwin.com -- cyg Simple -- 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: Problem referencing libraries in tcl 8.6, e.g. fileutil
On 8/7/2018 11:56 AM, SImon Conway-Smith wrote: > I have added the tcl intepreter into my Cygwin (64-bit) installation, but > when trying to run some code samples using the fileutil library, e.g. the > foreachLine command, I'm getting 'invalid command name > "fileutil::foreachLine"'. I've even tried prefixing the command with "tcl::" > as I had to do for the mathfunc:: library functions, but still get the error > message. Is there an additional tcl package I need to install, or what? > It seems that tcllib isn't installed with Cygwin's tcl. $ tclsh % package require fileutil can't find package fileutil % Since tcllib is pure tcl with no compilation required you can download it directly from https://www.tcl.tk/software/tcllib/ and install it into the /usr/lib/tcl8.6/ directory. -- cyg Simple -- 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: segfault with iconv
On 8/5/2018 11:55 PM, Steven Penny wrote: > On Sun, 5 Aug 2018 23:04:54, cyg Simple wrote: >> I'm getting a segfault with iconv with the attached script. Do others >> have this problem? TIA for the information. > > Not sure what is breaking for you - but works fine here: > > $ echo böse bübchen > infile.txt > > $ LC_ALL=C iconv --byte-subst '<%X>' -f ASCII -t ASCII infile.txt > bse bbchen > > $ LC_ALL=en_US.UTF-8 iconv --byte-subst '<%X>' -f ASCII -t ASCII > infile.txt > bse bbchen > Thanks for checking. My problem has been resolved with a reinstall. -- cyg Simple -- 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
segfault with iconv
I'm getting a segfault with iconv with the attached script. Do others have this problem? TIA for the information. -- cyg Simple #!/bin/sh options_ascii='--unicode-subst= --byte-subst=<0x%02x> --widechar-subst=<%08x>' # Test of --byte-subst with an ASCII substitution. cat > tmp-in <<\EOF Böse Bübchen EOF /usr/bin/iconv $options_ascii -f ASCII -t ASCII < tmp-in > tmp-out cat > tmp-ok <<\EOF B<0xc3><0xb6>se B<0xc3><0xbc>bchen EOF cmp tmp-out tmp-ok -- 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: ssh cause mintty terminal not to close (tested on 4 cygwin installations)
On 8/3/2018 6:01 AM, n...@internetgruppen.dk wrote: > For cyg Simple: > I am stuck with Cygwin 32 bit because of some tools, we use. A team is > trying to get it to work with 64 bits, but that is not there yet. > Are the tools dependent on the cygwin1.dll? What problems, bring them here and maybe we can help. -- cyg Simple -- 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: ssh cause mintty terminal not to close (tested on 4 cygwin installations)
On 8/2/2018 9:44 AM, Niels Kristian Jensen wrote: > I've noticed a strange behavior of the standard Cygwin Terminal (mintty): > > If I open a Cygwin Terminal (using the shortcut on the desktop installed by > Cygwin setup) and just press Ctrl-D, it writes "logout" and closes the > window as expected. > > If I do the same, but give one command "ssh" first, the word > "logout" appear, the window goes black, but the window does not close (!) The > window can still be closed using the "X" in upper right corner. > I see no such problem with Windows 10 Home Edition. > If I replace the command with "ssh -V", the window closes as > expected when I press Ctrl-D. > > This may seem like a minor thing, but we have much trouble with Jenkins > builds (started via Cygwin OpenSSH) which randomly hang forever - I wonder > if this could be a clue in this investigation. > I doubt it ... see below. > Tested versions: > > Windows Server 2008 R2 > OpenSSH_7.3p1, OpenSSL 1.0.2j 26 Sep 2016 > mintty 2.7.0 (i686-pc-cygwin) > What arch is this server? x86_64 or i686? > and > > Windows 10 > OpenSSH_7.6p1, OpenSSL 1.0.2m 2 Nov 2017 > mintty 2.8.1 (i686-pc-cygwin) > Same questions! > Only commented lines appear in /etc/ssh_config , ~/.bashrc and > ~/.bash_profile on both systems. > > I would be glad if (some of) you could repeat this test on your system - > perhaps this behavior is due to some local problem on my systems. > If you have x86_64 (i.e. 64bit) servers then install 64bit Cygwin to see it this continues. Otherwise follow the instructions at ... > Problem reports: http://cygwin.com/problems.html -- cyg Simple -- 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: Updated: setup (2.893)
Attn Jon Turney, The update announcement for setup[1] did not make it to the cygwin@cygwin.com list. [1] https://cygwin.com/ml/cygwin-announce/2018-07/msg00021.html -- cyg Simple -- 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: Cntlm does not run in windows 10
On 7/27/2018 5:28 AM, AKARKAR Nitesh (ITS/EBS) wrote: > Hi, > Can you please check below error I get when I try to run cntlm.bat on windows > 10: > ** > 0 [main] cntlm 190504 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.com > Exitting with error. Check daemon logs or run with -v. > ** > Can anybody help in this issue. > Update your Cygwin and tell your CNTLM vendor. See: https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings -- cyg Simple -- 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: [ITA] cmake 3.12.0
On 7/24/2018 3:01 PM, Achim Gratz wrote: > Ivan Shynkarenka writes: >> Otherwise I'd like to contact with current cmake maintainers, but I >> cannot find their email anywhere. > > That communication should happen right here. > Egads, Ivan wants to help and you give him a run around without doing a little research. Okay, yes there are maintainers listed. William Hoffman's last post on cmake was in 2005, probably the first release. Tony Kelman's last post was in March of this year but for the cmake release it was in 2015. Looking at kelman dot net, I don't know if Tony receives messages or not but I've added him in Cc to this thread to determine if it is still viable. I'll let you know, otherwise Tony, please respond. Note to find Tony's email address I search the mail archive[1] for `kelman "cmake"' to determine the last response. The archive has the email address in munged format. [1] https://cygwin.com/ml/cygwin/ -- cyg Simple
