Re: Newbie Questions

[Andrey Repin]

Greetings, Warren Young!

>> [C:\home\Daemon]$ bash -c ./foo.sh

> That's not the same command I gave you.  -c changes how bash.exe 
> interprets the following parameter.

According to `man bash', that's the correct command to execute scripts with
bash.

> It matters, because when you right-click a *.sh file in Windows 
> Explorer, say Open With, then tell Explorer to use bash.exe to open such 
> files now and in the future, it isn't going to stick -c in the command 
> for you.

> If you did change the file association in the registry, adding -c, that 
> still isn't going to help because Windows Explorer is going to pass the 
> full Windows-style path to bash.exe in place of the %1.  Plus you still 
> have the PATH issues I brought up in my previous email.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <12:13>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

$PATH contains dot but unclear where it comes from

[Robert Klemme]

Hi,

in cygwin64 on Win 7 64 bit I find "." in $PATH:

$ echo "$PATH" | tr : \\n | egrep '^\.$'
.

However, I was not able to detect where this came from.  It's neither
in the Windows system environment variables nor in the user
environment variables - as you can also see on a cmd prompt:

C:\Users\rklemme>path | find ";."

C:\Users\rklemme>path | find ".;"

C:\Users\rklemme>

There is nothing in rc files (you only see my workaround to remove it
which is commented ATM):

$ egrep -n '\..*PATH|PATH.*\.' .bash_profile .profile .bashrc
.bash_aliases /etc/profile /etc/bash*
.bash_profile:31:# remove "." from PATH
.bash_profile:32:# PATH=$(echo "$PATH" | sed -re
's#^:*\.:+##;s#:+\.:*$##;s#:+\.:+##g')
/etc/bash_completion:1092:# - stdout:  Filename of command in PATH
with possible symbolic links resolved.
/etc/bash_completion:1372:# completes on directories under those
specified in CDPATH.
/etc/bash_completion:1389:if [[ -z "${CDPATH:-}" || "$cur" ==
?(.)?(.)/* ]]; then
egrep: /etc/bash_completion.d: Is a directory

Do you have any idea where this might originate? I'd rather fix the
root cause than keep my workaround.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin-1.7.28 getpwent header declaration changes ?

[Corinna Vinschen]

On Feb  6 08:29, Marco Atzeri wrote:
> on cygwin-1.7.28 64 bit but not on cygwin-1.7.27,
> (only system difference) compiling octave I see:
> 
> 
> /pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
> :114:25: error: '::getpwent' has not been declared
>return octave_passwd (::getpwent (), msg);
>  ^
> [...]
> Is something slightly changed in the  relative system headers ?

I don't know anything about octave, but what has changed is that newlib
is finally introducing BSD-like visibility macros.  The pwd.h header now
contains this:

  #if __XSI_VISIBLE >= 500
  struct passwd   *getpwent (void);
  void setpwent (void);
  void endpwent (void);
  #endif

The default settings per the sys/cdefs.h header are:

  #define __POSIX_VISIBLE 200809
  #define __XSI_VISIBLE   700
  #define __BSD_VISIBLE   1
  #define __ISO_C_VISIBLE 2011

unless your environment defines one of

  _XOPEN_SOURCE
  _POSIX_C_SOURCE
  _ANSI_SOURCE
  _C99_SOURCE
  _C11_SOURCE
  _GNU_SOURCE

Have a look at the end of /usr/include/sys/cdefs.h, it explains things.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpN_cJUX75YH.pgp
Description: PGP signature

Re: $PATH contains dot but unclear where it comes from

[Csaba Raduly]

Hi Robert,

On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme  wrote:
> Hi,
>
> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>
> $ echo "$PATH" | tr : \\n | egrep '^\.$'
> .
>
> However, I was not able to detect where this came from.  It's neither
> in the Windows system environment variables nor in the user
> environment variables - as you can also see on a cmd prompt:

Windows always looks into the current directory when searching for
programs, so '.' is usually not in the Winows version of PATH (which
Cygwin imports).

Almost certainly, the dot was put into the PATH by one of the Bash
initialization files. Here are some off the top of my head (`info
bash` , 6.2 Bash startup files, has the complete list).

/etc/profile
/etc/bash.bashrc
~/.bash_profile
~/.profile
~/.bashrc


You can try running

bash -x --login

This will spew the shell commands being executed while interpreting
the startup scripts (make sure you have a large scroll-back buffer :)
Alternatively

bash -x --login > bash_init.txt 2>&1

then type 'exit' blindly into the terminal (maybe 'tee' would work
better but I don't have access to Cygwin right now).

If you saved to a file, you can grep for PATH and try to identify
which initialization file put the dot in.

HTH,
Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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-1.7.28 getpwent header declaration changes ?

[Marco Atzeri]

On 06/02/2014 10:01, Corinna Vinschen wrote:

On Feb  6 08:29, Marco Atzeri wrote:

on cygwin-1.7.28 64 bit but not on cygwin-1.7.27,
(only system difference) compiling octave I see:


/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
:114:25: error: '::getpwent' has not been declared
return octave_passwd (::getpwent (), msg);
  ^
[...]
Is something slightly changed in the  relative system headers ?


I don't know anything about octave, but what has changed is that newlib
is finally introducing BSD-like visibility macros.  The pwd.h header now
contains this:

   #if __XSI_VISIBLE >= 500
   struct passwd   *getpwent (void);
   void setpwent (void);
   void endpwent (void);
   #endif

The default settings per the sys/cdefs.h header are:

   #define __POSIX_VISIBLE 200809
   #define __XSI_VISIBLE   700
   #define __BSD_VISIBLE   1
   #define __ISO_C_VISIBLE 2011

unless your environment defines one of

   _XOPEN_SOURCE
   _POSIX_C_SOURCE
   _ANSI_SOURCE
   _C99_SOURCE
   _C11_SOURCE
   _GNU_SOURCE

Have a look at the end of /usr/include/sys/cdefs.h, it explains things.


Corinna


thanks for the hints

for what I can see  "_GNU_SOURCE" is defined in both cases at
configure stage and reported in config.status and config.h

I will look to compare the preprocessor output to see why building
on  1.7.28 the "/* Everything and the kitchen sink. */" is not pulled in

Regards
Marco







--
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: $PATH contains dot but unclear where it comes from

[Robert Klemme]

On Thu, Feb 6, 2014 at 10:14 AM, Csaba Raduly wrote:
> Hi Robert,
>
> On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme  wrote:
>> Hi,
>>
>> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>>
>> $ echo "$PATH" | tr : \\n | egrep '^\.$'
>> .
>>
>> However, I was not able to detect where this came from.  It's neither
>> in the Windows system environment variables nor in the user
>> environment variables - as you can also see on a cmd prompt:
>
> Windows always looks into the current directory when searching for
> programs, so '.' is usually not in the Winows version of PATH (which
> Cygwin imports).

I know. But this is completely irrelevant here as I am trying to
determine how the dot appeared in $PATH.

> Almost certainly, the dot was put into the PATH by one of the Bash
> initialization files. Here are some off the top of my head (`info
> bash` , 6.2 Bash startup files, has the complete list).
>
> /etc/profile
> /etc/bash.bashrc
> ~/.bash_profile
> ~/.profile
> ~/.bashrc

Apparently you did not really read my last email.

> You can try running
>
> bash -x --login
>
> This will spew the shell commands being executed while interpreting
> the startup scripts (make sure you have a large scroll-back buffer :)
> Alternatively
>
> bash -x --login > bash_init.txt 2>&1
>
> then type 'exit' blindly into the terminal (maybe 'tee' would work
> better but I don't have access to Cygwin right now).
>
> If you saved to a file, you can grep for PATH and try to identify
> which initialization file put the dot in.

I should have mentioned that I did just that - to no avail.

$ echo exit | bash --login -i -x 2>|log
$ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
140:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
145:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
152:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
159:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
166:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
171:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
178:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
183:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
190:+++ 
PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin

Also manual inspection does not show any line where the dot is
introduced.  The first line with an assignment to PATH which contains
the dot in the trace output is this one in /etc/profile:

PATH="/usr/local/bin:/usr/bin:${PATH}"

In the trace (see above):

+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

As you can see the dot is already there.  It seems it appears
somewhere in the mintty launching process.

Cheers

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: $PATH contains dot but unclear where it comes from

[Andrey Repin]

Greetings, Robert Klemme!

> I should have mentioned that I did just that - to no avail.

> $ echo exit | bash --login -i -x 2>|log
> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
> 140:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 145:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 152:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 159:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 166:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 171:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 178:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 183:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
> 190:+++ 
> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin

> Also manual inspection does not show any line where the dot is
> introduced.  The first line with an assignment to PATH which contains
> the dot in the trace output is this one in /etc/profile:

> PATH="/usr/local/bin:/usr/bin:${PATH}"

> In the trace (see above):

> + PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

> As you can see the dot is already there.  It seems it appears
> somewhere in the mintty launching process.

This seems much like you have an imposter somewhere in your system.
Please start cmd.exe alone, and do the following in order:

echo %PATH% > "%USERPROFILE%/bash-startup.log"
bash --login -x 2>&1 | tee -a "%USERPROFILE%/bash-startup.log"

Then check the logfile for issues.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <14:43>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin-1.7.28 getpwent header declaration changes ?

[Jan Nijtmans]

On Feb  6 08:29, Marco Atzeri wrote:
> Is something slightly changed in the  relative system headers ?

After upgrading to Cygwin 1.7.28, Sqlite doesn't compile any
more. See log below. When reverting to 1.7.27-2,
everything is back to normal.

The LOCK_EX macro's and friends are supposed to
be defined when including :

but they aren't any more.

I added a:
#define __BSD_VISIBLE 1
to sqliteInt.h (before all headers are included), then
everything works again.

Regards,
   Jan Nijtmans

==
sqlite3.c: In function 'flockCheckReservedLock':
sqlite3.c:25869:38: error: 'LOCK_EX' undeclared (first use in this function)
 int lrc = robust_flock(pFile->h, LOCK_EX | LOCK_NB);
  ^
sqlite3.c:25869:38: note: each undeclared identifier is reported only
once for e ach function it appears in
sqlite3.c:25869:48: error: 'LOCK_NB' undeclared (first use in this function)
 int lrc = robust_flock(pFile->h, LOCK_EX | LOCK_NB);
^
sqlite3.c:25872:36: error: 'LOCK_UN' undeclared (first use in this function)
   lrc = robust_flock(pFile->h, LOCK_UN);
^
sqlite3.c: In function 'flockLock':
sqlite3.c:25949:30: error: 'LOCK_EX' undeclared (first use in this function)
   if (robust_flock(pFile->h, LOCK_EX | LOCK_NB)) {
  ^
sqlite3.c:25949:40: error: 'LOCK_NB' undeclared (first use in this function)
   if (robust_flock(pFile->h, LOCK_EX | LOCK_NB)) {
^
sqlite3.c: In function 'flockUnlock':
sqlite3.c:25998:30: error: 'LOCK_UN' undeclared (first use in this function)
   if( robust_flock(pFile->h, LOCK_UN) ){
  ^
Makefile:563: recipe for target 'sqlite3.lo' failed
make: *** [sqlite3.lo] Error 1

--
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-1.7.28 getpwent header declaration changes ?

[Corinna Vinschen]

On Feb  6 14:00, Jan Nijtmans wrote:
> On Feb  6 08:29, Marco Atzeri wrote:
> > Is something slightly changed in the  relative system headers ?
> 
> After upgrading to Cygwin 1.7.28, Sqlite doesn't compile any
> more. See log below. When reverting to 1.7.27-2,
> everything is back to normal.
> 
> The LOCK_EX macro's and friends are supposed to
> be defined when including :
> 
> but they aren't any more.

They are.  There's an #include  in sys/file.h, which in
turn includes sys/fcntl.h which includes sys/_default_fcntl.h.

In sys/_default_fcntl.h, the LOCK_xx macros are defined if
__BSD_VISIBLE is defined, which *is* defined by default, unless you
define one of

  _ANSI_SOURCE
  _C99_SOURCE
  _C11_SOURCE
  _POSIX_C_SOURCE
  _XOPEN_SOURCE


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpJmSr76nlfn.pgp
Description: PGP signature

Re: cygwin-1.7.28 getpwent header declaration changes ?

[Corinna Vinschen]

On Feb  6 11:19, Marco Atzeri wrote:
> 
> 
> On 06/02/2014 10:01, Corinna Vinschen wrote:
> >On Feb  6 08:29, Marco Atzeri wrote:
> >>on cygwin-1.7.28 64 bit but not on cygwin-1.7.27,
> >>(only system difference) compiling octave I see:
> >>
> >>
> >>/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
> >>:114:25: error: '::getpwent' has not been declared
> >>return octave_passwd (::getpwent (), msg);
> >>  ^
> >>[...]
> >>Is something slightly changed in the  relative system headers ?
> >
> >I don't know anything about octave, but what has changed is that newlib
> >is finally introducing BSD-like visibility macros.  The pwd.h header now
> >contains this:
> >
> >   #if __XSI_VISIBLE >= 500
> >   struct passwd   *getpwent (void);
> >   void setpwent (void);
> >   void endpwent (void);
> >   #endif
> > [...]
> 
> thanks for the hints
> 
> for what I can see  "_GNU_SOURCE" is defined in both cases at
> configure stage and reported in config.status and config.h
> 
> I will look to compare the preprocessor output to see why building
> on  1.7.28 the "/* Everything and the kitchen sink. */" is not pulled in

Btw., it would be a good idea to get rid of calls to getpwent/getgrent
in future.  They *probably* won't do anymore what they were supposed to
do if you don't have passwd/group files.  A full implementation would
require to enumerate the local SAM and, at least, the primary domain
accounts at runtime.  That would be possible, but it comes at a hefty
price in terms of performance.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpCIQNQxFNQr.pgp
Description: PGP signature

Fwd: cygwin-1.7.28 getpwent header declaration changes ?

[Jan Nijtmans]

2014-02-06 15:02 GMT+01:00 Corinna Vinschen:
> In sys/_default_fcntl.h, the LOCK_xx macros are defined if
> __BSD_VISIBLE is defined, which *is* defined by default, unless you
> define one of
>
>   _ANSI_SOURCE
>   _C99_SOURCE
>   _C11_SOURCE
>   _POSIX_C_SOURCE
>   _XOPEN_SOURCE

Yes, SQLite defines _XOPEN_SOURCE in sqliteInt.h:



I could add a !defined(__CYGWIN__) there, but I prefer
just to define __BSD_VISIBLE.

Thanks!

Regards.

--
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-1.7.28 getpwent header declaration changes ?

[Corinna Vinschen]

On Feb  6 15:15, Jan Nijtmans wrote:
> 2014-02-06 15:02 GMT+01:00 Corinna Vinschen:
> > In sys/_default_fcntl.h, the LOCK_xx macros are defined if
> > __BSD_VISIBLE is defined, which *is* defined by default, unless you
> > define one of
> >
> >   _ANSI_SOURCE
> >   _C99_SOURCE
> >   _C11_SOURCE
> >   _POSIX_C_SOURCE
> >   _XOPEN_SOURCE
> 
> Yes, SQLite defines _XOPEN_SOURCE in sqliteInt.h:
> 
> 
> 
> I could add a !defined(__CYGWIN__) there, but I prefer
> just to define __BSD_VISIBLE.

On second thought, Linux defines the LOCK_xx macros unconditionally
in sys/file.h.  What we could do is to define the macros in sys/file.h
if they are not already defined because __BSD_VISIBLE wasn't set.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpOmrHVYGp5y.pgp
Description: PGP signature

Re: cygwin-1.7.28 getpwent header declaration changes ?

[Corinna Vinschen]

On Feb  6 15:28, Corinna Vinschen wrote:
> On Feb  6 15:15, Jan Nijtmans wrote:
> > 2014-02-06 15:02 GMT+01:00 Corinna Vinschen:
> > > In sys/_default_fcntl.h, the LOCK_xx macros are defined if
> > > __BSD_VISIBLE is defined, which *is* defined by default, unless you
> > > define one of
> > >
> > >   _ANSI_SOURCE
> > >   _C99_SOURCE
> > >   _C11_SOURCE
> > >   _POSIX_C_SOURCE
> > >   _XOPEN_SOURCE
> > 
> > Yes, SQLite defines _XOPEN_SOURCE in sqliteInt.h:
> > 
> > 
> > 
> > I could add a !defined(__CYGWIN__) there, but I prefer
> > just to define __BSD_VISIBLE.
> 
> On second thought, Linux defines the LOCK_xx macros unconditionally
> in sys/file.h.  What we could do is to define the macros in sys/file.h
> if they are not already defined because __BSD_VISIBLE wasn't set.

Jan, can you please check if SQlite builds *without* defining
__BSD_VISIBLE, but adding the following lines to /usr/include/sys/file.h;

Index: sys/file.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/sys/file.h,v
retrieving revision 1.8
diff -u -p -r1.8 file.h
--- sys/file.h  17 Jan 2014 11:01:46 -  1.8
+++ sys/file.h  6 Feb 2014 14:41:23 -
@@ -31,4 +31,16 @@
 #define L_INCR SEEK_CUR
 #define L_XTND SEEK_END
 
+/* Including  always defines flock & macros. */
+#if __BSD_VISIBLE - 0  == 0
+
+#define LOCK_SH0x01/* shared file lock */
+#define LOCK_EX0x02/* exclusive file lock */
+#define LOCK_NB0x04/* don't block when locking */
+#define LOCK_UN0x08/* unlock file */
+
+extern int flock _PARAMS ((int, int));
+
+#endif
+
 #endif


Thanks in advance,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpQAuZbwiKb_.pgp
Description: PGP signature

[ANNOUNCEMENT] Updated: openmpi-1.7.4-1

[Marco Atzeri]

Version 1.7.4-1  of packages

   libopenmpi
   libopenmpicxx1
   libopenmpifh2
   libopenmpiuse1
   libopenmpi-devel
   openmpi

are available in the Cygwin distribution:

CHANGES

Full upstream changes:
http://svn.open-mpi.org/svn/ompi/branches/v1.7/NEWS
http://www.open-mpi.org/community/lists/announce/2014/02/0059.php


DESCRIPTION
Open MPI : A High Performance Message Passing Library

The Open MPI Project is an open source MPI-2 implementation that
is developed and maintained by a consortium of academic, research,
and industry partners

HOMEPAGE
http://www.open-mpi.org/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the 
format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.

--
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: cygwin64 - installation problem - installed by administrator account

[Larry Hall (Cygwin)]

On 2/6/2014 1:42 AM, Flower, Martin wrote:




All scripts have .done.

Setup.log.full shows an error. I see the word McShield, and I link it to
BLODA. File C:\cygwin64\etc\setup\setup.rc exists - although I assume it
didn't exist when setup was started.

2014/02/05 10:05:28 Starting cygwin install, version 2.831
2014/02/05 10:05:28 User has backup/restore rights
2014/02/05 10:05:28 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2014/02/05 10:05:28 Current Directory: C:\Users\netflma\Downloads
2014/02/05 10:05:28 Could not open service McShield for query, start and stop. 
McAfee may not be installed, or we don't have access.
2014/02/05 10:05:38 source: network install
2014/02/05 10:05:42 source: download
2014/02/05 10:05:51 source: download
2014/02/05 10:05:52 Selected local directory: C:\Users\netflma\Downloads
2014/02/05 10:06:20 net: Proxy
Cached mirror list unavailable
get_url_to_membuf http://cygwin.com/mirrors.lst
getUrlToStream http://cygwin.com/mirrors.lst
2014/02/05 10:06:22 Ending cygwin install


This all looks fine to me.  Anything interesting in setup.log?


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: cygwin64 - installation problem - installed by administrator account

[Flower, Martin]

-Original Message-
From: cygwin-owner [mailto:cygwin-owner] On Behalf Of Larry Hall (Cygwin)
Sent: Thursday, February 06, 2014 3:49 PM
To: cygwin
Subject: Re: cygwin64 - installation problem - installed by administrator 
account

On 2/6/2014 1:42 AM, Flower, Martin wrote:



> All scripts have .done.
>
> Setup.log.full shows an error. I see the word McShield, and I link it 
> to BLODA. File C:\cygwin64\etc\setup\setup.rc exists - although I 
> assume it didn't exist when setup was started.
>
> 2014/02/05 10:05:28 Starting cygwin install, version 2.831
> 2014/02/05 10:05:28 User has backup/restore rights
> 2014/02/05 10:05:28 io_stream_cygfile: fopen(/etc/setup/setup.rc) 
> failed 2 No such file or directory
> 2014/02/05 10:05:28 Current Directory: C:\Users\netflma\Downloads
> 2014/02/05 10:05:28 Could not open service McShield for query, start and 
> stop. McAfee may not be installed, or we don't have access.
> 2014/02/05 10:05:38 source: network install
> 2014/02/05 10:05:42 source: download
> 2014/02/05 10:05:51 source: download
> 2014/02/05 10:05:52 Selected local directory: 
> C:\Users\netflma\Downloads
> 2014/02/05 10:06:20 net: Proxy
> Cached mirror list unavailable
> get_url_to_membuf http://cygwin.com/mirrors.lst getUrlToStream 
> http://cygwin.com/mirrors.lst
> 2014/02/05 10:06:22 Ending cygwin install

This all looks fine to me.  Anything interesting in setup.log?


--
Larry

_

Here is setup.log

2014/02/05 10:05:28 Starting cygwin install, version 2.831
2014/02/05 10:05:28 User has backup/restore rights
2014/02/05 10:05:28 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2014/02/05 10:05:28 Current Directory: C:\Users\netflma\Downloads
2014/02/05 10:05:28 Could not open service McShield for query, start and stop. 
McAfee may not be installed, or we don't have access.
2014/02/05 10:05:38 source: network install
2014/02/05 10:05:42 source: download
2014/02/05 10:05:51 source: download
2014/02/05 10:05:52 Selected local directory: C:\Users\netflma\Downloads
2014/02/05 10:06:20 net: Proxy
2014/02/05 10:06:22 Ending cygwin install



In my opinion, this has taken up enough of your time, so I suggest we leave the 
investigation there. I have reinstalled Git for Windows (MINGW32), and that 
seems to work ok.

/Martin


--
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: $PATH contains dot but unclear where it comes from

[Robert Klemme]

On Thu, Feb 6, 2014 at 12:56 PM, Andrey Repin wrote:
> Greetings, Robert Klemme!

Hello Andrey!

>> I should have mentioned that I did just that - to no avail.
>
>> $ echo exit | bash --login -i -x 2>|log
>> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
>> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
>> 140:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 145:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 152:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 159:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 166:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 171:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 178:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 183:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>> 190:+++ 
>> PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:/usr/local/sbin
>
>> Also manual inspection does not show any line where the dot is
>> introduced.  The first line with an assignment to PATH which contains
>> the dot in the trace output is this one in /etc/profile:
>
>> PATH="/usr/local/bin:/usr/bin:${PATH}"
>
>> In the trace (see above):
>
>> + PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
>
>> As you can see the dot is already there.  It seems it appears
>> somewhere in the mintty launching process.
>
> This seems much like you have an imposter somewhere in your system.
> Please start cmd.exe alone, and do the following in order:

Good idea to do it in cmd.exe!

> echo %PATH% > "%USERPROFILE%/bash-startup.log"
> bash --login -x 2>&1 | tee -a "%USERPROFILE%/bash-startup.log"

Why use tee here?  I did this:

C:\Users\rklemme>path >log

C:\Users\rklemme>echo exit | c:\cygwin64\bin\bash.exe --login -x -i >>log 2>&1

> Then check the logfile for issues.

Same story.  These are the first lines of the log

$ head -10 log | cut -c 1-80
PATH=C:\PROGRAM FILES (X86)\NVIDIA CORPORATION\PHYSX\COMMON;C:\PROGRAM FILES (X8
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
+ PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATI
+ MANPATH=/usr/local/man:/usr/share/man:/usr/man:
+ INFOPATH=/usr/local/info:/usr/share/info:/usr/info:
++ id -un
+ USER=rklemme
+ ORIGINAL_TMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp
+ ORIGINAL_TEMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp

The first line does not contain the dot.  The fourth line contains the
dot at the end:

$ sed -nre '4s#^(.{20}).*(.{80})$#\1...\2#p' log
+ 
PATH='/usr/local/b...Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.'

Concluding from the context (following lines) this is, as written
before, this line from /etc/profile:

PATH="/usr/local/bin:/usr/bin:${PATH}"
MANPATH="/usr/local/man:/usr/share/man:/usr/man:${MANPATH}"
INFOPATH="/usr/local/info:/usr/share/info:/usr/info:${INFOPATH}"

There is clearly no dot there. It's a mystery.

Wait, I tested with strace:

C:\Users\rklemme>echo exit | c:\cygwin64\bin\strace.exe -f /bin/bash
--login -x -i >str 2>&1

I found
...
   366393 [main] bash 8028 getwinenv: can't set native for PATH=
since no environ yet
...
   127518 [main] bash 8028 mount_info::conv_to_posix_path:
conv_to_posix_path (C:\Users\rklemme\Applications\SysinternalsSuite,
keep-rel, no-add-slash)
   127530 [main] bash 8028 normalize_win32_path:
C:\Users\rklemme\Applications\SysinternalsSuite = normalize_win32_path
(C:\Users\rklemme\Applications\SysinternalsSuite)
   147544 [main] bash 8028 mount_info::conv_to_posix_path:
/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite =
conv_to_posix_path (C:\Users\rklemme\Applications\SysinternalsSuite)
   147558 [main] bash 8028 mount_info::conv_to_posix_path:
conv_to_posix_path (., keep-rel, no-add-slash)
   127570 [main] bash 8028 mount_info::conv_to_posix_path: . =
conv_to_posix_path (.)
   127582 [main] bash 8028 __set_errno: ssize_t
env_PATH_to_posix(const void*, void*, size_t):3570 setting errno 36
...
   12   12308 [main] bash 8028 mount_info::conv_to_win32_path:
src_path /cygdrive/c/Users/rklemme/Applications/SysinternalsSuite, dst
C:\Users\rklemme\Applications\SysinternalsSuite, flags 0x4022, rc 0
   35   12343 [main] bash 8028 symlink_info::check: 0x0 = NtCreateFile
(\??\C:\Users\rklemme\Applications\SysinternalsSuite)
   18   12361 [main] bash 8028 symlink_info::check: not a symlink
   21   12382 [main] bash 

Re: Clearing the buffer after quitting LESS, MAN, VIM etc.

[Dawid Ferenczy]

Christopher Faylor  cygwin.com> writes:

> You're apparently not using a snapshot.
> 
> cgf


I love you! :)

It's very close to be perfect now. When I scroll by individual lines, it 
works fine. But when I try to scroll by pages, the screen is repainted 
between prompts only. If there are 3 lines between prompts (one prompt on 
bottom of the screen, 3 lines of output above and previous prompt above), 
only that 3 lines and the most bottom prompt are repainted with buffer. So 
one prompt on the bottom is repainted and it repeats with the prompt above. 
If there is no prompt on current screen (e.g. long output), the whole screen 
is repainted. Is it clear from my description?

-- 
 Dawid Ferenczy
 http://ferenczy.cz


--
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

Cygwin directory slash problem

[ajit samant]

I would like some help on setting up Cygwin directory slash problem. when i
type like /cygdrive/e/  then cygwin was looking for path that starts with
\cygdrive\e\ . Means cygwin   consider my forward slash as backslash and
shows error in path.
Have any Idea.

Thanks
Ajit



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Cygwin-directory-slash-problem-tp106042.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin directory slash problem

[Larry Hall (Cygwin)]

On 2/6/2014 11:40 AM, ajit samant wrote:

I would like some help on setting up Cygwin directory slash problem. when i
type like /cygdrive/e/  then cygwin was looking for path that starts with
\cygdrive\e\ . Means cygwin   consider my forward slash as backslash and
shows error in path.


No.  So let's start with the link below.  Please read and follow the
guidelines for submitting a complete problem report.  Don't forget to
*attach* the cygcheck output.


Problem reports:   http://cygwin.com/problems.html



--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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

Newbie Cygdrive questions

[mrushton]

Ok ... I am converting my scripts and making progress. 

But I have a question.  

My old shell software would let me have a path as : 

X:/INBOUND/CWSCRIPTS/myscript.sh


To access this shared X drive under Cygwin it seems I have to do this : 

/cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh


Is this correct ?  Is there a better way ?  

And C: seems to be /cygdrive/C/

--
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: Newbie Cygdrive questions

[Larry Hall (Cygwin)]

On 2/6/2014 1:53 PM, mrushton wrote:

Ok ... I am converting my scripts and making progress.

But I have a question.

My old shell software would let me have a path as :

X:/INBOUND/CWSCRIPTS/myscript.sh


To access this shared X drive under Cygwin it seems I have to do this :

/cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh


Is this correct ?  Is there a better way ?

And C: seems to be /cygdrive/C/


Cygwin uses POSIX paths and this is the mechanism it uses to provide
access to the drives using a POSIX path.  So yes, this is the correct
way to do what you want.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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

qsort_r and libc.a version?

[Jim Garrison]

I tried to build libgit2 so I could try to build gitg but encountered

undefined reference to `qsort_r'

