Re: Newline missing in csh

[Robert Klemme]

On Tue, Nov 17, 2015 at 2:28 AM, Andrey Repin  wrote:
>
> Greetings, Gluszczak, Glenn!
>
> > cat "/proc/registry/HKEY_CURRENT_USER/Control
> > Panel/International/sLanguage" works fine in bash
> > but if I switch to csh I fail to get a newline when reading the registry.
>
> > $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
> > Panel/International/sLanguage"
> > ENU^@
> > $ csh
> > $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
> > Panel/International/sLanguage"
> > ENU^@$
>
> cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
> Panel/International/sLanguage" | od -t x1

I'd rather do this to get the real contents (and not have cat -v add something):

od -t x1c "/proc/registry/HKEY_CURRENT_USER/Control
Panel/International/sLanguage"

Kind regards

robert

-- 
[guy, jim, charlie].each {|him| remember.him 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

Pin package version

[Robert Klemme]

Hi,

I could not find an answer to this: is it possible to pin a package
version with the Cygwin installer?  Switching manually to "keep" on
every update is error prone.

Kind regards

robert

-- 
[guy, jim].each {|him| remember.him 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 bash script suddenly can't find ls, grep

[Robert Klemme]

On Tue, Oct 14, 2014 at 10:54 PM, LMH  wrote:
> Thorsten Kampe wrote:
>> * LMH (Sat, 11 Oct 2014 20:30:07 -0400)
>>> Good Lord, I guess I wasn't thinking very clearly trying to use
>>> PATH as
>>> a variable for something else. I changed to,
>>>
>>> FILE_DIR=$(ls -d './'$SET'/'$FOLD'/'$FOLD'_anneal/'$PARAM_SET'/'$AN_SET)
>>> echo $FILE_DIR
>>>
>>> FILE_LIST=($(ls $FILE_DIR'/'*'out.txt' ))
>>> echo ${FILE_LIST[@]}
>>
>> That looks pretty ugly. You probably can replace all that with
>>
>> FILE_LIST=(./$SET/$FOLD/$FOLD_anneal/$PARAM_SET/$AN_SET/*out.txt)

More suggestions:

1. use lowercase variable names for variables used only inside your
script. Since variable names are case insensitive it will avoid
collisions like this and also improve readability of the code.
2. In bash you can set shell option "nullglob" to avoid a one element
array with the glob pattern if there is no matching file. In zsh it's
"setopt NULL_GLOB" I believe.
3. Since we do not know whether there are spaces in variables I would
replace the line above with (including suggestion 1):

file_list=("$set/$fold/$fold_anneal/$param_set/$an_set"/*out.txt)

Kind regards

robert


-- 
[guy, jim].each {|him| remember.him 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: Updated: bash-4.1.14-7

[Robert Klemme]

On Mon, Sep 29, 2014 at 11:22 PM, Eric Blake (cygwin) wrote:
> A new release of bash, 4.1.14-7, has been uploaded and will soon reach a
> mirror near you; leaving the previous version at 4.1.13-6.
...

Thank you Eric for the fast updates and staying on top of all the
security warnings coming in!

Kind regards

robert

--
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: gem command broken on Cygwin 64 with Ruby 2.0.0p481

[Robert Klemme]

On Fri, Sep 5, 2014 at 9:54 AM, Robert Klemme
 wrote:
> Hi folks,
>
> did someone of you experience this as well?
>
> $ uname -a
> CYGWIN_NT-6.1 arnie 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
> $ ruby --version
> ruby 2.0.0p481 (2014-05-08) [x86_64-cygwin]
> $ gem --version
> 2.4.1
> $ gem list -l
>
> *** LOCAL GEMS ***
>
> io-console (0.4.2)
> json (1.8.1)
> minitest (4.7.5)
> psych (2.0.5)
> rake (10.3.2)
> rdoc (4.1.1)
> $ gem update
> Updating installed gems
> ERROR:  While executing gem ... (ArgumentError)
> invalid byte sequence in UTF-8
> $ locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_ALL=
> $ LANG=C gem update
> Updating installed gems
> ERROR:  While executing gem ... (ArgumentError)
> invalid byte sequence in US-ASCII
>
> Apparently when reading a file the environment's encoding information
> is applied. I'm just not sure whether this is an issue with gem
> command or a Cygwin adjustment to that.
>
> Bonus points for a solution. :-)

Some feedback on the ruby-talk mailing list prompted me to experiment
a bit more. Apparently I found a solution which I post here for your
reference.

Setting the encoding to "BINARY" in the environment works:

$ LANG=C.BINARY gem update
Updating installed gems
Updating minitest
Fetching: minitest-5.4.1.gem (100%)
Successfully installed minitest-5.4.1
Parsing documentation for minitest-5.4.1
Installing ri documentation for minitest-5.4.1
Installing darkfish documentation for minitest-5.4.1
Done installing documentation for minitest after 3 seconds
Parsing documentation for minitest-5.4.1
Done installing documentation for minitest after 0 seconds
Gems updated: minitest

You can even get fancy and retain the language:

$ LANG="${LANG%%.*}.BINARY" gem update

Kind regards

robert

-- 
[guy, jim].each {|him| remember.him 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

gem command broken on Cygwin 64 with Ruby 2.0.0p481

[Robert Klemme]

Hi folks,

did someone of you experience this as well?

$ uname -a
CYGWIN_NT-6.1 arnie 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
$ ruby --version
ruby 2.0.0p481 (2014-05-08) [x86_64-cygwin]
$ gem --version
2.4.1
$ gem list -l

*** LOCAL GEMS ***

io-console (0.4.2)
json (1.8.1)
minitest (4.7.5)
psych (2.0.5)
rake (10.3.2)
rdoc (4.1.1)
$ gem update
Updating installed gems
ERROR:  While executing gem ... (ArgumentError)
invalid byte sequence in UTF-8
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=
$ LANG=C gem update
Updating installed gems
ERROR:  While executing gem ... (ArgumentError)
invalid byte sequence in US-ASCII

Apparently when reading a file the environment's encoding information
is applied. I'm just not sure whether this is an issue with gem
command or a Cygwin adjustment to that.

Bonus points for a solution. :-)

Kind regards

robert

-- 
[guy, jim].each {|him| remember.him 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: bash adds dot to $PATH

[Robert Klemme]

On Tue, Mar 25, 2014 at 3:14 AM, Linda Walsh wrote:
> Robert Klemme wrote:
>   So it could be an OS "feature" but I could not find any
>>
>> documentation about this. And it is still totally unclear to me what
>> the criterion might be as bash suffers from this but all other shells
>> do not. This is weird.
>
> 
> I don't think BASH sets the path... it adds to the existing one.

Please read the other emails - all the information is there.

> The others may set PATH.
>
> The "." in the path might be the way legacy programs can find their
> personal 'libs' in their bin dir, since when most bin's are executed,
> the CWD is set to the bindir.

Yes, probably. But why do some processes have it added and some not? I
even tried searching for information on such a feature on Microsoft
sites but did not find anything. I can imagine Windows doing this kind
of magic, but I haven't found any documentation about this -
especially what properties a process needs to have for this automatism
to kick in.

Cheers

robert


-- 
[guy, jim].each {|him| remember.him 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: bash adds dot to $PATH (was: Re: $PATH contains dot but unclear where it comes from)

[Robert Klemme]

Hi,

Matthew Blakley pointed out to me that he noticed that under Windows 7
several processes have the dot added - not only Cygwin processes. I
checked with ProcessExplorer and indeed PATH of chrome.exe ends with
";.;".  So it could be an OS "feature" but I could not find any
documentation about this. And it is still totally unclear to me what
the criterion might be as bash suffers from this but all other shells
do not. This is weird.

Kind regards

robert

-- 
[guy, jim].each {|him| remember.him 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

bash adds dot to $PATH (was: Re: $PATH contains dot but unclear where it comes from)

[Robert Klemme]

Folks,

sorry for the delay, I was sick in the meantime. Now, I try to
summarize all my finding in the hopes that bash package maintainer can
pick up from here.

When starting a terminal on my Windows 7 64 bit system $PATH contains
a dot at the end. The dot is not present in my Windows environment nor
is it added in one of the startup scripts. The dot appears even if
startup scripts are disabled. sh does _not_ exhibit the behavior.
Also, other shells do not do this.

Simple test in a Windows cmd window (first command shows there is no
dot at the end):

 Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\rklemme>path
PATH=C:\PROGRAM FILES (X86)\NVIDIA CORPORATION\PHYSX\COMMON;C:\PROGRAM
FILES (X86)\INTEL\ICLS CLIENT\;C:\PROGRAM FILES\I
NTEL\ICLS CLIENT\;C:\PROGRAM FILES (X86)\RSA SECURID TOKEN
COMMON;C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WINDOWS
 LIVE;C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT SHARED\WINDOWS
LIVE;C:\Windows\SYSTEM32;C:\Windows;C:\Windows\SYSTEM
32\WBEM;C:\Windows\SYSTEM32\WINDOWSPOWERSHELL\V1.0\;C:\PROGRAM
FILES\DELL\DELL DATA PROTECTION\ACCESS\ADVANCED\WAVE\GEMA
LTO\ACCESS CLIENT\V5\;C:\PROGRAM FILES (X86)\NTRU CRYPTOSYSTEMS\NTRU
TCG SOFTWARE STACK\BIN\;C:\PROGRAM FILES\NTRU CRYPT
OSYSTEMS\NTRU TCG SOFTWARE STACK\BIN\;C:\PROGRAM FILES (X86)\WINDOWS
LIVE\SHARED;C:\PROGRAM FILES\INTEL\INTEL(R) MANAGEM
ENT ENGINE COMPONENTS\DAL;C:\PROGRAM FILES\INTEL\INTEL(R) MANAGEMENT
ENGINE COMPONENTS\IPT;C:\PROGRAM FILES (X86)\INTEL\
INTEL(R) MANAGEMENT ENGINE COMPONENTS\DAL;C:\PROGRAM FILES
(X86)\INTEL\INTEL(R) MANAGEMENT ENGINE COMPONENTS\IPT;C:\Prog
ram Files\WIDCOMM\Bluetooth Software\;C:\Program
Files\WIDCOMM\Bluetooth Software\syswow64;C:\Program Files
(x86)\Intel\
OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL
SDK\2.0\bin\x64;C:\Program Files\Intel\Intel(R) Management En
gine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine
Components\IPT;C:\Program Files (x86)\Intel\Intel(
R) Management Engine Components\DAL;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Fi
les\Intel\WiFi\bin\;C:\Program Files\Common
Files\Intel\WirelessCommon\;C:\Users\rklemme\Applications\SysinternalsSuite

C:\Users\rklemme>c:\cygwin64\bin\bash.exe --norc --noprofile -i -l
bash-4.1$ echo "$PATH"
/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
CLIENT:/cygdr
ive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES
(X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES
/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES
(X86)/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/
cygdrive/c/Windows/SYSTEM32:/cygdrive/c/Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO
WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA
PROTECTION/ACCESS/ADVANCED/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdriv
e/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTEMS/NTRU TCG SOFTWARE
STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
 TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS
LIVE/SHARED:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MAN
AGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R)
MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES (X86)/INTEL/INTEL(R)
MANAGEMEN
T ENGINE COMPONENTS/IPT:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
 Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x86:/cygdrive/c/Program Files (x86)/Intel/Op
enCL SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R)
Management Engine Components/DAL:/cygdrive/c/Program Files
/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program
Files (x86)/Intel/Intel(R) Management Engine Compon
ents/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management
Engine Components/IPT:/cygdrive/c/Program Files/Intel
/WiFi/bin:/cygdrive/c/Program Files/Common
Files/Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/Sysinternal
sSuite:.
bash-4.1$

Note the last line ends with ":.".

The phenomenon persists, for these executions:
c:\cygwin64\bin\bash.exe --norc --noprofile -i
c:\cygwin64\bin\bash.exe --norc --noprofile
c:\cygwin64\bin\bash.exe -i -l

Actually I could not find a commandline with bash that did not lead to
the dot appended.

Invoking sh does not show the effect:

C:\Users\rklemme>c:\cygwin64\bin\sh.exe --norc --noprofile -i -l
sh-4.1$ echo "$PATH"
/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
CLIENT:/cygdr
ive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES
(X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES
/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES
(X86)/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/
cygdrive/c/Windows/SYSTEM32:/c

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

[Robert Klemme]

Thanks to all who helped so far!

On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin  wrote:

> So far, I'm not convinced that issue is Cygwin-specific. The fact that it
> doesn't manifest in Windows is actually because of it's (windows) native
> ignorance for this matter.

I sent a lengthy email with all the detailed shell outputs earlier but
it was blocked by spam filter. :-(

I'll try an executive summary, also because I don't have that much
time right now.

C:\Users\rklemme>C:\cygwin64\bin\bash.exe --norc --noprofile -li
bash-4.1$ echo "$PATH"
/cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c
ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES
/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM
ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/
Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO
WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE
D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE
MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
 TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg
drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/
c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog
ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
 Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86:
/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program
 Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files
/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel
/WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/
c/Users/rklemme/Applications/SysinternalsSuite:.
bash-4.1$

You notice the "." at the end.

C:\Users\rklemme>C:\cygwin64\bin\sh.exe --norc --noprofile -li
sh-4.1$ echo "$PATH"
/cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c
ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES
/COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM
ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/
Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO
WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE
D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE
MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
 TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg
drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/
c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG
RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog
ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
 Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86:
/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program
 Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files
/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel
/WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/
c/Users/rklemme/Applications/SysinternalsSuite

No dot at the end. Same for output of "env" without arguments invoked
from Windows prompt. The dot is also not there in the windows path.

My summary so far

1. There is nothing in the Windows PATH (neither system, nor user, nor
what's combined at  the prompt) that looks like a cause for dot (i.e.
empty path).
1. not all cygwin programs show the dot at the end of $PATH
2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe

C:\Users\rklemme>C:\cygwin64\bin\bash.exe --version
GNU bash, version 4.1.11(2)-release (x86_64-unknown-cygwin)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

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

[Robert Klemme]

On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
 wrote:
> On 2/19/2014 12:16 PM, Robert Klemme wrote:

>> The dot is already in the variable before bash even modifies it.
>
> So that means you need to look in your Windows environment to understand
> where this comes from.

I did look in windows environment as well (again, see earlier emails).

>  Don't discount any start-up batch files
> (i.e. cygwin.bat), etc., that you may be using to kick-start bash
> either.

I am using the regular mintty start that cygwin establishes.  This is
the command line
C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -

I can't see in documentation that mintty manipulates the environment
in some way.

More ideas?

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

[Robert Klemme]

On Wed, Feb 19, 2014 at 5:06 PM, Eliot Moss  wrote:
> As others have said, cygwin does not add . to the path
> itself.  It must be something in your .bash_profile,
> .bashrc, or other script sourced from them.
>
> Going through the output of your login with tracing
> enabled, as previously described, really is a straightforward
> way to track this down ...

You are right - that's why I did that already.  You would have found
out by reading earlier emails. But to no avail.  As I have written
already the very first line of the log looks like this

+ PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM
FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES/COMMON
FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES
(X86)/COMMON FILES/MICROSOFT SHARED/WINDOWS
LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPOWERSHELL/V1.0:/cygdrive/c/PROGRAM
FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCED/WAVE/GEMALTO/ACCESS
CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTEMS/NTRU TCG
SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS
LIVE/SHARED:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT
ENGINE COMPONENTS/IPT:/cygdrive/c/PROGRAM FILES (X86)/INTEL/INTEL(R)
MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES
(X86)/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/IPT:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x86:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management
Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program Files
(x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program
Files/Intel/WiFi/bin:/cygdrive/c/Program Files/Common
Files/Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.'

It's from /etc/profile and the line looks like this

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

The dot is already in the variable before bash even modifies it.

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

[Robert Klemme]

On Tue, Feb 18, 2014 at 7:32 PM, David Boyce  wrote:
>> On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
>>  wrote:
>>
>>> Can anybody make sense of that?  I can share the complete log with
>>> individuals if it helps.
>>
>> Nobody?
>
> I haven't read the whole backthread, but you do understand that a
> missing entry is translated to ".", right? E.g.
> "/usr/bin:$foo:/usr/local/bin" will include a dot if foo is undefined.
> Here's the relevant section from the man page:
>
> "A zero-length (null) directory name in the value of PATH indicates
> the current directory. A null directory name may appear as two
> adjacent colons, or as an initial or trailing colon."

I was not aware of this.  Thank you!

> I'd be surprised if this isn't at the root of the issue.

Let's see: on Windows command prompt

path >path.txt

Now let's look at the contents.  No additional leading or trailing
semi colon.  But:

$ egrep -o ';{2,}' path.txt
;;
;;

Aha!  If we look at the positions

$ egrep -o '.{15};{2,}.{15}' path.txt
OWERSHELL\V1.0\;;C:\PROGRAM FILE
ftware\syswow64;;C:\Program File

we find they do not match the position and mount of dots in the Cygwin
$PATH: it's only present at the end:

mon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.

OK, now: I removed empty path entries from Windows PATH (system and
user), rebooted and they are gone.

But, the Cygwin shell's $PATH still has the dot at the same position
(i.e. at the end).

I assume there must be some internal mechanism in Cygwin which causes
this but at the moment I am out of ideas where to look further.  Does
anybody else have an idea?  Is there maybe some automatism which adds
the dot because on Windows systems the shell always also looks in the
current directory?

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

[Robert Klemme]

On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
 wrote:

> Can anybody make sense of that?  I can share the complete log with
> individuals if it helps.

Nobody?

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

[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::con

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

$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: Clearing the buffer after quitting LESS, MAN, VIM etc.

[Robert Klemme]

On Sat, Jan 4, 2014 at 4:58 AM, Dawid Ferenczy  wrote:
> Christopher Faylor  cygwin.com> writes:
>
>> Problems like that interfere with my sleep so it's best to get them out
>> of the way before I go to bed.

> that's the difference between real programmers and other coders. Real
> programmer can't go to bed, when he has unsolved issue ;)

I do not like that comparison - even jokingly - because it sends a
wrong message. Sometimes it's really better to sleep things over. You
usually notice the next day when you find out that the "solution"
created new issues of its own. I'm not saying Christopher did in this
case but I would certainly not recommend to resolve all issues before
going to sleep. :-)

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: getting windows ntfs file info

[Robert Klemme]

On Mon, Dec 30, 2013 at 9:22 AM, Jon Retting  wrote:
> Hello,
> Typed up this one liner function for getting a files actual windows 
> details/properties information.  I needed a tertiary way to compare 
> executable/drivers, so a version number from windows seemed like a viable 
> option. Hopefully someone will find this handy, seeing as i feel so guilty 
> for not contributing more to such a wonderful project like Cygwin. And heck 
> anything's better than that most recent dosshell thread :)
>
> #get file details from windows via wmic wmi formatted call condensed
> finfo() { [[ -f "$(cygpath "$@")" ]] || { echo "bad-file";return 1;}; echo 
> "$(wmic datafile where name=\""$(echo "$(cygpath -wa "$@")"|sed 
> 's/\\//g')"\" get /value)"|sed 's/\r//g;s/^M$//;/^$/d'|awk -F"=" '{print 
> $1"=""\033[1m"$2"\033[0m"}';}

If I'm not mistaken there is at least one superfluous "echo $(" in
there.  I would also not use $@ since there could be multiple
arguments. IIRC you can also omit quotes around $(...) without risking
issues with multiple words.

finfo() {
  [ -f "$(cygpath -u "$1")" ] || { echo "bad file: $1" >&2; return 1; }

  wmic datafile where name=\"$(cygpath -w "$1" | sed 's/\\//g')\"
get /value \
  | sed 's/\r//g;s/^M$//;/^$/d' \
  | awk '-F=' '{printf "%s=\033[1m%s\033[0m\n", $1, $2}'
}

Changed a few more things
 - error to stderr
 - line breaks
 - awk print -> printf

Unfortunately I don't have a cygwin handy to test this. I'd also
probably not output color coding control characters from this function
but rather use tputs to adjust to the terminal at hand. Also sed code
can be integrated into awk or replaced by dos2unix, I guess.

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: Win 7 claims setup-x86_64.exe doesn't work any more - but it does

[Robert Klemme]

Hi Corinna,

On Thu, Nov 28, 2013 at 2:09 PM, Corinna Vinschen wrote:
> On Nov 28 10:24, Robert Klemme wrote:

>> since the last update of my cygwin 64 installer during the execution I
>> get a Windows pop up indicating that the program does not work any
>> more. Funny thing is: it does. I just click "cancel" and the
>> installation proceeds normally.  It even happens if I start the
>> program and click cancel on the first screen.  Is anybody else
>> experiencing the same?  Version is 2.831.
>
> Just tried it on a W7-64 machine and I can't reproduce this.  Maybe
> a virus scanner is interfering?

I just tested with the AV switched off and there is no difference.
Also, it has worked without issues in the past with AV.

The only change to the system was that I uninstalled Notepad++
yesterday.  Before I did that I uninstalled all the plugins and all of
a sudden my "Desktop" directory was gone.  I do not have an idea
whether this is in any way related and I don't want to blame Notepad++
unless I have evidence of any issues caused by it. So far I could not
find anything unusual.

I checked Windows Application Log and there seems to be always an
error like the one attached whenever the UI reports issues.

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Protokollname: Application
Quelle:Application Error
Datum: 28.11.2013 14:50:45
Ereignis-ID:   1000
Aufgabenkategorie:(100)
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer:  Nicht zutreffend
Computer:  arnie
Beschreibung:
Name der fehlerhaften Anwendung: setup-x86_64.exe, Version: 0.0.0.0, 
Zeitstempel: 0x5288542b
Name des fehlerhaften Moduls: nvinitx.dll_unloaded, Version: 0.0.0.0, 
Zeitstempel: 0x50ef1ca0
Ausnahmecode: 0xc005
Fehleroffset: 0x07fefd9b01e8
ID des fehlerhaften Prozesses: 0xf34
Startzeit der fehlerhaften Anwendung: 0x01ceec40d162a465
Pfad der fehlerhaften Anwendung: C:\Users\***\Downloads\setup-x86_64.exe
Pfad des fehlerhaften Moduls: nvinitx.dll
Berichtskennung: 13c4eb73-5834-11e3-bd57-d2585892fffd
Ereignis-XML:
http://schemas.microsoft.com/win/2004/08/events/event";>
  

1000
2
100
0x80

48834
Application
arnie

  
  
setup-x86_64.exe
0.0.0.0
5288542b
nvinitx.dll_unloaded
0.0.0.0
50ef1ca0
c005
07fefd9b01e8
f34
01ceec40d162a465
C:\Users\***\Downloads\setup-x86_64.exe
nvinitx.dll
13c4eb73-5834-11e3-bd57-d2585892fffd
  

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

Win 7 claims setup-x86_64.exe doesn't work any more - but it does

[Robert Klemme]

Folks,

since the last update of my cygwin 64 installer during the execution I
get a Windows pop up indicating that the program does not work any
more. Funny thing is: it does. I just click "cancel" and the
installation proceeds normally.  It even happens if I start the
program and click cancel on the first screen.  Is anybody else
experiencing the same?  Version is 2.831.

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: Telnet in latest Cygwin

[Robert Klemme]

On Sun, Oct 27, 2013 at 7:15 PM, Ralph Siegler wrote:
> Corinna Vinschen writes:
>
>   I'd suggest to use ssh instead.
>> Telnet is inherently unsecure and ssh is a wonderful replacement.

> but telnet is an invaluable tool for command line troubleshooting tcp
> network connectivity issues to SMTP, HTTP and other services by manually
> typing the protocol commands into the server.  ssh can't do that

There's also netcat (nc).

http://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fnc%2Fnc-1.107-4&grep=%2Fnc.exe

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: transfering cygwin configuration from win XP to win 7

[Robert Klemme]

On Tue, Oct 8, 2013 at 11:33 PM, Chris Olin  wrote:
> I recently did this at work by backing up the C:\cygwin directory, my
> Windows user profile directory and manually creating the directory
> path C:\cygwin\etc\setup, then copying
> C:\cygwin\etc\setup\installed.db to the new computer, running the
> installer, and changing the install method from "Default" to
> "Reinstall". Because my previous installed.db file is where the
> installer would be looking for it, it thinks that all of the packages
> I had installed are installed, so switching the install method to
> reinstall, everything is reinstalled.

That's a nice trick!  Thank you!

> I pass 'winsymlinks' to the CYGWIN environment variable and create a
> symlink from /cygwin/c/Documents and Settings/Chris Olin to
> /home/colin and update /etc/passwd to point to the new home directory.
> After recreating this symlink, it was just a matter of manually
> copying over configuration files and directories back into my home
> directory.

I follow a different approach: I have a cygwin-home under my Windows
home directory and have created a symlink pointing from /home/rklemme
to that directory.  Advantage: all backups from my Windows home also
include cygwin settings and I need to only update that single symlink
if I throw away my cygwin installation and reinstall.

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: 1.7.25: problem with the cd command in ksh

[Robert Klemme]

On Mon, Oct 7, 2013 at 7:00 PM, Christopher Faylor  wrote:
> On Mon, Oct 07, 2013 at 06:44:56PM +0200, Francis ANDRE wrote:

>>Le 07/10/2013 11:54, Andrey Repin a ?crit :

 Can I have a official statement from Cygwin about this? ie that bash is
 supporting MS-DOX path by accident and ksh won't and that is not a 
 requirement
 of Cygwin?
 Or
 Can Cygwin adds the understanding of absolute DOS path as a requirement 
 and fix
 the ksh stuff?
>>> That's a weird request, to say the least.
>>> Why not fix your script instead? It's all wrong, from the way it handle
>>> variable values, to the way it handle paths.
>>> And from my understanding of it, YOU prepending the path manually.
>>> And you dare complain?
>>Hold on Andrey, the script is not mine, it is a tool provided by Sun for 
>>making
>>easier the integration of diff from mercurial. I am just a user that want to
>>make it running. I just change all cd by kcd() by that does not work neither

Francis, you could mock java with a bash script which converts file
name arguments to proper Windows paths before invoking java.exe.

> Regardless of who created the script, we are not going to change Cygwin.
> As I said, the whole point of Cygwin is to avoid the use of
> Window/MS-DOS things like C:\foo.  Specifically patching programs like ksh
> to handle MS-DOS paths is not something that makes sense in that context.

+1

The only thing that Cygwin could reasonably do IMHO is to provide a
JDK package.  Not sure though how much effort it would be to make
graphical applications (Sing etc.) possible since Windows versions of
OpenJDK do not seem to be part of the official project.

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: 1.7.25: problem with the cd command in ksh

[Robert Klemme]

On Sun, Oct 6, 2013 at 10:49 AM, Francis ANDRE  wrote:
> Hi Robert
>
> The problem here is that the string of the target directory is computed by
> another tool -- Mercurial in this case -- and that Mercurial returns a
> absolute windows style path as
>
> Z:/DEV/OpenJDK_7u40/hotspot
>
> which seems to be relative in Unix world but which is absolute in the
> Windows world.
>
>
> Moreover, when using the bash shell, the command
>
> FrancisANDRE@idefix /cygdrive/c/Cygwin
> $ cd Z:/DEV/OpenJDK_7u40/hotspot
>
> moves the cwd without error to
> FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK_7u40/hotspot
>
>
> So why the ksh cannot do the same?

That question ksh developers or cygwin package maintainers should be
able to answer.  They might just use different syscalls which vary in
behavior on Cygwin.  You could try to find that out with strace.

Fact remains: using the Windows JDK on Cygwin is always nasty since
it's a Windows program and communication between scripts which use
Unix style paths and programs using Windows style paths soon gets
messy - especially if paths need to go both ways.

For your ksh script the easiest fix would probably be

cd $(cygpath -u "$dir")

If it needs to be cross platform you probably need to spend a bit more
effort e.g. define a shell function dependent on the platform where
the Unix versions just return the argument and the Cygwin version does
the mentioned conversion.

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: 1.7.25: problem with the cd command in ksh

[Robert Klemme]

On Sat, Oct 5, 2013 at 8:33 AM, Francis ANDRE
 wrote:
> Hi Cygwin List
>
> I have a problem with the cd command in a ksh script. In the log below,
> there is this error:
> /make/scripts/webrev.ksh[2899]: cd:
> /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspo
> t/make/windows/makefiles: No such file or directory
>
> and the snippet producing this error is
>
> # cd to the directory so the names are short
> echo "=1" CWW=$CWS  DIR=$DIR
> VARRR=$CWS/$DIR
> echo "=2" VARR=$VARRR
> cd "$VARRR"
> echo "=3" $CWS/$DIR
>
> So it seems that the cd command is prepending the target directory where to
> go(Z:/DEV/OpenJDK_7u40/hotspo
> t/make/windows/makefiles)  by the current working directory
> (/cygdrive/z/DEV/OpenJDK_7u40/hotspot/)...

I guess that's because Z:/... is a relative path on Unix (as opposed
to Windows).

> Is there a way to avoid this prefix so that the commad: cd
> Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles just prepend by the
> cygdrive prefix?

Use a proper cygwin path, e.g.

/cygdrive/z/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles

I typically do it like this: only use Unix style paths in scripts.  If
I invoke a Windows command I convert necessary paths with "cygpath -a
{path}".  I even have a script somewhere which looks at command line
arguments and converts them on the fly if it thinks it's a path (the
heuristic I use is that I test the path for existence and if that
fails I use dirname of the path and test it for existing directory).

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: About ssh

[Robert Klemme]

On Fri, Sep 20, 2013 at 11:36 PM, Javier Vasquez
 wrote:
> Hi,
>
> I'm able to perform:
>
> % ssh localhost
>
> From cygwing.  But I'm unable to perform:
>
> % ssh 
>
> I always get:
>
> --
> ssh: connect to host 192.168.2.103 port 22: Connection timed out
> --
>
> The client works well hooking to a remote machine:
>
> % ssh @
>
> Works just fine from cygwin.  But once in the remote machine, I'm
> unable to perform:
>
> % ssh @
>
> It returns the same time out error, but it lasts a longer to return it.
>
> I've even add c:\cygwing64\usr\bin\sshd as an allowed application on
> the windows firewall settings (for private net only).  As that didn't
> work, I also added new rules (for both TCP and UDP) to allow incoming
> connections on port 22.  That didn't help either.
>
> I've tried as well to set UsePrivilegeSeparation to no.  But that was
> of no help either.
>
> I'm totally clueless now.
>
> I've followed several howtos like:
>
> http://docs.oracle.com/cd/E24628_01/install.121/e22624/preinstall_req_cygwin_ssh.htm
> http://superuser.com/questions/445237/cygwin-ssh-server-is-not-accepting-connections
> http://windows.microsoft.com/is-is/windows7/open-a-port-in-windows-firewall
> http://lifehacker.com/205090/geek-to-live--set-up-a-personal-home-ssh-server
> http://www.noah.org/ssh/cygwin-sshd.html
>
> The only caveat on the 1st link is that I couldn't remove the
> "win_user", and then regenerate it as local user, cause:
>
> --
> mkpasswd -l –u 
> --
>
> Returns nothing on me.  So I can't append its output to /etc/passwd
>
> But that didn't seem to prevent being able to connect to localhost any
> ways.  So it doesn't seem to be an issue.
>
> BTW, the service is running OK according to windows "local services".
>
> Another caveat is that I didn't install cygwin for all users, just to
> the myself ().  That didn't prevent the service to run,
> neither it prevent me from ssh to localhost.
>
> Any hints on how to enable sshd to receive connections?

Did you actually start it?  You can verify with "netstat -an" that
something is listening on port 22 as a first quick check.

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: cygpath -m behaviour change

[Robert Klemme]

On Thu, Sep 19, 2013 at 3:23 PM, David Griffiths
 wrote:
>> But why are you even using cygpath to try and determine the containing
>> directory?  'dirname' does that task, in a much more portable manner,
>> and without having to worry about whether 'file/..' can be abused in
>> spite of POSIX semantics
>
> To given even more context, this is how it was used:
>
> uname=`uname`
>
> case $uname in
>   CYGWIN_*)
> CURRENT_DIR=$(cygpath -ma "${0}\..")
> ;;
>
>   *)
> CURRENT_DIR=$(cd $(dirname "$0") && pwd)
> esac
>
> CURRENT_DIR (or something derived from it) ends up getting passed to a
> Java program which requires the absolute pathname in native format.
> The dirname/pwd variant won't do that under cygwin.

I don't understand why there is a difference made with regard to the
directory extraction in Cygwin and others.  I'd probably rather have
done

CURRENT_DIR=$(dirname "$0")

if  [ ! -d "$CURRENT_DIR" ]; then
  echo "ERROR: cannot derive directory from script path: $0" >&2
  exit 1
fi

case $(uname) in
  CYGWIN_*)
CURRENT_DIR=$(cygpath -wa "$CURRENT_DIR")
;;
  *)
CURRENT_DIR=$(cd "$CURRENT_DIR" && pwd)
   ;;
esac

"$JAVA_HOME/bin/java" foo.bar.Main "$CURRENT_DIR"

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: cygpath -m behaviour change

[Robert Klemme]

On Mon, Sep 16, 2013 at 11:56 AM, David Griffiths
 wrote:
>> Yes, that's exactly right, assuming that 'boo' doesn't exist.
>
> Hi, it happens even if boo does exist. To put it in context, the
> script in question was attempting to determine the current directory:
>
> CURRENT_DIR=$(cygpath -ma "${0}"/../)

I am confused: do they need the current directory or the directory
where the script resides?  The use of -m also sounds a bit weird to
me.  I'd rather use -u or -w depending on who is supposed to use the
value (i.e. a Windows process or a Unix Cygwin process).

> (I didn't write this script but I assume they did this for performance 
> reasons.)

For the same I'd rather do

DIR_OF_SCRIPT=$(dirname "$0") && test -d "$DIR_OF_SCRIPT" || exit 1

> But anyway, as you can see ${0} always exists.

$ dash -c 'echo $0; for a; do echo "arg: $a"; done'
dash
$ dash -c 'echo $0; for a; do echo "arg: $a"; done' bla
bla
$ dash -c 'echo $0; for a; do echo "arg: $a"; done' bla foo
bla
arg: foo
$ dash -c 'echo $0; for a; do echo "arg: $a"; done' -- bla foo
--
arg: bla
arg: foo

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: svn 1.7.10-1 on x86_64 does not work

[Robert Klemme]

On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger  wrote:
> On 8/27/2013 9:04 AM, Robert Klemme wrote:
>> $ svn --version
>> /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
>> shared object file: No such file or directory
>
> Check that you have libneon27 installed. That's missing from the
> dependencies. If that doesn't work, try "cygcheck /usr/bin/svn", which
> might tell you what else is missing.

$ fgrep -i libneon /etc/setup/installed.db
$ cygcheck $(type -p svn) >/dev/null
cygcheck: track_down: could not find cygneon-27.dll

Bingo!  I installed it and now it works.

> If all that fails, follow the instructions at
> http://cygwin.com/problems.html. The cygcheck output will help us figure
> out what else is missing.

There does not seem to be anything else missing.  Thank you, David!

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

svn 1.7.10-1 on x86_64 does not work

[Robert Klemme]

Hi folks,

even obtaining the version fails with this:

$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory

I have a pretty fresh installation (only selected the older version of
svn) and am not aware of anything I missed during installation (such
as preventing installation of automatically selected dependencies).

Version:
$ uname -a
CYGWIN_NT-6.1  1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin

Unfortunately I don't have strace (see earler email) so at the moment
I cannot easily check which file is missing.

Is this a known issue? Is there some configuration change I can apply
to get it working?

Kind regards

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

1.7.7: Postinstall issue with boxes.sh

[Robert Klemme]

Hi,

there seems to be a small glitch with the grep pattern.  I have
attached the error log and a patch for file /etc/postinstall/boxes.sh.

Kind regards

robert

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


setup.log.full
Description: Binary data


boxes.sh.patch
Description: Binary data
--
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

dash vs. ash?

[Robert Klemme]

All,

I just notice that there is dash in cygwin 1.7 but there is also ash.
What would be the reason to switch from ash to dash?  From what I am
finding on the web it seems, dash was basically ash code modernized.
So it seems when on 1.7 dash would be the preferred one.  Any insight?

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: Problem getting flock with timeout to work

[Robert Klemme]

Corinna,

thanks for your feedback!

2009/3/12 Corinna Vinschen :
> On Mar 12 17:44, Robert Klemme wrote:
>> The second flock does not start the command as I expect it to be.
>>
>> I am referring to the man page of flock which says this about option -w:
>>
>> Fail  (with an exit code of 1) if the lock cannot be acquired within
>> seconds seconds.  Decimal fractional values are allowed.
>>
>> So, since the second flock obviously cannot obtain the lock in time, I
>> would have expected it to fail and not execute the command given.
>> This is at least a documentation issue as flock's behavior and
>> documentation do not match IMHO.
>
> This scenario (your first testcase) works fine with Cygwin 1.7 with my
> fix from a couple of hours ago.  I missed the fact that BSD flock lock
> semantic allows to set both lock types (LOCK_SH/LOCK_EX) regardless of
> the read/write mode in which the file has been opened, in contrast
> to POSIX lock semantic.  That's fixed now and other than that glitch,
> it worked.

Hey, that's good news!

> However...

> Cygwin won't be able to support the scenario from your second testcase
> for the time being.  The reason is that in this scenario
>
>  (
>    flock -s 200
>    ...
>  ) 200> lockfile
>
> the lock will end when the flock process exits.  The lock can only
> persist as long as the process which created the lock, or any of the
> child applications which inherited the file descriptor, still runs.  We
> can't maintain a global file descriptor table with lock information like
> the OS or what a master process could do if Cygwin would be designed so.

Thank you for the explanation!

> I know that's bad news, it certainly is for me since I thought I had
> implemented flock with full BSD semantics, but we just can't do that
> for now.

For me this is good enough - I find the variant "flock -c" better anyway. :-)

Thank you for looking into this!  Sorry for the intermediate confusion
about your "wrong" Linux.

Kind regards

robert

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

Re: Problem getting flock with timeout to work

[Robert Klemme]

2009/3/12 Corinna Vinschen :

> On second thought, maybe I don't understand what you're expecting.
> Running the testcase on a Linux box I get this:
>
> Linux calimero 2.6.[etc]
> -rw-r--r-- 1 corinna vinschen 0 Mar 12 16:48 lock
> timeout 10
> started 1
> 3644 Thu Mar 12 16:48:48 CET 2009
> started 2
> 3644 Thu Mar 12 16:48:49 CET 2009
> waiting...
> 3644 Thu Mar 12 16:48:50 CET 2009
> 3644 Thu Mar 12 16:48:51 CET 2009
> 3644 Thu Mar 12 16:48:52 CET 2009
> 3662 Thu Mar 12 16:48:53 CET 2009
> 3662 Thu Mar 12 16:48:54 CET 2009
> 3662 Thu Mar 12 16:48:55 CET 2009
> 3662 Thu Mar 12 16:48:56 CET 2009
> 3662 Thu Mar 12 16:48:57 CET 2009
> done
>
> 9 seconds
>
> I don't see that this is different in the sense of "more correct" than
> on Cygwin.

Sorry, I overlooked the timeout setting: of course, this is correct.
But if you start it with command line argument 1 (i.e. timeout 1
second) the second flock should bail out with an error since it cannot
obtain the lock in time.

Kind regards

robert

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

Re: Problem getting flock with timeout to work

[Robert Klemme]

Hi again,

2009/3/12 Corinna Vinschen :
> On Mar 12 15:40, Robert Klemme wrote:

>> Any ideas?  Am I doing something wrong?
>
> On second thought, maybe I don't understand what you're expecting.
> Running the testcase on a Linux box I get this:
>
> Linux calimero 2.6.[etc]
> -rw-r--r-- 1 corinna vinschen 0 Mar 12 16:48 lock
> timeout 10
> started 1
> 3644 Thu Mar 12 16:48:48 CET 2009
> started 2
> 3644 Thu Mar 12 16:48:49 CET 2009
> waiting...
> 3644 Thu Mar 12 16:48:50 CET 2009
> 3644 Thu Mar 12 16:48:51 CET 2009
> 3644 Thu Mar 12 16:48:52 CET 2009
> 3662 Thu Mar 12 16:48:53 CET 2009
> 3662 Thu Mar 12 16:48:54 CET 2009
> 3662 Thu Mar 12 16:48:55 CET 2009
> 3662 Thu Mar 12 16:48:56 CET 2009
> 3662 Thu Mar 12 16:48:57 CET 2009
> done
>
> 9 seconds
>
> I don't see that this is different in the sense of "more correct" than
> on Cygwin.

Well, maybe your Linux is wrong, too. This is what *my* Linux (CentOS
5.2, all packages current) does:

[r...@padsw7ora01 tmp]# ~/fl-test-2.sh 1
Linux padsw7 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008
i686 i686 i386 GNU/Linux
-rw-r--r-- 1 root root 0 Mar 12 17:39 lock
timeout 1
started 1 with PID 17106
17107 1 Thu Mar 12 17:39:29 CET 2009
started 2 with PID 17114
17107 2 Thu Mar 12 17:39:30 CET 2009
waiting...
17107 3 Thu Mar 12 17:39:31 CET 2009
17107 4 Thu Mar 12 17:39:32 CET 2009
17107 5 Thu Mar 12 17:39:33 CET 2009
done
[r...@padsw7ora01 tmp]#

The second flock does not start the command as I expect it to be.

I am referring to the man page of flock which says this about option -w:

Fail  (with an exit code of 1) if the lock cannot be acquired within
seconds seconds.  Decimal fractional values are allowed.

So, since the second flock obviously cannot obtain the lock in time, I
would have expected it to fail and not execute the command given.
This is at least a documentation issue as flock's behavior and
documentation do not match IMHO.

I'll attach another script which implements the other suggested scheme
with even more disturbing output:

17:31:09 tmp$ ./fl-test.sh
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
-rw-r--r-- 1 RKlemme Domain Users 0 Mar 12 17:31 lock
timeout 10
started 1 with PID 3160
1 1 Thu Mar 12 17:31:31 WEST 2009
started 2 with PID 1848
2 1 Thu Mar 12 17:31:32 WEST 2009
1 2 Thu Mar 12 17:31:32 WEST 2009
waiting...
2 2 Thu Mar 12 17:31:33 WEST 2009
1 3 Thu Mar 12 17:31:33 WEST 2009
2 3 Thu Mar 12 17:31:34 WEST 2009
1 4 Thu Mar 12 17:31:34 WEST 2009
2 4 Thu Mar 12 17:31:35 WEST 2009
1 5 Thu Mar 12 17:31:35 WEST 2009
2 5 Thu Mar 12 17:31:36 WEST 2009
done
17:31:37 tmp$

Zero locking at all!

On my Linux this script behaves as expected:

[r...@padsw7ora01 tmp]# ~/fl-test.sh
Linux padsw7 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008
i686 i686 i386 GNU/Linux
-rw-r--r-- 1 root root 0 Mar 12 17:38 lock
timeout 10
started 1 with PID 16989
1 1 Thu Mar 12 17:38:12 CET 2009
started 2 with PID 16994
1 2 Thu Mar 12 17:38:13 CET 2009
waiting...
1 3 Thu Mar 12 17:38:14 CET 2009
1 4 Thu Mar 12 17:38:15 CET 2009
1 5 Thu Mar 12 17:38:16 CET 2009
2 1 Thu Mar 12 17:38:17 CET 2009
2 2 Thu Mar 12 17:38:18 CET 2009
2 3 Thu Mar 12 17:38:19 CET 2009
2 4 Thu Mar 12 17:38:20 CET 2009
2 5 Thu Mar 12 17:38:21 CET 2009
done

Now with timeout too short:

[r...@padsw7ora01 tmp]# ~/fl-test.sh 1
Linux padsw7 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008
i686 i686 i386 GNU/Linux
-rw-r--r-- 1 root root 0 Mar 12 17:38 lock
timeout 1
started 1 with PID 17023
1 1 Thu Mar 12 17:38:25 CET 2009
started 2 with PID 17028
1 2 Thu Mar 12 17:38:26 CET 2009
flock error from 2
waiting...
2 1 Thu Mar 12 17:38:27 CET 2009
1 3 Thu Mar 12 17:38:27 CET 2009
2 2 Thu Mar 12 17:38:28 CET 2009
1 4 Thu Mar 12 17:38:28 CET 2009
2 3 Thu Mar 12 17:38:29 CET 2009
1 5 Thu Mar 12 17:38:29 CET 2009
2 4 Thu Mar 12 17:38:30 CET 2009
2 5 Thu Mar 12 17:38:31 CET 2009
done
[r...@padsw7ora01 tmp]#


Kind regards

robert


fl-test.sh
Description: Bourne shell script
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Problem getting flock with timeout to work

[Robert Klemme]

Hi,

I searched the archives but could not find any related issue.  My
problem is this: I use flock with a timeout but apparently the timeout
does not work, i.e. flock waits longer than specified.  Script is
attached.  Output is here:

This is ok, timeout is longer than needed:

15:34:27 tmp$ ./fl-test-2.sh
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
-rw-r--r-- 1 RKlemme Domain Users 0 Mar 12 15:34 lock
timeout 10
started 1
3672 Thu Mar 12 15:34:32 WEST 2009
started 2
3672 Thu Mar 12 15:34:33 WEST 2009
waiting...
3672 Thu Mar 12 15:34:34 WEST 2009
3672 Thu Mar 12 15:34:35 WEST 2009
3672 Thu Mar 12 15:34:36 WEST 2009
2884 Thu Mar 12 15:34:37 WEST 2009
2884 Thu Mar 12 15:34:39 WEST 2009
2884 Thu Mar 12 15:34:40 WEST 2009
2884 Thu Mar 12 15:34:41 WEST 2009
2884 Thu Mar 12 15:34:42 WEST 2009
done

This looks wrong, timeout is much shorter than what the process takes
and should abort:

15:34:43 tmp$ ./fl-test-2.sh 2
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
-rw-r--r-- 1 RKlemme Domain Users 0 Mar 12 15:34 lock
timeout 2
started 1
2444 Thu Mar 12 15:34:45 WEST 2009
started 2
2444 Thu Mar 12 15:34:47 WEST 2009
waiting...
2444 Thu Mar 12 15:34:48 WEST 2009
2444 Thu Mar 12 15:34:49 WEST 2009
2444 Thu Mar 12 15:34:50 WEST 2009
4064 Thu Mar 12 15:34:51 WEST 2009
4064 Thu Mar 12 15:34:52 WEST 2009
4064 Thu Mar 12 15:34:53 WEST 2009
4064 Thu Mar 12 15:34:55 WEST 2009
4064 Thu Mar 12 15:34:56 WEST 2009
done
15:34:57 tmp$

Any ideas?  Am I doing something wrong?

Kind regards

robert


fl-test-2.sh
Description: Bourne shell script
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Ruby and OpenSSL: no such file to load -- openssl (RuntimeError)

[Robert Klemme]

2008/10/18 Redd Vinylene <[EMAIL PROTECTED]>:
> I'm getting this error on Cygwin when trying to run this tiny little Rails 
> app:
>
> ./script/../config/../vendor/rails/railties/lib/initializer.rb:253:in
> `require_frameworks': no such file to load -- openssl (RuntimeError)
>
> I have both the openssl and openssl-devel packages installed. There's
> even an openssl.so in /lib/ruby/1.8/i386-cygwin. I don't know about
> libopenssl-ruby though, it only seems to exist for Debian and Ubuntu.
>
> Anybody got a clue? Have a nice weekend y'all.

Maybe you got your environment messed up.  Did you try adding
/lib/ruby/1.8/i386-cygwin to RUBYLIB?

robert

-- 
remember.guy do |as, often| as.you_can - without end

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

Re: ruby-1.8.6-p114-1: IRB cannot use readline any more

[Robert Klemme]

2008/5/21 Corinna Vinschen <[EMAIL PROTECTED]>:
> On May 21 09:51, Robert Klemme wrote:
>> after upgrading to this new version of Ruby readline does not seem to
>> work in IRB any more.  I tried using parameter --readline as well as
>> various combinations of packages readline, libreadline5 and
>> libreadline6 but to no avail.  Switching back to the previous version
>> (ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin]) solves the issue.
>
> My fault.  I moved my 1.5 build environment to another machine and
> missed to install the readline devel package.  The result is that
> readline support is entirely missing in ruby.

Ah, I suspected some build (flag) issue. Thanks for confirming!

> I'll prepare a new package today.
>
> Thanks for the report,

Thank *you* for the quick reaction!

Kind regards

robert

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

ruby-1.8.6-p114-1: IRB cannot use readline any more

[Robert Klemme]

Hi,

after upgrading to this new version of Ruby readline does not seem to
work in IRB any more.  I tried using parameter --readline as well as
various combinations of packages readline, libreadline5 and
libreadline6 but to no avail.  Switching back to the previous version
(ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin]) solves the issue.
Did anybody else experience this?  Is there another solution for this?

Kind regards

robert


-- Forwarded message --
From: Corinna Vinschen <[EMAIL PROTECTED]>
Date: 2008/5/8
Subject: Updated: ruby-1.8.6-p114-1
To: cygann <[EMAIL PROTECTED]>

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