Running non-cygwin executables in cygwin bash terminal or script
Hello, In general, is there anything that can go wrong or not work if I invoke regular Windows/.NET executables (not compiled with any cygwin header or linked with any cygwin dll) from a cygwin bash terminal or script? I am planning to write a bash script to call rsync and then a command line program written in C# (.NET framework 4.5 in Visual Studio 2013). I'm not a huge cygwin/posix/unix hacker, so there are a few things that seem murky. I suppose that are other people in similar situations. I can think of a few things that don't seem entirely clear in the documentation and FAQ. I'm guessing that invoking regular Windows/.NET executables would mostly just work, with the following caveat: - stdin/stdout/stderr redirection and piping would still work, even when piping with cygwin-linked programs (care with charset and end-of-line conventions needs to be taken, however); - UNIX-style sockets are out of the question; - the usual Window permission model would still be used; - if the regular Windows/.NET executable accepts a file or directory path as argument, it still needs to be written in the Windows style (i.e. "C:\\foobar\\" instead of "/cygdrive/c/foobar"); - the locale of the cygwin bash process may cause problems when passing arguments to the regular Windows program. Am I mostly correct? So far it seems to work. Am I missing other caveat? Would it make sense to have all this summarized in the FAQ? Best Regards, Kal -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.5
Hi Cygwin friends and users,
I just released a 5th TEST version of the next upcoming Cygwin release,
1.7.33-0.5.
Changes compared to the former test version 1.7.33-0.4:
- atexit is now exported as statically linked function from libcygwin.a.
This allows reliable access to the DSO handle of the caller for newly
built executables. The former atexit entry point into the DLL remains
for backward compatibility only.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
"test" release.
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.32, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- Add -b/--remove-all option to setfacl to reduce the ACL to only the
entries representing POSIX permission bits.
- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
This can be utilized in scripts to access paths via cygdrive prefix, even
if the cygdrive prefix has been changed by the user.
- /proc/partitions now prints the windows mount points the device is mounted
on. This allows to recognize the underlying Windows devices of the Cygwin
raw device names.
- New API: quotactl, designed after the Linux/BSD function, but severely
restricted: Windows only supports user block quotas on NTFS, no group
quotas, no inode quotas, no time constraints.
- New APIs: ffsl, ffsll (glibc extensions).
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- New internal exception handling based on SEH on 64 bit Cygwin.
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- When exec'ing applications, check if $PATH exists and is non-empty. If not,
add PATH variable with Cygwin installation directory as content to Windows
environment to allow loading of Cygwin system DLLs.
- Disable CYGWIN "dosfilewarning" option by default.
- Improve various header files for C++- and standards-compliance.
- Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
- atexit is now exported as statically linked function from libcygwin.a.
This allows reliable access to the DSO handle of the caller for newly
built executables. The former atexit entry point into the DLL remains
for backward compatibility only.
Bug Fixes
-
- Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
directory stream.
- Fix a resource leak in rmdir(2).
- Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
open and before calling one of the affected functions.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html
- Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html
- Fix chown(2) on ptys in a corner case.
- Generate correct error when a path is inaccessible due to missing permissions.
Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html
- Don't hang in accept calls if socket is no listener. Set errno to EINVAL
instead.
- Don't allow seeking on serial lines and sockets. Set errno to ESPIPE
instead.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html
- Fix output of /proc//statm.
- Fix a SEGV in cygcheck if the envi
BLODA Addition
I recently discovered that the Liquidware Labs Stratusphere Agent causes random issues when launching executables through a Cygwin bash shell. Any chance someone can add this to the BLODA list to help others that might run into similar issues? -- 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: BLODA Addition
Hi Bryan, On Nov 5 11:12, Bryan Berns wrote: > I recently discovered that the Liquidware Labs Stratusphere Agent > causes random issues when launching executables through a Cygwin bash What means "random issues" here? > shell. Any chance someone can add this to the BLODA list to help > others that might run into similar issues? If you can describe a simple way how to discover the software by the existence of some file or registry key, or maybe by the name of a running process (not as reliable), we could add this even to the BLODA test in cygcheck. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcpmIfv4LY3.pgp Description: PGP signature
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
Hi Cygwin friends and users,
I just released a 6th TEST version of the next upcoming Cygwin release,
1.7.33-0.6.
Changes compared to the former test version 1.7.33-0.5:
- The 1.7.33-0.5 version introduced a dependency to a symbol (__dso_handle)
provided only by GCC versions starting with GCC 4.8.3-3. This results
in being unable to link executables with GCC 4.8.3-2 and earlier.
Cygwin 1.7.33-0.6 introduces a fix for this situation by providing its
own default symbol __dso_handle.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
"test" release.
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.32, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- Add -b/--remove-all option to setfacl to reduce the ACL to only the
entries representing POSIX permission bits.
- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
This can be utilized in scripts to access paths via cygdrive prefix, even
if the cygdrive prefix has been changed by the user.
- /proc/partitions now prints the windows mount points the device is mounted
on. This allows to recognize the underlying Windows devices of the Cygwin
raw device names.
- New API: quotactl, designed after the Linux/BSD function, but severely
restricted: Windows only supports user block quotas on NTFS, no group
quotas, no inode quotas, no time constraints.
- New APIs: ffsl, ffsll (glibc extensions).
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- New internal exception handling based on SEH on 64 bit Cygwin.
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- When exec'ing applications, check if $PATH exists and is non-empty. If not,
add PATH variable with Cygwin installation directory as content to Windows
environment to allow loading of Cygwin system DLLs.
- Disable CYGWIN "dosfilewarning" option by default.
- Improve various header files for C++- and standards-compliance.
- Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
- atexit is now exported as statically linked function from libcygwin.a.
This allows reliable access to the DSO handle of the caller for newly
built executables. The former atexit entry point into the DLL remains
for backward compatibility only.
Bug Fixes
-
- Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
directory stream.
- Fix a resource leak in rmdir(2).
- Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
open and before calling one of the affected functions.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html
- Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html
- Fix chown(2) on ptys in a corner case.
- Generate correct error when a path is inaccessible due to missing permissions.
Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html
- Don't hang in accept calls if socket is no listener. Set errno to EINVAL
instead.
- Don't allow seeking on serial lines and sockets. Set errno to ESPIPE
instead.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html
- Fix output of /proc//statm.
- Fix a SEGV in cygcheck if the environment variable COMSPEC is not
Re: [ANNOUNCEMENT] Updated: wget-1.16-1
On Wed, Nov 5, 2014 at 1:27 AM, Eric Blake wrote: > That thread also suggested that you could work around some of the > regression by setting up your config file to automatically add > --no-scroll if that is the new behavior you don't like. I should have mentioned, that does not fix it. $ wget --limit-rate=1 --progress=bar:noscroll \ cygwin.com/snapshots/x86/cygwin1-20141027.dbg.xz --2014-11-05 12:08:45-- http://cygwin.com/snapshots/x86/cygwin1-20141027.dbg.xz Resolving cygwin.com (cygwin.com)... 209.132.180.131 Connecting to cygwin.com (cygwin.com)|209.132.180.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3164408 (3.0M) [application/x-xz] Saving to: ‘cygwin1-20141027.dbg.xz.1’ cygwin1-20141027.db 0%[ ] 4 1.00 B/s eta 36d 14h cygwin1-20141027.db 0%[ ] 5 1.00 B/s eta 36d 14h cygwin1-20141027.db 0%[ ] 6 1.00 B/s eta 36d 14h cygwin1-20141027.db 0%[ ] 7 1.00 B/s eta 36d 15h -- 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] TEST RELEASE: Cygwin 1.7.33-0.5
> I just released a 5th TEST version of the next upcoming Cygwin release,
> 1.7.33-0.5.
Ever since using this 1.7.33-0.x series (currently running 1.7.33-0.5) I've
been having intermittent trouble with one of my scripts, and just finally got
around to digging further today. This is an expect script (subroutine of a
larger system) designed to auto-login to an ssh session and then set the passwd
-R to allow further ssh sessions to have "full network powers". (I then run a
cron script which drops these rights off again every half-hour, so the "full
network powers" logins are time limited.)
The symptoms of the failure are that it sometimes fails to send the ssh
password (and thus doesn't proceed to the passwd -R command at all). If I run
the script a second time, it almost always works on the second try. After some
time has passed I run it again and get a failure, then immediately run again
and succeed. I would appreciate any thoughts as to why such a script would
fail, and then succeed on successive runs. This routine basically never failed
on the previous recent versions of cygwin (in active daily use since
approximately July 1st).
Dave
The script is called like this:
$ super.exp localhost mypasswd
and the file super.exp looks like this:
#!/usr/bin/expect
set mach [lindex $argv 0]
set pass [lindex $argv 1]
spawn ssh -o PubkeyAuthentication=no $mach
expect -exact "password: "
send $pass\n
expect {
"$ " {
send "passwd -R\n"
expect -exact "password: "
send $pass\n
expect -exact "password: "
send $pass\n
expect -exact "$ "
send "exit\n"
interact
}
"Permission denied, please try again." {
send_error "The password you provided was invalid.\n"
exit 1
}
}
Re: BLODA Addition
Random is this case is receiving a "permission denied" message from the shell when launching an executable. When repeatably running a test case, we see an error one every 15 minutes on average. Without it installed, no error occurs. I'll see what might be good registry key to query -- not sitting at a computer with it installed right now. I was thinking about debugging the underlying issue that's causing this from a cygwin perspective. Would this be advisable or is this behavior just a fundamental consequence of how cygwin interacts with Windows? On Nov 5, 2014 11:43 AM, "Corinna Vinschen" wrote: > > Hi Bryan, > > On Nov 5 11:12, Bryan Berns wrote: > > I recently discovered that the Liquidware Labs Stratusphere Agent > > causes random issues when launching executables through a Cygwin bash > > What means "random issues" here? > > > shell. Any chance someone can add this to the BLODA list to help > > others that might run into similar issues? > > If you can describe a simple way how to discover the software by > the existence of some file or registry key, or maybe by the name > of a running process (not as reliable), we could add this even to > the BLODA test in cygcheck. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- 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: Running non-cygwin executables in cygwin bash terminal or script
Greetings, Kal Sze! > In general, is there anything that can go wrong or not work if I > invoke regular Windows/.NET executables (not compiled with any cygwin > header or linked with any cygwin dll) from a cygwin bash terminal or > script? Speaking veeery-veeery generally, no. A program is a program. If it can be run, it'll run. (I.e., I'm starting WoW client from shell script.) However, there's a number of things you should be aware of. > I am planning to write a bash script to call rsync and then a command > line program written in C# (.NET framework 4.5 in Visual Studio 2013). > I'm not a huge cygwin/posix/unix hacker, so there are a few things > that seem murky. I suppose that are other people in similar > situations. > I can think of a few things that don't seem entirely clear in the > documentation and FAQ. > I'm guessing that invoking regular Windows/.NET executables would > mostly just work, with the following caveat: > - stdin/stdout/stderr redirection and piping would still work, even > when piping with cygwin-linked programs (care with charset and > end-of-line conventions needs to be taken, however); Right. > - UNIX-style sockets are out of the question; If you want your non-cygwin program communicate through Cygwin sockets, you are in for a lot of trouble. Not strictly "out of question", but "largely not worth the time spent". > - the usual Window permission model would still be used; More or less. There's caveats imposed by POSIX approximation of Windows ACLs. > - if the regular Windows/.NET executable accepts a file or directory > path as argument, it still needs to be written in the Windows style > (i.e. "C:\\foobar\\" instead of "/cygdrive/c/foobar"); "C:/foobar" would work in most cases, so do "/foobar", assuming you know what you are doing. > - the locale of the cygwin bash process may cause problems when > passing arguments to the regular Windows program. If it's usual LANG=whatever.UTF-8, yes. If it's more friendly single-byte encoding, should not be a problem. > Am I mostly correct? So far it seems to work. Am I missing other caveat? > Would it make sense to have all this summarized in the FAQ? You forgot another important moment. Since non-cygwin applications have no conception of pty's, running them in default Cygwin terminal (mintty) and read their output may prove to be a challenge. You could, however, use native console instead (i.e. running bash directly, instead of letting mintty do it). Combined with appropriate LANG= settings, that could be the way to go. P.S. --8<--8<--8<-- case "$TERM" in xterm*) LANG=ru_RU.UTF-8 ;; *) LANG=ru_RU.CP866 ;; esac export LANG -->8-->8-->8-- -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.11.2014, <21:57> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FW: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.5
>> I just released a 5th TEST version of the next upcoming Cygwin release, >> 1.7.33-0.5. > Ever since using this 1.7.33-0.x series (currently running 1.7.33-0.5) > I've been having intermittent trouble with one of my scripts, and just > finally got around to digging further today. This is an expect script It would appear, after a bit more digging, that this problem is related to some timeout issues. Most of the time the ssh login goes rapidly, but occasionally it takes quite a lot longer triggering the expect default timeout. When setting the timeout substantially longer, the reliability goes up substantially. Dave
Re: [ANNOUNCEMENT] Updated: gcc-4.9.2-1 (x86/x86_64) (Test)
On 03/11/2014 22:08, JonY wrote: gcc-4.9.2-1 has been uploaded for 32bit and 64bit Cygwin. This version is set to test. I've just noticed that gcc-java requires libgcj15. Given that libgcj15 is part of the test release, should the dependency be libgcj14? Dave. -- 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/deficiency in unzip: incompatible with other programs when entry path names have non-ascii chars
>On 2014-11-04 22:10, Yaakov wrote: > >>On 2014-11-04 20:08, Brent wrote: >> >>I then reran my complete test suite. Everything now works except the part >>of the test where cygwin unzip is to extract a zip file produced by Java. >>This particular zip file has entries whose path names are non-ASCII chars. >>I have manually verified that this zip file is perfectly extractable by >>7zip and WinZip, so Java does not seem to be the problem. > >Thank you for providing your test case. This is a known issue with unzip, and >the exact same things occurs with your test.zip on Linux: > >http://www.linuxfromscratch.org/blfs/view/svn/general/unzip.html Thanks. That link's "UnZip Locale Issues" section documents the wrong assumptions about character encoding made by unzip. Do you know if there are any plans to fix unzip? -- 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] TEST RELEASE: Cygwin 1.7.33-0.6
Corinna Vinschen wrote: Hi Cygwin friends and users, I just released a 6th TEST version of the next upcoming Cygwin release, 1.7.33-0.6. Looks good so far. An observation from my first test on a machine which is member of a domain: mkpasswd -l and -L always print the HOST prefix. mkpasswd -d and -D never print the DOMAIN prefix This likely would break creation of local 'technical' user accounts in existing *-config scripts (possibly including the csih script): e.g.: $ net user cyg_server PASSWORD /add $ mkpasswd -l -u cyg_server >> /etc/passwd Result: $ id cyg_server id: cyg_server: no such user $ id THISHOST+cyg_server uid= Now on my wishlist: an nsswitch.conf option to change the 'print prefix' behavior for machines in a domain. Christian -- 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