GitHub has a closed issue for this 
https://github.com/libgit2/libgit2/issues/1606 saying that qsort_r was added to 
glibc in version 2.8, released in 2008.

Since libc in Cygwin is part of the base package, how would I find out which 
upstream version it's based on?  

There was a commit in libgit2 that was supposed to fix this :

https://github.com/libgit2/libgit2/commit/0d77647adc1f76df66e437e6442d7f7706e2c38e#diff-bb2cd4651768482b99cb1c52d29ceffdR694

but I don't know enough about Cygwin internals to determine why it still fails 
on Cygwin.

--
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: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

On 2/6/2014 8:50 AM, Steven Bardwell wrote:



On 2/5/2014 7:07 AM, Steven Bardwell wrote:

I have no problem doing some recoding of my application to reliably

solve

my

issues with fork() -- can you all
point me in the direction of the 'spawn family of calls'?


See spawn.cc ->



--
Larry



Larry - thanks for the link to the source for the spawn() APIs.  It works
perfectly on my 32-bit install (where, as it happens, the fork() issue
never shows up either).

However, on my 64-bit install, the spawnv() call is returning with an
error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
I have attached the output from 'strace' on this process. If you look at
line 602, I think you can see where the exception gets generated. Can
you see what is going on? I tried to create a simple test program that
shows the problem, but (so far) they all work. Thanks.


Interesting.  No, off hand, the strace output doesn't shed any light on
the situation for me either.  Clearly an access violation occurs when
/bin/sh is spawned but if it only happens in your specific code and not
in a simple invocation of spawn(), that suggests a possible usage problem.
I know, that's not much help. ;-)

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: qsort_r and libc.a version?

[Larry Hall (Cygwin)]

On 2/6/2014 2:04 PM, Jim Garrison wrote:

I tried to build libgit2 so I could try to build gitg but encountered

 undefined reference to `qsort_r'

GitHub has a closed issue for this
https://github.com/libgit2/libgit2/issues/1606 saying that qsort_r was added
to glibc in version 2.8, released in 2008.

Since libc in Cygwin is part of the base package, how would I find out
which upstream version it's based on?


Cygwin uses newlib for its C library.  From what I can see, qsort is there
but qsort_r isn't.


There was a commit in libgit2 that was supposed to fix this :

https://github.com/libgit2/libgit2/commit/0d77647adc1f76df66e437e6442d7f7706e2c38e#diff-bb2cd4651768482b99cb1c52d29ceffdR694

but I don't know enough about Cygwin internals to determine why it still
fails on Cygwin.


The problem with that patch is that it doesn't take Cygwin into account.
If you append a check for Cygwin there as well (i.e. defined(__CYGWIN__) )
then that should resolve the compile issue.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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 SSH and msysGit

[Someone Somebody]

 I did some additional research of my own, it seems that the only
thing that should really be os dependent is in the working dir and the
index file and since this is not relevant for pure push/fetch I think
it might work ok using Cygwin's Git.

But who knows... msysGit includes a lot of different patches to get it
to work well in Windows and many of them are not merged into the core
Git and who knows really whether one of them can affects this.

Also I think trying to add msysGit after the Cygwin $PATH might still
have something explode since the binaries in the libexec/git-core are
dependent on dlls in the bin directory... and they might have similar
names to Cygwin binaries and having the Cygwin dlls earlier in the
$PATH might cause it to bomb. (Git seems to invoke "git-receive-pack",
"git-upload-pack" vs "git receive-pack", "git upload-pack" requiring
the libexec/git-core directory).

I might just have to ask on the msysGit mailing list :P

Thanks.

--
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: Newbie Cygdrive questions

[Richard]

On Thu, 6 Feb 2014, mrushton wrote:


To access this shared X drive under Cygwin it seems I have to do this :

/cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh


Is this correct ?  Is there a better way ?

And C: seems to be /cygdrive/C/



A BETTER way?

This has nothing per se to do with Cygwin, but, briefly:

Standardize all your systems on something YOU can control. For example, I 
always create a top-level directory called l (that's the letter, not the 
numeral) which stands for "local", and another called nfs, which simply 
means a remote mount - could be real nfs or Samba - and then make links 
within these directories to wherever they need to go. That way, all disk 
space is available via either:


/l/

or

/nfs/

as appropriate.

And there's never any confusion over which is which - and drive letters 
can be completely avoided as desired, or not.


...All (many!) good System Administrators do things similar to this...

Richard

--
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 SSH and msysGit

[Christopher Faylor]

On Thu, Feb 06, 2014 at 09:46:50PM +0200, Someone Somebody wrote:
> I did some additional research of my own, it seems that the only
>thing that should really be os dependent is in the working dir and the
>index file and since this is not relevant for pure push/fetch I think
>it might work ok using Cygwin's Git.
>
>But who knows... msysGit includes a lot of different patches to get it
>to work well in Windows and many of them are not merged into the core
>Git and who knows really whether one of them can affects this.
>
>Also I think trying to add msysGit after the Cygwin $PATH might still
>have something explode since the binaries in the libexec/git-core are
>dependent on dlls in the bin directory... and they might have similar
>names to Cygwin binaries and having the Cygwin dlls earlier in the
>$PATH might cause it to bomb. (Git seems to invoke "git-receive-pack",
>"git-upload-pack" vs "git receive-pack", "git upload-pack" requiring
>the libexec/git-core directory).
>
>I might just have to ask on the msysGit mailing list :P

As MSYS is actually a competing project, we don't support any MSYS
utilities here and aren't terribly interested in hearing about
interaction problems with Cygwin.  So asking for help there is probably
for the best, although you could have the same problem in reverse.

--
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: Newbie Questions

[Warren Young]

On 2/6/2014 01:13, Andrey Repin wrote:

Greetings, Warren Young!


[C:\home\Daemon]$ bash -c ./foo.sh



That's not the same command I gave you.  -c changes how bash.exe
interprets the following parameter.


According to `man bash', that's the correct command to execute scripts with
bash.


Are you trolling?

$ man bash

SYNOPSIS
   bash [options] [file]

...

ARGUMENTS
   If arguments remain after option processing, and neither the -c
   nor the -s  option  has  been supplied, the first argument is
   assumed to be the name of a file containing shell commands.



In other words, bash behaves exactly as I said originally, and Windows 
Explorer isn't wrong to call Bash with just the name of a script, when 
you tell it that all *.sh open with bash.exe.


--
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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)

[Warren Young]

On 2/6/2014 07:13, Corinna Vinschen wrote:


Btw., it would be a good idea to get rid of calls to getpwent/getgrent
in future.  They *probably* won't do anymore what they were supposed to
do if you don't have passwd/group files.


There must be a way to list an executable's DLL imports, and thereby do 
a survey on Cygwin to see which executables currently import those 
functions.  If so, I know a guy who currently has all of Cygwin 
downloaded and ready to re-install, to test this. :)


I tried futzing with objdump, nm, and dumpbin, and couldn't get anything 
useful.  Mainly what I got was either irrelevant or complaints of the 
"no string table" sort.


> A full implementation would

require to enumerate the local SAM and, at least, the primary domain
accounts at runtime.  That would be possible, but it comes at a hefty
price in terms of performance.


Linux and Cygwin are pretty much the last ones standing when it comes to 
preferentially reading plain text files in /etc for user info.  Big iron 
Unix, the BSDs, and Mac OS X now all treat these files as secondary to 
some behind-the-scenes database.


In some of these systems, you can edit /etc/foo and run a command to 
manually sync that content back to the "real" user info DB.  (e.g. the 
BSDs)  In others, direct edits to these files are ignored, but the OS 
syncs a subset of changes to the user info DB to these files, for the 
benefit of getpwent() and friends.  (e.g. Mac OS X.)


In Cygwin, we have a kind of hybrid of these, owing to the fact that the 
integration between Cygwin and Windows is pretty much one-way.  We have 
mkpasswd/group, which treats the DB as primary, like OS X, but which 
must be run manually to sync changes, like the BSDs.


I don't see a reason for this to change, given that so many other POSIX 
systems share aspects of this behavior.


It would be nicer if Cygwin behaved more like OS X in this regard. 
That is, for mkpasswd/group to be run automatically when the SAM/AD 
changes.  I don't see Microsoft doing that for us, though.


The only way I can think of for Cygwin to do that for itself would be to 
run mkpasswd/group from setup.exe, in the same way that it runs 
autorebase.


I realize the current recommended practice is to keep /etc/foo as small 
as possible, but shouldn't an AD/SAM DB lookup be faster than a linear 
scan of a large /etc/foo file?  Why lament the fact that getpwent() is 
slow, when getpwnam() is its logical replacement, and presumably much 
faster?


(I assume getpwnam() consults SAM/AD in Cygwin, now or in Cygwin.next.)

Here's the Mac OS X passwd(5) man page: http://goo.gl/AwIHku

It's relevant here because Mac OS X uses OpenDirectory, an LDAP 
directory server.  In that way, it is not unlike future-Cygwin+AD.


--
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: using spawn functions to avoid fork() errors

[Steven Bardwell]

> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
> > Larry - thanks for the link to the source for the spawn() APIs.  It
works
> > perfectly on my 32-bit install (where, as it happens, the fork() issue
> > never shows up either).
> >
> > However, on my 64-bit install, the spawnv() call is returning with an
> > error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
> > I have attached the output from 'strace' on this process. If you look at
> > line 602, I think you can see where the exception gets generated. Can
> > you see what is going on? I tried to create a simple test program that
> > shows the problem, but (so far) they all work. Thanks.
> 
> Interesting.  No, off hand, the strace output doesn't shed any light on
> the situation for me either.  Clearly an access violation occurs when
> /bin/sh is spawned but if it only happens in your specific code and not
> in a simple invocation of spawn(), that suggests a possible usage problem.
> I know, that's not much help. ;-)
> 
> --
> Larry
> 
I am still trying to create a simple example, but the fact that it works on
the 32-bit
install inspired me to look again at the strace output, comparing the output
from
the install that works with the 64-bit strace output that shows the problem.

Can you look at this section?   /bin/sh (the program that is getting
spawned) 
gets loaded and starts running with PID 1464, but /bin/sh is failing :

   47 8674492 [main] ulpd 2116 child_info::sync: n 2, waiting for
subproc_ready(0x258) and child process(0x26C)
4   4 [main] sh (1464)
**
  296 300 [main] sh (1464) Program name: C:\cygwin64\bin\sh.exe (windows
pid 1464)
   52 352 [main] sh (1464) OS version:   Windows NT-6.1
   34 386 [main] sh (1464)
**
  233 619 [main] sh (1464) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
0x0)
  287 906 [main] sh 1464 child_copy: cygheap - hp 0x254 low 0x1802DA410,
high 0x1802E46D0, res 1
  1221028 [main] sh 1464 child_copy: done --- Process 1464, exception
c005 at 0001800448D0

My process (PID=2116) creates the new process (/bin/sh with PID=1464), but
then /bin/sh craps out.
Does that shed any light on what might be the issue?

Steve




--
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: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

On 2/6/2014 5:14 PM, Steven Bardwell wrote:



On 2/6/2014 8:50 AM, Steven Bardwell wrote:

Larry - thanks for the link to the source for the spawn() APIs.  It

works

perfectly on my 32-bit install (where, as it happens, the fork() issue
never shows up either).

However, on my 64-bit install, the spawnv() call is returning with an
error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
I have attached the output from 'strace' on this process. If you look at
line 602, I think you can see where the exception gets generated. Can
you see what is going on? I tried to create a simple test program that
shows the problem, but (so far) they all work. Thanks.


Interesting.  No, off hand, the strace output doesn't shed any light on
the situation for me either.  Clearly an access violation occurs when
/bin/sh is spawned but if it only happens in your specific code and not
in a simple invocation of spawn(), that suggests a possible usage problem.
I know, that's not much help. ;-)

--
Larry


I am still trying to create a simple example, but the fact that it works on
the 32-bit
install inspired me to look again at the strace output, comparing the output
from
the install that works with the 64-bit strace output that shows the problem.

Can you look at this section?   /bin/sh (the program that is getting
spawned)
gets loaded and starts running with PID 1464, but /bin/sh is failing :

47 8674492 [main] ulpd 2116 child_info::sync: n 2, waiting for
subproc_ready(0x258) and child process(0x26C)
 4   4 [main] sh (1464)
**
   296 300 [main] sh (1464) Program name: C:\cygwin64\bin\sh.exe (windows
pid 1464)
52 352 [main] sh (1464) OS version:   Windows NT-6.1
34 386 [main] sh (1464)
**
   233 619 [main] sh (1464) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
0x0)
   287 906 [main] sh 1464 child_copy: cygheap - hp 0x254 low 0x1802DA410,
high 0x1802E46D0, res 1
   1221028 [main] sh 1464 child_copy: done --- Process 1464, exception
c005 at 0001800448D0

My process (PID=2116) creates the new process (/bin/sh with PID=1464), but
then /bin/sh craps out.
Does that shed any light on what might be the issue?


/bin/sh is crashing, for sure, but it's not clear to me why that would
be the case.  It certainly has something to do with the way it's being
invoked.  But whether that's the problem (i.e. GIGO) or whether there's
something wrong on the Cygwin side that your usage is conveniently
bringing to light, I can't say.  I'm assuming the former given your
description so far.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Newbie Cygdrive questions

[David Conrad]

It may be useful to know, if you do not already, that the cygpath
utility can be used to convert between Windows and Unix paths.

cygpath -u X:/INBOUND/CWSCRIPTS/myscript.sh

will give you /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh, and

cygpath -w /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh

will give you X:\INBOUND\CWSCRIPTS\myscript.sh

You can also use cygpath -m if you prefer forward slashes, even in
your Windows paths.


On Thu, Feb 6, 2014 at 3:03 PM, Richard  wrote:
>
> On Thu, 6 Feb 2014, mrushton wrote:
>>
>>
>> To access this shared X drive under Cygwin it seems I have to do this :
>>
>> /cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh
>>
>>
>> Is this correct ?  Is there a better way ?
>>
>> And C: seems to be /cygdrive/C/
>>
>
> A BETTER way?
>
> This has nothing per se to do with Cygwin, but, briefly:
>
> Standardize all your systems on something YOU can control. For example, I
> always create a top-level directory called l (that's the letter, not the
> numeral) which stands for "local", and another called nfs, which simply
> means a remote mount - could be real nfs or Samba - and then make links
> within these directories to wherever they need to go. That way, all disk
> space is available via either:
>
> /l/
>
> or
>
> /nfs/
>
> as appropriate.
>
> And there's never any confusion over which is which - and drive letters can
> be completely avoided as desired, or not.
>
> ...All (many!) good System Administrators do things similar to this...
>
> Richard
>
>
> --
> 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
>

--
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: using spawn functions to avoid fork() errors

[David Conrad]

>>> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
 However, on my 64-bit install, the spawnv() call is returning with an
 error -- 'No such file or  directory' -- when I try to spawn /bin/sh.

A few things come to mind as possibilities to check, or try. First,
there is a certain amount of magic that cygwin does to treat
/bin/sh.exe and /bin/sh the same. What happens if you spawn
/bin/sh.exe instead of /bin/sh? Second, what happens if you use
spawnvp instead of spawnv? Although, from the strace excerpt it
doesn't look like it's actually having trouble finding the executable,
so those probably aren't it. Still, worth checking, perhaps.

Third, are you certain you are NULL-terminating the array of
arguments? If you aren't doing so explicitly, it is possible there
happened to be a NULL pointer just after the arguments in memory for
the 32-bit version, so it happened to work, but that didn't happen for
the 64-bit version. The argv array must have a NULL at the end of it.
Fourth, what are you passing to the mode parameter of spawnv?

Or, fifth, I dunno what the problem is. Those are my only ideas. Good luck.

David

--
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: qsort_r and libc.a version?

[Jim Garrison]

> -Original Message-
> Behalf Of Larry Hall (Cygwin)
> Sent: Thursday, February 06, 2014 11:39 AM
> Subject: Re: qsort_r and libc.a version?
> 
> On 2/6/2014 2:04 PM, Jim Garrison wrote:
> > I tried to build libgit2 so I could try to build gitg but encountered
> >
> >  undefined reference to `qsort_r'
> >
> > GitHub has a closed issue for this
> > https://github.com/libgit2/libgit2/issues/1606 saying that qsort_r was
> > added to glibc in version 2.8, released in 2008.
> >
> > Since libc in Cygwin is part of the base package, how would I find out
> > which upstream version it's based on?
> 
> Cygwin uses newlib for its C library.  From what I can see, qsort is there but
> qsort_r isn't.
> 
> > There was a commit in libgit2 that was supposed to fix this :
> >
> >
> https://github.com/libgit2/libgit2/commit/0d77647adc1f76df66e437e6442d
> > 7f7706e2c38e#diff-bb2cd4651768482b99cb1c52d29ceffdR694
> >
> > but I don't know enough about Cygwin internals to determine why it
> > still fails on Cygwin.
> 
> The problem with that patch is that it doesn't take Cygwin into account.
> If you append a check for Cygwin there as well (i.e. defined(__CYGWIN__) )
> then that should resolve the compile issue.
> 
> --
> Larry

So the correct patch for this would be to treat __CYGWIN__ the same as 
__MINGW32__ and use the internal git__insertsort_r function?

--
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: qsort_r and libc.a version?

[Larry Hall (Cygwin)]

On 2/6/2014 6:29 PM, Jim Garrison wrote:

-Original Message-
Behalf Of Larry Hall (Cygwin)
Sent: Thursday, February 06, 2014 11:39 AM
Subject: Re: qsort_r and libc.a version?

On 2/6/2014 2:04 PM, Jim Garrison wrote:

I tried to build libgit2 so I could try to build gitg but encountered

  undefined reference to `qsort_r'

GitHub has a closed issue for this
https://github.com/libgit2/libgit2/issues/1606 saying that qsort_r was
added to glibc in version 2.8, released in 2008.

Since libc in Cygwin is part of the base package, how would I find out
which upstream version it's based on?


Cygwin uses newlib for its C library.  From what I can see, qsort is there but
qsort_r isn't.


There was a commit in libgit2 that was supposed to fix this :



https://github.com/libgit2/libgit2/commit/0d77647adc1f76df66e437e6442d

7f7706e2c38e#diff-bb2cd4651768482b99cb1c52d29ceffdR694

but I don't know enough about Cygwin internals to determine why it
still fails on Cygwin.


The problem with that patch is that it doesn't take Cygwin into account.
If you append a check for Cygwin there as well (i.e. defined(__CYGWIN__) )
then that should resolve the compile issue.

--
Larry


So the correct patch for this would be to treat __CYGWIN__ the same as
__MINGW32__ and use the internal git__insertsort_r function?


Yes, give that a try.  This branch may work for Cygwin without any
further changes on either side.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: perl-Text-CSV_XS-1.04-1

[David Stacey]

Version 1.04-1 of perl-Text-CSV_XS has been uploaded.

CHANGE LOG
==

1.04- 2014-02-01, H.Merijn Brand
* get_columnd () with no argument now returns the empty list
  instead of undef when no columns defined
* fragments (rcf7111) now also support AoH (was AoA only)
* Error code conflict for fragments resolved to 2013
* New function "csv" (not a method)


DESCRIPTION
===

Text::CSV_XS provides facilities for the composition and decomposition
of comma-separated values. An instance of the Text::CSV_XS class will
combine fields into a CSV string and parse a CSV string into fields.

The module accepts either strings or files as input and support the use
of user-specified characters for delimiters, separators, and escapes.


CPAN


http://search.cpan.org/~hmbrand/Text-CSV_XS-1.04/CSV_XS.pm


Cheers,

Dave.



If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in
the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.

--
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: Newbie Cygdrive questions

[Mike Rushton]

That is good to know about that utility Cygpath.   Maybe I will try it.

What I was doing was going thru some scripts ... changing the paths ... 
clean in up stuff ...
over the years I ended up with a lot of commented out sections of code 
... and testing them.




And this is a different approach that I never would have thought of.

/l/

or

/nfs/



Thanks.


On 2/6/2014 5:37 PM, David Conrad wrote:

It may be useful to know, if you do not already, that the cygpath
utility can be used to convert between Windows and Unix paths.

cygpath -u X:/INBOUND/CWSCRIPTS/myscript.sh

will give you /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh, and

cygpath -w /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh

will give you X:\INBOUND\CWSCRIPTS\myscript.sh

You can also use cygpath -m if you prefer forward slashes, even in
your Windows paths.


On Thu, Feb 6, 2014 at 3:03 PM, Richard  wrote:

On Thu, 6 Feb 2014, mrushton wrote:


To access this shared X drive under Cygwin it seems I have to do this :

/cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh


Is this correct ?  Is there a better way ?

And C: seems to be /cygdrive/C/


A BETTER way?

This has nothing per se to do with Cygwin, but, briefly:

Standardize all your systems on something YOU can control. For example, I
always create a top-level directory called l (that's the letter, not the
numeral) which stands for "local", and another called nfs, which simply
means a remote mount - could be real nfs or Samba - and then make links
within these directories to wherever they need to go. That way, all disk
space is available via either:

/l/

or

/nfs/

as appropriate.

And there's never any confusion over which is which - and drive letters can
be completely avoided as desired, or not.

...All (many!) good System Administrators do things similar to this...

Richard


--
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




--
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: Newbie Cygdrive questions

[Andrey Repin]

Greetings, mrushton!

> Ok ... I am converting my scripts and making progress. 

> But I have a question.  

> My old shell software would let me have a path as : 

> X:/INBOUND/CWSCRIPTS/myscript.sh


> To access this shared X drive under Cygwin it seems I have to do this : 

> /cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh


> Is this correct ?  Is there a better way ?  

> And C: seems to be /cygdrive/C/

The true answer is - "depends"...
If you do not need interoperation between Cygwin and pure Windows stuff, you
could use either scheme, but the latter is preferred under Cygwin banner.
In case you DO need to work with Windows tools, the former scheme would
satisfy both worlds. (Windows does not see a difference betwen \ and / as
directory separators on the very low level, but this matters for a lot of
Cygwin tools.)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 07.02.2014, <04:33>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Newbie Cygdrive questions

[Mike Rushton]

I see.


What would you say to this ?

I have to use an EDI translator - it runs under windows/dos and had unix 
versions


I was trying this ... but the program needed to see the path of a config 
file ... after the -cp switch.


/cygdrive/c/gentran61SA/lftran /cygdrive/c/gentran61sa/data/EDN -id -cp 
/cygdrive/c/Gentran61SA


It gave me errors can not open file /cygdrive/c/Gentran61SA\ediprim.cfg.  It 
was like the program could not figure out
what style of paths to use.

I changed it to :  (escape out of bash and run this code)

! c:/gentran61SA/lftran c:/gentran61sa/data/EDN -id -cp c:/Gentran61SA

and it worked perfectly.Is there a better way to do this ?








On 2/6/2014 7:39 PM, Andrey Repin wrote:

Greetings, mrushton!


Ok ... I am converting my scripts and making progress.
But I have a question.
My old shell software would let me have a path as :
X:/INBOUND/CWSCRIPTS/myscript.sh



To access this shared X drive under Cygwin it seems I have to do this :
/cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh



Is this correct ?  Is there a better way ?
And C: seems to be /cygdrive/C/

The true answer is - "depends"...
If you do not need interoperation between Cygwin and pure Windows stuff, you
could use either scheme, but the latter is preferred under Cygwin banner.
In case you DO need to work with Windows tools, the former scheme would
satisfy both worlds. (Windows does not see a difference betwen \ and / as
directory separators on the very low level, but this matters for a lot of
Cygwin tools.)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 07.02.2014, <04:33>

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

[ANNOUNCEMENT] Updated: python-openssl, New: python3-openssl

[Yaakov (Cygwin/X)]

The following packages have been updated for both arches:

* python-openssl-0.13.1-1
* python3-openssl-0.13.1-1 (NEW)

This package provides Python bindings for the OpenSSL libraries.

This is an update to the latest upstream release, and the first to be 
built for Python 3.x.


--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: ruby-1.9.3-p484-1

[Yaakov (Cygwin/X)]

The following packages have been updated for both arches:

*** ruby-1.9.3-p484-1
*** ruby-doc-1.9.3-p484-1
*** ruby-tcltk-1.9.3-p484-1

Ruby is an interpreted scripting language for quick and easy
object-oriented programming.

This is an update to the latest upstream patch release, which includes a 
fix for CVE-2013-4164.  RubyGems now uses the ca-certificates package 
instead of a bundled copy.


--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: ca-certificates-1.96-3

[Yaakov (Cygwin/X)]

The following package has been updated for the Cygwin distribution:

*** ca-certificates-1.96-3

ca-certificates contains the Certificate Authority root certificates
needed for verifying SSL certificates.

This release provides symlinks in a couple more places to match 
hardcoded locations in a wider variety of software.


--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: Newbie Cygdrive questions

[Mike Rushton]

Good ... I will have to work with that Cygpath and see what kind of 
results that I get.

I am unsure how this program is going to respond.

I may have to just do the shell escape and execute the invocation of 
gentran if the program can not figure out where the location of its 
configuration files should be.



Now I see that Cygwin has a C compiler ... I will have to play with this 
a little later - I may be able to find a use for this.


What about a Secure Shell client to transfer files and to get a secure 
session going, does Cygwin have that ?  I see other people's emails 
about ssh but am not

sure if this is what I am looking for.

This Cygwin is a great package to work with.

I have been programming in some sort of shell script since 1992.





On 2/6/2014 10:09 PM, Larry Hall (Cygwin) wrote:

On 2/6/2014 8:05 PM, Mike Rushton wrote:

I see.


What would you say to this ?

I have to use an EDI translator - it runs under windows/dos and had unix
versions

I was trying this ... but the program needed to see the path of a config
file ... after the -cp switch.

/cygdrive/c/gentran61SA/lftran /cygdrive/c/gentran61sa/data/EDN -id -cp
/cygdrive/c/Gentran61SA


It gave me errors can not open file 
/cygdrive/c/Gentran61SA\ediprim.cfg.  It

was like the program could not figure out
what style of paths to use.

I changed it to :  (escape out of bash and run this code)

! c:/gentran61SA/lftran c:/gentran61sa/data/EDN -id -cp c:/Gentran61SA

and it worked perfectly.Is there a better way to do this ?


Well, as I said before, Cygwin really prefers POSIX paths.  But, as 
you've

found out, non-Cygwin programs won't understand POSIX paths.  If you need
to interact with non-Cygwin programs, you'll either want to translate the
paths you send to them back to DOS-style paths with cygpath, set up links
that both Windows and Cygwin will understand without translation, or live
somewhat dangerously and use the path-style you found above.  I'm sure
there are other flavors you could find that could also work, at least in
some cases.  The cygpath route is the one approach that fully supports
POSIX paths and DOS-style paths.




--
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: Newbie Cygdrive questions

[Larry Hall (Cygwin)]

On 2/6/2014 8:05 PM, Mike Rushton wrote:

I see.


What would you say to this ?

I have to use an EDI translator - it runs under windows/dos and had unix
versions

I was trying this ... but the program needed to see the path of a config
file ... after the -cp switch.

/cygdrive/c/gentran61SA/lftran /cygdrive/c/gentran61sa/data/EDN -id -cp
/cygdrive/c/Gentran61SA


It gave me errors can not open file /cygdrive/c/Gentran61SA\ediprim.cfg.  It
was like the program could not figure out
what style of paths to use.

I changed it to :  (escape out of bash and run this code)

! c:/gentran61SA/lftran c:/gentran61sa/data/EDN -id -cp c:/Gentran61SA

and it worked perfectly.Is there a better way to do this ?


Well, as I said before, Cygwin really prefers POSIX paths.  But, as you've
found out, non-Cygwin programs won't understand POSIX paths.  If you need
to interact with non-Cygwin programs, you'll either want to translate the
paths you send to them back to DOS-style paths with cygpath, set up links
that both Windows and Cygwin will understand without translation, or live
somewhat dangerously and use the path-style you found above.  I'm sure
there are other flavors you could find that could also work, at least in
some cases.  The cygpath route is the one approach that fully supports
POSIX paths and DOS-style paths.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: libzip-0.11.2-1

[Yaakov (Cygwin/X)]

The following packages have been updated for both arches:

* libzip-0.11.2-1
* libzip2-0.11.2-1
* libzip-devel-0.11.2-1
* libzip-doc-0.11.2-1

LibZip is a C library for reading, creating, and modifying zip archives. 
Files can be added from data buffers, files, or compressed data copied 
directly from other zip archives.  Changes made without closing the 
archive can be reverted.


This is an update to the latest upstream release.  The man3 pages have 
been moved to a separate libzip-doc package.


--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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