RE: Join command fails to output fields on input file with DOS line endings.

[Andy Hall]

> On 7/22/2019 12:59 PM, Eliot Moss wrote:
> On 7/22/2019 12:50 PM, Andy Hall wrote:
> > This behavior of join surprised me:
> >
> > $ join -1 3 <(echo a b col3  c d | unix2dos) <(echo col3 f2 f3 f4 f5)
> >   f2 f3 f4 f5
> >
> > Join parses the input line well enough to execute the join, but the 
> > presence of the DOS line endings suppresses the
> > output of fields from the first input.
> >
> > Compare with
> >
> > $ join -1 3 <(echo a b col3  c d) <(echo col3 f2 f3 f4 f5)
> > col3 a b c d f2 f3 f4 f5
> >
> > which is correct.
> >
> > Here is a weirder example where the join field is missing and the output is 
> > reversed!
> >
> > NOK
> > $ join <(echo col F1 | unix2dos) <(echo col F2)
> >   F2 F1
> >
> > OK
> > $ join <(echo col F1) <(echo col F2)
> > col F1 F2
> 
> The lesson is: You're better off not using DOS line endings with Cygwin.
> It tends to do things the POSIX way, where the line ending is LF, not
> CR LF.  Some things *may* work, but it's somewhat hit or miss ...  EM
> 
Right.  But in this case,  the last field of the first file contains a \r which
completely mangles the output.  

But join appears to "work" if the lines of the second file are in DOS format.

E.g.
$ join <(echo col F1) <(echo col F2 | unix2dos)
col F1 F2


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

Join command fails to output fields on input file with DOS line endings.

[Andy Hall]

This behavior of join surprised me: 

$ join -1 3 <(echo a b col3  c d | unix2dos) <(echo col3 f2 f3 f4 f5)
 f2 f3 f4 f5

Join parses the input line well enough to execute the join, but the presence of 
the DOS line endings suppresses the
output of fields from the first input.

Compare with

$ join -1 3 <(echo a b col3  c d) <(echo col3 f2 f3 f4 f5)
col3 a b c d f2 f3 f4 f5

which is correct.  

Here is a weirder example where the join field is missing and the output is 
reversed!

NOK
$ join <(echo col F1 | unix2dos) <(echo col F2)
 F2 F1

OK
$ join <(echo col F1) <(echo col F2)
col F1 F2






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

RE: [ANNOUNCEMENT] Updated: mintty 2.9.4

[Andy Hall]

> -Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf Of Thomas 
> Wolff
> Sent: Tuesday, November 13, 2018 12:08 AM
> To: cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] Updated: mintty 2.9.4
> 
> Am 12.11.2018 um 22:50 schrieb Andrey Repin:
> > Greetings, Thomas Wolff!
> >
> >> I have uploaded mintty 2.9.4 with the following changes:
> >> Terminal features
> >> * Copy as HTML (#811).
> > I should agree with Achim. This feature is utterly broken.
> > Copied fragments are inserted as HTML TABLES(of all the things!) with no 
> > formatting whatsoever.
> OK, it shall be made configurable. But please describe in which ways
> workflows are broken and how / in which application HTML tables (HTML
> source?) would appear.
> Of course plain text clipboard format is still supplied (multiple
> formats can be copied to the Windows clipboard at the same time,
> otherwise I wouldn't have enabled this by default), and the assumption
> was that an application pasting plain text from the Windows clipboard
> would still retrieve that.
> 
For what it's worth,  I tried some simple examples. 

Copy and paste into notepad, notepad++ or another mintty window resulted in 
plain text being copied.  

Paste into MS Word 2016 gives you three options:  "Keep Source Formatting",  
"Merge Formatting"  and "Keep Text Only".   If I selected "Keep Source 
Formatting", the result is a single cell table containing the text copied.  The 
other options resulted in plain text being copied.  The former is actually 
useful if you happen to be writing documentation about how to do something at 
the command line level, but there are flaws.   In my case, the inserted table 
had a black background and white test and it was not easy to change this.   


--
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 seg faulting?

[Andy Hall]

Here is some more information

The sequence:

Andy@Andy-Work ~
$ export OFFICE_BIN="C:\Program Files (x86)\Microsoft Office\root\Office16"
$ strace "$OFFICE_BIN"/Wordconv.exe -oice -nme "Post-Install.doc" 
"Post-Install.docx" >strace.out
Segmentation fault 
$ echo $?
139

Produces the attached strace.  Notice the last lines

--- Process 5628, exception c005 at 6fdca6fd
--- Process 5628 exited with status 0xc005  // This is windows code for 
access violation

So teh seg fault comes from the Wordconv.exe process when it is exiting,  but 
why?  This doesn't happen if I do this in
CMD.

$ cmd
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\cygwin64\home\Andy\ConvWord>"%OFFICE_BIN%\Wordconv.exe" -oice -nme 
"Post-Install.doc" "Post-Install.docx"
"%OFFICE_BIN%\Wordconv.exe" -oice -nme "Post-Install.doc" "Post-Install.docx"

Somebody with deeper knowledge of cygwin internals will have to track this down.

Andy


Here is a strange one.   I have two scripts, conv.sh and conv.bat that do the 
same thing: scan the current directory for
.doc files and convert them to .docx files.  Here are the two scripts.

$ cat conv.sh
#!/bin/bash

OFFICE_BIN="C:\Program Files (x86)\Microsoft Office\root\Office16"

for doc in *.doc; do
echo "converting: $doc"
"$OFFICE_BIN"/Wordconv.exe -oice -nme "$doc" "${doc}x"
done

$cat conv.bat
@echo off
set OFFICE_BIN=C:\Program Files (x86)\Microsoft Office\root\Office16

for %%a in ("*.doc") do (
rem This is necessary because *.doc can match *.docx! Need to check the 
actual extension.
if "%%~xa" == ".doc" (
echo "converting: %%a"
"%OFFICE_BIN%\Wordconv.exe" -oice -nme "%%a" "%%ax"a
)
)

When conv.sh is run on a directory containing three .doc files, the conversions 
work but I get three seg faults at three
different locations.  E.g.

$ conv.sh
converting: Post-Install.doc
./conv.sh: line 5:  6060 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"
converting: Post-InstallB.doc
./conv.sh: line 5: 13264 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"
converting: Post-InstallTest.doc
./conv.sh: line 5: 13260 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"

When conv.bat is run in the same directory, the conversions work and I don't 
get any seg faults (or they are not being
reported!)  E.g. 
$ conv.bat
"converting: Post-Install.doc"
"converting: Post-InstallB.doc"
"converting: Post-InstallTest.doc"

Now Wordconf.exe is a 32-bit executable running on a Windows 10 Pro 64-bit 
installation.

My cygcheck.out is attached.  I guess I can get an strace if need.


Andy



cygcheck.out
Description: Binary data


strace.out
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

RE: Bash seg faulting?

[Andy Hall]

On 1 June Doug Henderson wrote:
> 
> On 1 June 2017 at 18:01, Andy Hall wrote:
> >
> > Here is a strange one.   I have two scripts, conv.sh and conv.bat that do 
> > the same thing: scan the current directory for
> > .doc files and convert them to .docx files.  Here are the two scripts.
> >
> > $ cat conv.sh
> > #!/bin/bash
> >
> 
> Try running "cat -e conv.sh" to see if you have dos line endings, e.g.
> CR LF, instead of unix line endings, e.g. LF only.
> 
> If you do, run "dos2unix conv.sh" or "d2u conv.sh" to fix the line
> ending problem. Check that your editor can create files with unix line
> endings, and preserves unix line endings.
> 
> HTH
> Doug
> 
First of all, the Wordconv.exe converts a .doc file to a .docx file, ostensible 
writing no output.   However, I find if I change the script to read:

#!/bin/bash

OFFICE_BIN="C:\Program Files (x86)\Microsoft Office\root\Office16"

for doc in *.doc; do
echo "converting: $doc"
"$OFFICE_BIN"/Wordconv.exe -oice -nme "$doc" "${doc}x" | od
done

and run, I don’t get the seg faults, but od is showing no output written as you 
might expect (as in od 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 seg faulting?

[Andy Hall]

Here is a strange one.   I have two scripts, conv.sh and conv.bat that do the 
same thing: scan the current directory for
.doc files and convert them to .docx files.  Here are the two scripts.

$ cat conv.sh
#!/bin/bash

OFFICE_BIN="C:\Program Files (x86)\Microsoft Office\root\Office16"

for doc in *.doc; do
echo "converting: $doc"
"$OFFICE_BIN"/Wordconv.exe -oice -nme "$doc" "${doc}x"
done

$cat conv.bat
@echo off
set OFFICE_BIN=C:\Program Files (x86)\Microsoft Office\root\Office16

for %%a in ("*.doc") do (
rem This is necessary because *.doc can match *.docx! Need to check the 
actual extension.
if "%%~xa" == ".doc" (
echo "converting: %%a"
"%OFFICE_BIN%\Wordconv.exe" -oice -nme "%%a" "%%ax"a
)
)

When conv.sh is run on a directory containing three .doc files, the conversions 
work but I get three seg faults at three
different locations.  E.g.

$ conv.sh
converting: Post-Install.doc
./conv.sh: line 5:  6060 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"
converting: Post-InstallB.doc
./conv.sh: line 5: 13264 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"
converting: Post-InstallTest.doc
./conv.sh: line 5: 13260 Segmentation fault  "$OFFICE_BIN"/Wordconv.exe 
-oice -nme "$doc" "${doc}x"

When conv.bat is run in the same directory, the conversions work and I don't 
get any seg faults (or they are not being
reported!)  E.g. 
$ conv.bat
"converting: Post-Install.doc"
"converting: Post-InstallB.doc"
"converting: Post-InstallTest.doc"

Now Wordconf.exe is a 32-bit executable running on a Windows 10 Pro 64-bit 
installation.

My cygcheck.out is attached.  I guess I can get an strace if need.


Andy



cygcheck.out
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

RE: unzip, find broken by auto handling of .exe file extension

[Andy Hall]

> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
> Stephen Anderson
> Sent: Monday, September 12, 2016 4:31 PM
> To: cygwin@cygwin.com
> Subject: Re: unzip, find broken by auto handling of .exe file extension
> 
> 
> > On Sep 12, 2016, at 4:53 PM, Marco Atzeri  wrote:
> >
> > On 12/09/2016 21:12, Stephen Anderson wrote:
> >> Thanks Ken, good observation.
> >>
> >>   -Original Message-
> >>> From: Nellis, Kenneth
> >>> From: Stephen Anderson >
> >>> > See also:
> >>> >
> >>> > http://stackoverflow.com/questions/32467871/unzip-gives-checkdir-error-
> >>> > directory-exists-but-is-not-a-directory#32468314
> >>> >
> >>> > The fact that 7z handles this and unzip does not indicates that the
> >>> > problem is fixable..
> >>
> >>> FWIW, it seems that the same issue is present with tar:
> >>> 
> >>
> >> This means that you can't reliably extract from a tar or zip archive in
> >> cygwin.
> >> The windoze equivalents do not have this problem.
> >> It looks to me like the approach of equating filenames 'foo' and
> >> 'foo.exe' is dangerous at the stat(2) level - apparently windoze
> >> accomplishes the same trick in a much less destructive way.
> >>
> >> sja
> >>
> >
> > This characteristics is needed as windows for historical reason
> > requested  ".exe" extension for all executable files, while
> > Unix have not such restriction.
> >
> > So "cat.exe" is recognized by cygwin also as "cat".
> > Without this feature all scripts taken by traditional Unix's will
> > be broken and cygwin will be unusable.
> >
> > Try this experiment on Linux:
> >
> > touch foo
> > mkdir foo
> >
> > does it work ?
> 
> This is not relevant, there is no foo, there is only foo.exe.
> 
> In the case of windows _command_ processing, certain extensions are searched 
> for automatically without creating an
> equivalency in file names. This means that for the same directory and 
> filename hierarchy, windows and linux archive
> processing work, cygwin uniquely fails. Not a desirable outcome.
> 
> IMHO the only time cygwin should be looking for .exe (or .cmd, .bat etc if 
> desired), is when no match is found on
loading a
> _command_, possibly only from a shell.
> 
> sja 

Yes, one should expect that the inverse of any file archiving operation would 
return the original directory structure,
possibly with some alterations to permissions and ownership.I have been 
burned several times by the .exe handling in
tar when moving archives back and forth between Linux and Windows.   I would 
agree that this behavior violates the
"principle of least astonishment"  especially for long-time Unix users.

In the past, I have advocated the same solution you proposed.   But how does 
this make commands like "which" and
"whereis"  which take program names as arguments work properly?

adh  


> --
> 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: Simple .cmd file works under Cygwin but not Window's cmd interpreter.

[Andy Hall]

Andrey -

Thank you for the response.   I had already tried most of your suggestions in 
one form or another.So below is my
latest try (reduced to the essentials) to find what works and what doesn’t.  
The essential idea was to take the PATH out
of consideration by reducing it to a minimum in both the CMD and Cygwin 
environments.   This did not change the result
at all.  This is expected, because Crystal Reports does not itself depend on 
anything in the PATH.  The user defined
functions are dynamically loaded and installed when run under Cygwin but not 
when run in a Windows command window.

There are differences in the environments (attached) but I don’t see anything 
Cygwin has added or changed that would
make a difference.  After all, Crystal Reports knows nothing about Cygwin 
specific environment variables so anything
added by Cygwin should not affect the behavior.   There are a few things that 
are different (oddly) , but manually
setting these in either environments is a bit tedious.

Now there are some details about the way user defined functions are installed 
that are peculiar.  First of all,  the
CLASSPATH settings are obviously read from the registry by Crystal Reports, not 
from the environment.   This is one of
the nasty manual configuration settings I mentioned below.It also reads the 
path to a JVM .dll from a registry
setting and this also has to be set  to get user defined functions working.   
When running  the script below in a
Windows CMD window,  Crystal reports loads and runs, but it fails to load the 
user defined functions.  That works from a
bash prompt.   From experimentation, I know setting this registry value is 
necessary as running in the Cygwin
environment fails if this is not set.  It is possible, that there is something 
strange about .dll loading which causes
it to work in Cygwin but not on a CMD Window, but that seems unlikely.

@Echo off

set CR_HOME_DIR=C:\Program Files (x86)\Business Objects\Crystal Reports 11.5

:: Display CLASSPATH
echo CLASSPATH
echo %CLASSPATH%
echo.

:: Set and display JAVA_HOME
set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_45
echo JAVA_HOME
echo %JAVA_HOME%
echo.

::  Set minimal path and add 32-bit JDK to PATH and display
set PATH=.;%JAVA_HOME%\bin
echo PATH
echo %PATH%
echo.

:: Display environment.  
set
java.exe -version
"%CR_HOME_DIR%"\crw32.exe

I am still very puzzled,

Andy Hall


> Greetings, Andy Hall!
> 
> > This is a puzzle that I have not been able to sort out despite trying all
> > sorts of variations. Basically, I maintain a bunch of Crystal Reports based
> > on Crystal reports XI R2. Sorry, I have no choice there.
> > I have this installed and running on a Widows 10 machine. How I did that is
> > another story.
> > Recently I was asked what it would take to internationalize these reports.
> > Fortunately, CR has a mechanism that allows you to define your own functions
> > that can be used in reports which  allow you to access properties files
> > containing the localized entities just as you would for a
> > normal Java app.   All well and good.
> 
> > So I set about trying to get this to work. The plugin to CR XI R2, is not
> > well integrated with the base system and a bit of not so nice manual
> > configuration is necessary.
> > You have to follow this to the letter, but that is not sufficient.
> > Out of the box I could not get it to work. So to debug what was going on I
> > wrote a simple bash script to try to get it to work.
> > Lo and behold this simple script works:
> 
> > #!/bin/bash
> 
> > echo " "
> > echo "CLASSPATH = $CLASSPATH"
> > echo " "
> > #JAVA_HOME=C":\Program Files (x86)\Java\jdk1.6.0_45"
> > echo "JAVA_HOME = $JAVA_HOME"
> > echo " "
> > echo "PATH = $PATH"
> 
> > cd "/cygdrive/c/Program Files (x86)/Business Objects/Crystal Reports 11.5"
> > java -version
> > crw32.exe
> 
> > Notice that this seem to do nothing but display some key variables and the
> > run CR in its installation directory, just as the normal shortcut does.
> > It launches CR which finds the plugin and loads it.
> 
> > Now I have a need to do the same outside of the Cygwin environment, so I
> > wrote a simple equivalent .cmd file:
> 
> > @Echo off
> 
> > :: Display CLASSPATH
> > set CLASSPATH
> 
> echo %CLASSPATH%
> 
> > :: Set and display JAVA_HOME
> > ::set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_45
> > set JAVA_HOME
> 
> echo %JAVA_HOME%
> 
> > :: Add 32-bit JDK to PATH and display
> > ::set PATH=%JAVA_HOME%\bin;%PATH%
> > set PATH
> 
> Just start Java from %ProgramData%\Oracle\Java\javapath\java.exe
> In truth, it IS ALREAD

Simple .cmd file works under Cygwin but not Window's cmd interpreter.

[Andy Hall]

This is a puzzle that I have not been able to sort out despite trying all sorts 
of variations.  Basically,  I maintain a
bunch of Crystal Reports  based on Crystal reports XI R2.  Sorry,  I have no 
choice there.    I have this installed and
running on a Widows 10 machine.   How I did that is another story.   Recently I 
was asked what it would take to
internationalize these reports.  Fortunately, CR has a mechanism that allows 
you to define your own functions that can
be used in reports which  allow you to access properties files containing the 
localized entities just as you would for a
normal Java app.   All well and good. 

So I set about trying to get this to work.   The plugin to CR XI R2, is not 
well integrated with the base system and a
bit of not so nice manual configuration is necessary.  You have to follow this 
to the letter, but that is not
sufficient.   Out of the box I could not get it to work.    So to debug what 
was going on I wrote a simple bash script
to try to get it to work.   Lo and behold this simple script works:

#!/bin/bash

echo " "
echo "CLASSPATH = $CLASSPATH"
echo " "
#JAVA_HOME=C":\Program Files (x86)\Java\jdk1.6.0_45"
echo "JAVA_HOME = $JAVA_HOME"
echo " "
echo "PATH = $PATH"

cd "/cygdrive/c/Program Files (x86)/Business Objects/Crystal Reports 11.5"
java -version
crw32.exe

Notice that this seem to do nothing but display some key variables and the run 
CR in its installation  directory, just
as the normal shortcut does.  It launches CR which finds the plugin and loads 
it.

Now I have a need to do the same outside of the Cygwin environment, so I wrote 
a simple equivalent .cmd file:

@Echo off

:: Display CLASSPATH
set CLASSPATH

:: Set and display JAVA_HOME
::set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_45
set JAVA_HOME

:: Add 32-bit JDK to PATH and display
::set PATH=%JAVA_HOME%\bin;%PATH%
set PATH

pushd C:\Program Files (x86)\Business Objects\Crystal Reports 11.5
java.exe -version
crw32.exe
popd

If I run this from a bash command prompt it works as well.  It also works if I 
launch cmd from bash and then run the cmd
file.  That makes sense.

But here is the puzzle,   If I simply click on the runCR.cmd file, say from  
the file explorer,  CR launches but does
not find the plugin.  The same happens if I launch a Windows cmd window and run 
the cmd file outside of Cygwin. 

So the question is: “What could possibly be the difference between the Cygwin 
environment and the Windows cmd
environment that makes this work in one and not the other?”   I have examined 
the PATH used in the Cygwin environment
and set the PATH in the Windows environment to be identical.  No change.   I 
thought it might have to do with whether or
not a 32-bit or 64-bit JVM is configured in the path, but that does not seem to 
make a difference.   It fails if the JVM
in the path is 32-bit or 64-bit probably because CR really gets its JVM from a 
registry setting.

I am at a loss,   Does anybody have an idea?   

BTW, I would have expected the reverse to be the case:  works in Windows but 
not Cygwin.  

Andy Hall



--
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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

[Andy Hall]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
> Brian Inglis
> Sent: Wednesday, January 13, 2016 12:14 AM
> To: cygwin@cygwin.com
> Subject: Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A 
> records
> 
> Corinna Vinschen  cygwin.com> writes:
> > On Jan  7 15:39, Brian Inglis wrote:
> >> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A 
> >> records.
> >> Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows.
> >> Can anyone reproduce failure with problem host name below?
> >
> > Yes, I can reproduce it, and it's a total surprise.
> 
> > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
> > at all.
> 
> Especially when after just one getaddrinfo call, the DNS cache is populated
> with:
> leapsecond.utcd.org
> 
> Record Name . . . . . : leapsecond.utcd.org
> Record Type . . . . . : 1
> Time To Live  . . . . : 600
> Data Length . . . . . : 4
> Section . . . . . . . : Answer
> A (Host) Record . . . : 244.34.36.97
> 
> so the DNS server is being contacted and responding normally, but it would
> appear Windows GAI is failing to use that info.
> Has this been reproduced on W10 so we can report this upstream?
> Is there any support without an account for upstream W7 reports?
> 
> 
DNS just translates URLs to IP addresses.  It is no surprise that works.   
However, addresses in the range 240.0.0.0 -
255.255.255.255 are reserved.   Windows is probably blocking that as a "favor".

Net Range   240.0.0.0 - 255.255.255.255
CIDR240.0.0.0/4
NameSPECIAL-IPV4-FUTURE-USE-IANA-RESERVED
Handle  NET-240-0-0-0-0
Parent  
Net TypeIANA Special Use
Origin AS   
OrganizationInternet Assigned Numbers Authority (IANA)
Registration Date   
Last Updated2013-08-30
CommentsAddresses starting with 240 or a higher number have not been 
allocated and should not be used, apart
from 255.255.255.255, which is used for "limited broadcast" on a local network.

This block was reserved by the IETF, the organization that develops Internet 
protocols, in the Standard document and in
RFC 1112. The documents can be found at:
http://datatracker.ietf.org/doc/rfc1112
RESTful Linkhttp://whois.arin.net/rest/net/NET-240-0-0-0-0
See AlsoRelated organization's POC records.
See AlsoRelated delegations.


--
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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

[Andy Hall]

> 
> On Jan  8 13:44, cyg Simple wrote:
> > On 1/8/2016 6:14 AM, Corinna Vinschen wrote:
> > > $ ./gai leapsecond.utcd.org
> > > ret = 11004
> > >
> > > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
> > > at all.
> >
> > utcd.org doesn't resolve for me.  So getaddrinfo has no info to get.
> 
> Why then does it work on Linux?
> 

nslookup works for me:

Win7 64-bit

$ nslookup leapsecond.utcd.org
Non-authoritative answer:
Server:  UnKnown
Address:  192.168.1.1

Name:leapsecond.utcd.org
Address:  244.34.36.97

Win10 64-bit

C:\Users\Andy>nslookup leapsecond.utcd.org
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:leapsecond.utcd.org
Address:  244.34.36.97

However,  tracert and ping  yield this on both W7 & W10:

$ tracert leapsecond.utcd.org
Unable to resolve target system name leapsecond.utcd.org.

$ tracert 244.34.36.97

Tracing route to 244.34.36.97 over a maximum of 30 hops

  1  Transmit error: code 1231.

Trace complete.

$ ping 244.34.36.97

Pinging 244.34.36.97 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 244.34.36.97:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Weird!





--
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: Unable to run excel via cron

[Andy Hall]

 On 06/23/2015 09:39 AM, Kertz, Denis (D)** CTR ** wrote:
  I changed the cron setup to use cygserver as Corinna suggested.  I used
  cron-config and cygserver-config to setup the cron and cygserver services
  and passwd -R to establish my password.  Normal cron jobs run under this
  setup but Excel still hangs as it did before.  I also tried this on the
  Win7 PC that I thought worked at one time but it behaved the same with
  Excel hanging.
 
  So it looks like Corinna's first case is the situation - there is no
  solution.  There apparently is something unique about Excel that will not
  run in this Win7 cron environment.
 
 It's actually not unique to Excel and it's not peculiar to Cygwin's cron.
 Any program that requires desktop interaction to run would suffer this same
 limitation on Vista and beyond if started from a service.  In the Cygwin
 environment, cron is run as a service and used to start programs, so it's
 the obvious 'culprit' reported here but it's just one of many possible
 vectors that exhibit the unwanted behavior on Windows.  Just FYI.
 
 --
 Larry
 
I think Denis is saying Excel hangs even if it doesn't require user 
interaction. 
 I.e.  it runs some macros and exits.   On Win7 Pro, I was able to run the 
following 
.vbs script via the task scheduler and have it run the  AddTimeInColumn macro.
The resulting spreadsheet had the times the task was run column A.

Andy

Here's the .vbs script:

Dim args, objExcel

Set args = WScript.Arguments
Set objExcel = CreateObject(Excel.Application)

objExcel.Workbooks.Open(C:\cygwin64\home\Andy\ExcelTest\TestExcel.xlsm)
objExcel.Visible = True

objExcel.Run AddTimeInColumn

objExcel.ActiveWorkbook.Save
objExcel.ActiveWorkbook.Close(0)
objExcel.Quit

Here's the macro:

Public Sub AddTimeInColumn()

Dim LastRowInColumn As Long

LastRowInColumn = Cells(Cells.Rows.Count, A).End(xlUp).Row

'If column is completely blank, need to adjust last row
If Cells(LastRowInColumn, A).Value =  Then LastRowInColumn = 0

'Insert time in next row
Cells(LastRowInColumn + 1, A).Value = Time()

End Sub




--
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: Unable to run excel via cron

[Andy Hall]

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
 Kiehl, Horst
 Sent: Wednesday, June 17, 2015 8:10 AM
 To: Kertz, Denis (D)** CTR **; cygwin@cygwin.com
 Subject: RE: Unable to run excel via cron
 
 (Trying to remove TOFU to make the conversation appear chronological again 
 and with correct attributions.)
 
 Kertz, Denis (D)** CTR ** d.kertz at alcatel-lucent dot com wrote:
We need to run some Excel programs via cron and are using vbscript to 
do this.  We have this running on a WinXP
 machine but are having trouble running on a Win7 machine, but we don't think 
 it is a Win7 problem.
   
Here's the script to run a simple test excel program:
   
[...]
 
 Bryan Berns wrote:
   What bitness of Excel and Cygwin are you running?
  
   CreateObject(Excel.application) will attempt to create a 32-bit
   instance of Excel when launched through the 32-bit version of
   wscript.exe or a 64-bit instance of Excel when launched through the
   64-bit version of Excel.  Which bitness of WScript.exe ends up being
   run will depend on the bitness of the parent program (which may be
   different in a command prompt vice Cygwin).  Try changing it to run
   Wscript.exe in SysWow64 instead of System32 (which is subject to
   automatic redirection) and see if changes the behavior.  If you're not
   running a 64-bit OS, then just ignore everything I said.
 
 Kertz, Denis (D)** CTR ** wrote:
 
  Unfortunately, using the 64-bit wscript.exe didn't change anything - same 
  behavior as before with excel hanging.
 
  We are using 64-bit cygwin and 32-bit Excel (Excel 2007).
 
 Although the aspect Corinna wrote about may be the culprit already,
 just in case:
 
 It appears that you, Denis, were misunderstanding Bryan. The consequence
 of what he tried to point out might be that you, using 64-bit Cygwin and
 32-bit Excel, would have to explicitly use the 32-bit wscript.exe
 instead of the 64-bit wscript.exe, to make sure that wscript.exe
 (32-bit) will start Excel (32-bit) successfully. In other words, you
 might have to use $windir/SysWOW64/wscript.exe (i.e.
 %windir%\SysWOW64\wscript.exe) from your 64-bit Cygwin process.
 
 (The reason for the seemingly backwards 32-bitness and 64-bitness of
 executables in SysWOW64 and system32, respectively, if viewed from a
 64-bit process, is to make code with hardcoded system32, whether
 compiled or interpreted, continue to work in a 64-bit context as well as
 in a 32-bit context.)
 
 Horst
 
Years ago,  I had a similar problem on Windows Server 2003.  I needed to run a 
component of Visual Studio in a
Cygwin-based nightly build system.   It would not run unless Visual Studio was 
running prior to the builds starting.   I
solved it by first bringing up Visual Studio this way.

VISUAL_STUDIO=Microsoft Visual Studio 8

ps -W | grep -q $VISUAL_STUDIO || \
cygstart --showminnoactive \
/cygdrive/c/Program Files/$VISUAL_STUDIO/Common7/IDE/devenv.exe /edit

So my question is, does having the Excel UI visible prior to running the cron 
job help?  

The other difference is I used the Windows Task Scheduler instead of cron to 
kick off the nightly build.   The .bat file
(still running, but obviously obsolete)  is

==
@echo off

C:
chdir C:\cygwin\bin

rem set CYGWIN=ntsec
set CYGWIN=binmode,nodosfilewarning

bash --login -i /home/build/bin/nightly_bootstrap.sh
==

This seemed to side-step any problems resulting from the differences in 
permission handling between Cygwin and Windows.


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

RE: Odd ezmlm warning messages from this list

[Andy Hall]

I sometimes get these as well.  My e-mail address is @ comcast dot net.  So 
it's a problem contacting the Comcast mail
servers, but it should be recoverable. 

Andy Hall
Fixpertise Consulting

 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
 Duncan Roe
 Sent: Thursday, January 29, 2015 2:03 AM
 To: cygwin
 Subject: Odd ezmlm warning messages from this list
 
 Hi,
 
 I get messages like the one below now and then. From the message text it would
 seem something has gone wrong with the mail formatting (2 reply addresses).
 
 This is just a heads-up,
 
 Cheers ... Duncan.
 
 - Forwarded message from cygwin-h...@cygwin.com -
 
 Date: 18 Jan 2015 00:03:42 -
 From: cygwin-h...@cygwin.com
 To: duncan_...@acslink.net.au
 Subject: ezmlm warning
 
 Hi! This is the ezmlm program. I'm managing the
 cygwin@cygwin.com mailing list.
 
 
 Messages to you from the cygwin mailing list seem to
 have been bouncing. I've attached a copy of the first bounce
 message I received.
 
 If this message bounces too, I will send you a probe. If the probe bounces,
 I will remove your address from the cygwin mailing list,
 without further notice.
 
 
 I've kept a list of which messages from the cygwin mailing list have
 bounced from your address.
 
 Copies of these messages may be in the archive.
 To retrieve a set of messages 123-145 (a maximum of 100 per request),
 send an empty message to:
cygwin-get.123_...@cygwin.com
 
 To receive a subject and author list for the last 100 or so messages,
 send an empty message to:
cygwin-in...@cygwin.com
 
 Here are the message numbers:
 
194279
194280
194281
194278
194447
 
 --- Enclosed is a copy of the bounce message I received.
 
 Return-Path: 
 Received: (qmail 6504 invoked for bounce); 6 Jan 2015 00:56:24 -
 Date: 6 Jan 2015 00:56:24 -
 From: mailer-dae...@sourceware.org
 To: cygwin-return-1942...@cygwin.com
 Subject: failure notice
 
 Hi. This is the qmail-send program at sourceware.org.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.
 
 duncan_...@acslink.net.au:
 User and password not set, continuing without authentication.
 duncan_...@acslink.net.au 202.124.241.196 failed after I sent the message.
 Remote host said: 550 Messages should have one or no Reply-To headers, not 2.
 
 
 - End forwarded message -
 
 --
  Please avoid sending me Word or PowerPoint attachments.
  See http://www.gnu.org/philosophy/no-word-attachments.html
 
 --
 Problem reports:   http://cygwin.com/problems.html
 FAQ:   http://cygwin.com/faq/
 Documentation: http://cygwin.com/docs.html
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


--
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: Testers needed: New passwd/group handling in Cygwin

[Andy Hall]

 On Mar  2 14:20, Frank Fesevur wrote:
  2014-02-28 22:08 GMT+01:00 Corinna Vinschen:
   That's not really a problem but a case of it is as it is.  To get the
   user and group info, Cygwin has to contact the DC and/or GC and then
   runs into a timeout.  Right now, the LDAP timeout is set to 3 seconds.
   I don't know yet if it's such a bright idea to lower this timeout value.
 
  I understand why it happens. And three seconds are not the problem.
 
  It is just a bit confusing to activate the shortcut and for 3 seconds
  nothing seems to happen. First time I double-clicked again because I
  though it wasn't working at all. Obviously a bit later two terminal
  showed up. If mintty would should up empty and wait those three
  seconds before something happens it is more clear it just takes some
  startup time. But maybe that is more a mintty problem.
 
 No, this is not mintty's fault.  You have to understand that the
 request for information from the DC is called before the actual
 application had any chance to initialize,  This happens before
 the application has, in fact, been called from the Cygwin DLL.
 
 Therefore, if the three seconds are a burden, there are three choices
 going forward:
 
 - We reduce the timeout to 1 second in general, which could be a problem
   when utilizing a slow VPN conncetion to the DC,
 
 - We allow the user to specify a timeout value and set the default to
   1 second.
 
 - We stick to the 3 seconds and users should switch to files (/etc/passwd
   /etc/group) when being offline from their DC.
 
 I'm really not sure what the best way is, I guess we as a community have
 to dice this out somehow.
 
 
 Corinna

Why not have a command that allows you choose whether or not you are on-line, 
that is, currently connected to a
network with a DC or off-line where you are not.  In the former you consult 
the DC in the latter you use the local
files?  That way you can leave the timeout at a reasonable value.


--
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: Little cygpath improvement request

[Andy Hall]

 
 On Sun, Feb 16, 2014 at 12:30 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote
  if [ ! -z $2 ] ; then NATIVE=$(cygpath -ml $2) ; fi
 
 That might better be written as this
 
 [ $2 ]  NATIVE=$(cygpath -ml $2)
 
 You do not need the extra quotes when setting a variable in this way.
 
Goodness. If code cleanliness is the issue, Why not simply hide this construct 
in a function?

function dospath() {
[ $1 ]  cygpath -ml $1
}

Then 

NATIVE=$(dospath $1)

Which is about as simple and clear as it gets.


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

RE: BUG: Ability to access nonexistent directories

[Andy Hall]

 
 On 5/20/2013 7:53 AM, Fedin Pavel wrote:
Hello!
 
Heh...
So, complete emulation would cost a major performance drop,
 right ?
Well... Can there be any setting which enables these checks ?
 At
  least we have one use case...
 
  Not without lots of new code.
 
  So, maybe next Thursday?
 
By the way, you said it would be slow... I have an idea how to
 implement a
  compromise solution which would not be horribly slow.
What if we check existence of intermediate paths not every time
 but only
  when we meet thing like '..' ?
I'll explain... For example, if we would access /foo/bar/baz,
 testing for
  /foo and /foo/bar existence would supposedly be a waste of time,
 because we
  would get Object not found on the final path too. But, when
 processing
  thing like /foo/bar/../baz, we really need to check for intermediate
 dirs.
  But, still not every time. In this example we actually need to test
 only for
  /foo/bar's existence. I. e. a path to which we apply '..', before
 stripping
  the last component.
Does it make sense ?
 
 Sure, that makes some sense.  It might help address the concern of not
 adding lots of new code and minimize the slowdown that the code would
 add.  But there is a clear reticence to fiddle with the path
 processing
 code because of its complexity already and its high use.  Even what
 seems
 like a small slowdown can be magnified because it is called so often.
 Small changes adding new features can add allot of complexity once all
 the
 corner cases are cleaned up (your case is a one known example of such
 a
 corner case).  So the message is not that folks here don't see the
 value
 in your suggestion or need help figuring out how to minimize the
 impact.
 What's needed is some code to do this and some good analysis that
 shows
 that it doesn't impact performance outside this corner case.  Such a
 patch
 could then be evaluated directly for any complexity it adds and the
 performance analysis could be used to objectively evaluate any impact
 there.
 Not to discourage you but there will be a fairly low tolerance for
 much of
 a complexity change or almost any performance degradation.  Cygwin's
 performance is a regular source of complaints on this list (and
 elsewhere).
 There's a difficult balancing act in this code so changes are not
 undertaken lightly.  Just fair warning. :-)
 
 --
 Larry
 
 _

So here is a naïve question.  Contrary to Corrina’s posting at
http://cygwin.com/ml/cygwin/2013-01/msg00173.html, the underlying OS
must effectively evaluate a path from left to right. Otherwise it cannot
locate the file in questions.  Now the OS may optimize this in a number
of ways, but in the end, the resulting optimization has to be equivalent
to a left to right evaluation. 

Furthermore, a Windows path can include “.” and “..”, so why not leave
these in for the first attempt to access the file?   Only if that fails,
then start breaking up the path to locate possible symbolic links,
missing directories or deal with other special cases?

Andy Hall


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

RE: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive

[Andy Hall]

 
  2.  Since this is a Windows thing, is there some reason why the
 execution
  of file or file.exe isn't handled as a special case in the exec call
  (and all its flavors) and no place else?
 
 make, for example? If you have a rule that creates foo from foo.c,
 gcc will actually create foo.exe. The next time you run make, it
 won't see foo and recreate foo.exe, even if foo.exe is still
 up to date.
 
 With the special handling of .exe, when make checks for foo, cygwin
 checks foo first, doesn't find anything, and then checks foo.exe,
 returning its result to make and make is happy.
 
 Anothen example: A script tries to execute foo from . , cygwin
 executes foo.exe instead and the script thinks foo exists,
 but a subsequent touch foo (or rm foo or whatever) fails, which
 is massively inconsistent.
 
 I consider the current handling of .exe files quite consistent.
 
 Or, in other words, when forced to choose between the two pains,
 I'd rather endure this.
 
 Otto
 
Well, this seems to be something that has to be addressed specifically in
make and gcc (and other similar places).  If make has a rule to create foo
from foo.c, then that is what it should do!  Dennis Ritchie would turn over
in his grave is he heard that commands like tar, rsync, zip, ... were not
idempotent WRT at least filenames and contents, let alone permissions.  

Andy



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

RE: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive

[Andy Hall]

 On 7/12/2012 8:03 AM, Andrey Repin wrote:
  Greetings, Steven Hartland!
 
  There really is not much point in rehashing this again under a
 different
  subject.
 
  If you or anyone would like to offer patches which change the behavior
  emphasis
  while keeping everyone happy about .exe handling
  /emphasis
  please do so.
 
  Isn't the commit which changed the behaviour stored so where,
  as this has worked fine in the past, so in theory it could be
  just applied in reverse?
 
  Reading comprehension is the skill you should train. Really.
 
 Indeed Steven.  Please review all the comments from this thread and
 the history of this change.  While you view this as a bug, others
 view it as a feature.  This is one area where Cygwin has to try to
 straddle the Windows and Linux worlds and there is no completely
 painless solution.  There are multiple workarounds that have already
 been presented to you if this new behavior doesn't suit your needs.
 Or you can wow us all with your abilities to find a comprehensive
 solution that no one has found before.
 
 --
 Larry
 

At the risk of adding more fuel to the fire, let me add my 2 cents worth to
this.

1.  As a long time and frequent user of tar and rsync to transfer files and
directories between Windows and various UNIX flavors, I have been astonished
(and severely burned) by the fact that transferring  files back and forth
between Windows and other UNIX machines via tar, rsync, cp -r or other
similar mechanisms are not idempotent operations, at least with respect to
file names and contents.  This violates the principle of least
astonishment not to mention that it breaks things in not so obvious and
surprising ways when it happens.  

2.  Since this is a Windows thing, is there some reason why the execution
of file or file.exe isn't handled as a special case in the exec call
(and all its flavors) and no place else?  For example, it would seem that if
exec is asked to run file with no .exe extension and that file  does not
exist or is not executable, then it could try file.exe if that exists and
is executable.  

Andy Hall



--
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 for Fedora?

[Andy Hall]

 
 Hello,
 
 Was wondering if it's possible to install / emulate Cygwin on Fedora?
 
 Basically, I want my scripts to be able to run flawlessly on both Fedora
 and
 Cygwin/Windows systems. Cygwin, I believe, can have different packages
 and/or
 different versions of programs in packages (e.g. /usr/bin/file, whose
 output for
 Microsoft documents changes with versions).
 
 Instead of asking for access to a Cygwin/Windows PC just for the above, I
 thought it would be terrific if Cygwin could somehow be installed /
 emulated on
 a Fedora.
 
 Regards,
 /HS

 
Harry -

I understand what you are asking for and it is a special case of wanting to
have the same shell scripts run in a Windows (e.g. Cygwin) and other UNIX
environments:  e.g. Linux, Solaris, HP/UX and AIX to name a few.
As you point out many commands with the same name actually have different
behaviors in different environments.  There are many ways this can be
handled and at the risk of starting a debate as to what is the best way, I
will give you one alternative that I have used successfully many times.

I create a file named common.sh which contains functions common to all my
scripts and functions which abstract out the differences between platforms.
This file is read into all my scripts using something like the following.

$BINDIR=`dirname` $0`  
. $BINDIR/common.sh

This assumes that all your scripts are in the same directory, but if not you
get the idea.

One key function in common.sh is:

setplat () {
# Set the location of UNIX commands and the
# names of some UNIX command.  And some common
# common parameters.

# Set default name of awk command
AWK_CMD=awk

# Set the OS specific parameters
set `uname -a`
OSVERSION=$1$3
case $OSVERSION in
SunOS*) PATH=/usr/bin
AWK_CMD=nawk
PLATFORM=SunOS
HOSTNAME=`hostname`
# Solaris hostname is a FQDN! Strip DN.
HOSTNAME=${HOSTNAME%%[.]*}
;;


Linux*) PATH=/bin:/usr/bin
PLATFORM=Linux
HOSTNAME=`hostname -s`
;;
CYG*)
PLATFORM=WINNT
;;

 # Other platforms removed for clarity.
esac
}

# Now determine where we are executing.
setplat

The above is by no means complete, as I have stripped out some stuff to make
it clearer.  Note that in the above the path is set to a restricted set of
directories.  This may not be what you want, but this example, is for a
build system and the construction environment is set elsewhere and refers to
absolute path names to commands used.  This ensures there are no mistakes
that might be made because of similar commands being installed by other
packages.

Now here is an example what you might do.  If running in a Windows
environment, some commands might yield a windows path name which should not
be passed into a Cygwin command.  So you define a function get_path which
always returns a POSIX style path.

get_path () {
case $OSVERSION in
CYG*)  `cygpath $1` ;;
*)  echo $1 ;;
esac
}

And you do things like 

SOURCE_ROOT=`get_path $SOURCE_ROOT`

Where you need to be sure you have a POSIX style path

Here's an example of a function that gets the value of the nth field from
standard input.  It deals with the problem of DOS line endings that might
occur in non-Cygwin environments. 

field () {
# Careful. The stuff in brackets is space tab.
sed s/[][  ]*/|/g | cut -d| -f$1 | sed s/$'\r'//
}

Now the nice thing about this approach is that all the platform differences
can be isolated / migrated to one place and tuned as you need.

HTH 

Andy Hall














--
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: Portable shell code between Cygwin and Linux

[Andy Hall]

 * Eliot Moss (Tue, 02 Aug 2011 11:40:44 -0400)
  On 8/2/2011 8:24 AM, Sebastien Vauban wrote:
   Thorsten Kampe wrote:
   * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200)
   My goal is to have just 1 alias that would work both under Win32
   (Cygwin) and Ubuntu
  
   Why don't have simply put your alias definitions in if [[ $OSTYPE =
   cygwin ]]; then else?
  
   Because I really want one single definition which could work on
   every system I'm using.
 [...]
  The suggestion to use a few conditionals that look at the which OS
  you're on does not involve continued tweaking. Once you have the right
  file, it works everywhere (for which you have provided suitable cases)
  using the exact same file. It's just that different parts get executed
  on different platforms. It's not as elegant as achieving an
  arrangement with no conditionals, but it's practical and flexible.
 
 Couldn't have said it better. Cygwin is not Linux and you just can't
 ignore the differences. For example I have different aliases for netstat
 and ps on Linux and on Windows. They just don't have the same options.
 
 Thorsten
 
I second this.  I have used that same technique since the late 80s to build
scripts that run on multiple platforms including Cygwin, Linux, Solaris,
HP-UX and AIX.  You can cover up all sorts of differences that way.  Its
about the only clean way of dealing with platform specific differences.  And
sadly, you may even have to stick with /bin/sh if you really want to be
portable.

Andy Hall


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

File name completion broken in 1.7.7?

[Andy Hall]

I have recently upgraded to 1.7.7 from 1.5.X.  In 1.5.X, it used to be that
in bash I could type lines like

P4 edit hydra_c

and hit the tab key to complete the file name.  A command like

p4 edit hydra_config

would be then executed.   

In 1.7.7, when I type

P4 edit hydra_c

and hit the tab key to complete the file name, I get the text bash:
_get_comp_words_by_ref(): `preprev': unknown argument
followed by the missing part of the filename.  The command completes
successfully as below:

ah...@ahall-pc /cygdrive/c/konaware/builder
$ p4 edit hydra_cbash: _get_comp_words_by_ref(): `preprev': unknown argument
onfig
//konaware/builder/hydra_config#6 - opened for edit

Now I do not get this behavior on other commands when I use filename
completion. It turns out that my p4 command is an alias that converts the
current working directory to a windows path name which is added to the real
p4 command as an option as below:

ah...@ahall-pc /cygdrive/c/konaware/builder
$ alias p4
alias p4='p4 -d `cygpath -w \$PWD\`'

So I set the -x option and ran the command again.

ah...@ahall-pc /cygdrive/c/konaware/builder
$ set -x

Wierdly, bash seems to run all sorts or stuff including p4 commands that
have nothing to do with the command I wanted executed.  It does finally get
around to executing the correct command.  See the last 2 lines below.

ah...@ahall-pc /cygdrive/c/konaware/builder
$ p4 edit hydra_c+ local cur prev preprev p4commands p4filetypes
+ COMPREPLY=()
+ _get_comp_words_by_ref cur prev preprev
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag cur prev preprev
+ [[ 3 -ge 1 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 3 -ge 2 ]]
+ case ${!OPTIND} in
+ vprev=prev
+ let 'OPTIND += 1'
+ [[ 3 -ge 3 ]]
+ case ${!OPTIND} in
+ echo 'bash: _get_comp_words_by_ref(): `preprev'\'': unknown argument'
bash: _get_comp_words_by_ref(): `preprev': unknown argument
+ return 1
++ awk 'NF3 {print $1}'
+++ cygpath -w /cygdrive/c/konaware/builder
++ p4 -d 'C:\konaware\builder' help commands
+ p4commands='add
admin
branch
branches
change
changes
client
clients
counter
counters
delete
depot
depots
describe
diff
diff2
dirs
edit
filelog
files
fix
fixes
flush
fstat
group
groups
have
help
info
integrate
integrated
job
jobs
jobspec
label
labels
labelsync
lock
obliterate
opened
passwd
print
protect
rename
reopen
resolve
resolved
revert
review
reviews
set
submit
sync
triggers
unlock
user
users
verify
where'
+ p4filetypes='ctext cxtext ktext kxtext ltext tempobj ubinary
uresource uxbinary xbinary xltext xtempobj xtext
text binary resource'
+ '[' 2 -eq 1 ']'
+ '[' 2 -eq 2 ']'
+ case $prev in
+ return 0
onfig
++ cygpath -w /cygdrive/c/konaware/builder
+ p4 -d 'C:\konaware\builder' edit hydra_config
//konaware/builder/hydra_config#6 - currently opened for edit

If I don't use file name completion, everything progresses normally!

$ p4 edit hydra_config
++ cygpath -w /cygdrive/c/konaware/builder
+ p4 -d 'C:\konaware\builder' edit hydra_config
//konaware/builder/hydra_config#6 - currently opened for edit

If I run a command that does not involve an alias, such as

vi hydra_c

and hit the tab key to complete the file name, hydra_config, I get a
completely different but presumably correct result.

ah...@ahall-pc /cygdrive/c/konaware/builder
$ vi hydra_c+ local IFS cur xspec
+ IFS='
'
+ COMPREPLY=()
+ _get_comp_words_by_ref cur
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag cur
+ [[ 1 -ge 1 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 1 -ge 2 ]]
+ __get_cword_at_cursor_by_ref '' words cword cur
+ words=()
+ local cword words
+ __reassemble_comp_words_by_ref '' words cword
+ local exclude i j ref
+ [[ -n '' ]]
+ eval cword=1
++ cword=1
+ [[ -n '' ]]
+ eval 'words=(' '${comp_wor...@]}' ')'
++ words=(${comp_wor...@]})
+ local i cur2
+ local 'cur=vi hydra_c'
+ local index=10
+ (( i = 0 ))
+ (( i = cword ))
+ [[ 10 -ge 2 ]]
+ [[ vi != \v\i ]]
+ [[ 0 -lt 1 ]]
+ local old_size=10
+ cur=' hydra_c'
+ local new_size=8
+ index=8
+ (( ++i  ))
+ (( i = cword ))
+ [[ 8 -ge 7 ]]
+ [[  hydra_ != \h\y\d\r\a\_\c ]]
+ cur=hydra_c
+ (( index-- ))
+ [[ 7 -ge 7 ]]
+ [[ hydra_c != \h\y\d\r\a\_\c ]]
+ [[ 1 -lt 1 ]]
+ (( ++i  ))
+ (( i = cword ))
+ [[ hydra_c != \h\y\d\r\a\_\c ]]
+ cur2=hydra_c
+ local words cword cur
+ _upvars -a2 words vi hydra_c -v cword 1 -v cur hydra_c
+ ((  10  ))
+ ((  10  ))
+ case $1 in
+ [[ -n 2 ]]
+ printf %d 2
+ [[ -n words ]]
+ unset -v words
+ eval 'words=(${@:3:2})'
++ words=(${@:3:2})
+ shift 4
+ ((  6  ))
+ case $1 in
+ [[ -n cword ]]
+ unset -v cword
+ eval 'cword=$3'
++ cword=1
+ shift 3
+ ((  3  ))
+ case $1 in
+ [[ -n cur ]]
+ unset -v cur
+ eval 'cur=$3'
++ cur=hydra_c
+ shift 3
+ ((  0  ))
+ [[ -n cur ]]
+ upvars+=($vcur)
+ upargs+=(-v $vcur 

RE: File name completion broken in 1.7.7?

[Andy Hall]

On 11/5/2010 David Rothenberger wrote:
 
 On 11/5/2010 10:13 AM, Andy Hall wrote:
  I have recently upgraded to 1.7.7 from 1.5.X.  In 1.5.X, it used to be
 that
  in bash I could type lines like
 
  P4 edit hydra_c
 
  and hit the tab key to complete the file name.  A command like
 
  p4 edit hydra_config
 
  would be then executed.
 
  In 1.7.7, when I type
 
  P4 edit hydra_c
 
  and hit the tab key to complete the file name, I get the text bash:
  _get_comp_words_by_ref(): `preprev': unknown argument
  followed by the missing part of the filename.
 
 I believe the bash-completion package is installed. It includes
 /etc/bash_completion.d/p4 which is causing your problems. The version of
 bash-completion included with 1.5 was not enabled by default, but the
 current version is. This is why the problem surfaced with 1.7. (Note
 that it has nothing to do with the Cygwin version but the version of
 bash-completion instead.)
 
 You can uninstall the bash-completion package if you don't want it at
 all (which is probably true since you hadn't enabled it in 1.5) or
 remove the /etc/bash_completion.d/p4 file.
 
 (Personally, I created a /etc/bash_completion.d/disabled directory and
 moved the files I didn't want there, for performance. I suspect I'll
 have to manually repeat this every time I update bash-completion. There
 may be a better official way to disable parts of bash-completion.)
 
 --
 David Rothenberger    daver...@acm.org
 
 Finagle's First Law:
 If an experiment works, something has gone wrong.

Yes, bash-completion was installed.  As I was not relying on it, I took your
advice and uninstalled it.  One thing I immediately noticed is that bash
starts up much, much faster.  Prior to uninstalling bash-completion, there
was a noticeable (and annoying) delay between clicking on my desktop Cygwin
shortcut and the time a bash prompt appeared!

Thanks for the help.

Andy Hall



--
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: In what way is /cygdrive special WRT to permissions?

[Andy Hall]

One final note on this:

At Jeremy's suggestion, I tried changing the way /cygdrive is mounted.  As
Administrator I changed /etc/fstab to read

//vega/repository /repos smbfs binary,noacl 0 0
none /cygdrive cygdrive binary,noacl,user 0 0

Mount now shows

administra...@taurus ~
$ mount
//vega/repository on /repos type smbfs (binary,noacl)
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,noacl,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,noacl,posix=0,user,noumount,auto)
H: on /cygdrive/h type smbfs (binary,noacl,posix=0,user,noumount,auto)

Note that all drives now seem to inherit noacl from the mount of /cygdrive
which for C: may not be what you want either.  

An ls -l of /cygrive/f now shows

administra...@taurus ~
$ ls -l /cygdrive/f
total 2048
drwxr-xr-x 36 Administrator None 0 2010-10-07 12:35 builds
drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases

and testing the ability to write you have

administra...@taurus ~
$ test -w /cygdrive/f/builds  echo you can write
you can write

This was always the case when you have Administrator privileges.

But, when logged in as user build which does not have Administrator
privileges, you now have:

$ ls -l /cygdrive/f
total 2048
drwxr-xr-x 36 build None 0 2010-10-07 12:35 builds
drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases

and

$ test -w /cygdrive/f/builds  echo You can write
You can write

Which is the way cygwin 1.5 behaved!  

Perhaps the default mounting of file systems that are not NTFS should be
with noacl, but that is a question best answered by more knowledgeable
people.  It would at least make the behavior of test consistent which what
you can actually do with the filesystem.


 
 Corinna -
 
 Thanks for the reply and clarification.  I have made the obvious change in
 my mounts to get around this problem.   However, there has been a change
 in behavior between 1.5 and 1.7.   I have 1.7.7 installed on Windows
 Server 2003 SP2.
 
 The mount table shows
 
 $ mount
 //vega/repository on /repos type smbfs (binary,noacl)
 C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
 C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
 C:/cygwin on / type ntfs (binary,auto)
 C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
 D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
 F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)
 H: on /cygdrive/h type smbfs (binary,posix=0,user,noumount,auto)
 
 F: also happens to be mapped to //vega/repository via the normal Windows
 mechanisms.
 
 When signed on to the Administrator account you have:
 
 administra...@taurus ~
 $ ls -l /repos
 total 2048
 drwxr-xr-x 36 Administrator None 0 2010-10-04 19:30 builds
 drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases
 
 administra...@taurus ~
 $ test -w /repos/builds  echo writeable
 writeable
 
 administra...@taurus ~
 $ ls -l /cygdrive/f
 total 2048
 drwxrwxr-x 36   0 2010-10-04 19:30 builds
 drwxrwxr-x 17   0 2010-10-04 18:23 releases
 
 administra...@taurus ~
 $ test -w /repos/builds  echo writeable
 writeable
 
 When logged on as the non-admistrative user build you have:
 
 bu...@taurus ~
 $ ls -l /repos
 total 2048
 drwxr-xr-x 36 build None 0 2010-10-04 19:30 builds
 drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases
 
 bu...@taurus ~
 $ test -w /repos/builds  echo writeable
 writeable
 
 bu...@taurus ~
 $ ls -l /cygdrive/f
 total 2048
 drwxrwxr-x 36   0 2010-10-04 19:30 builds
 drwxrwxr-x 17   0 2010-10-04 18:23 releases
 
 bu...@taurus ~
 $ test -w /cygdrive/f/builds  echo writeable
 
 bu...@taurus ~
 $ echo test /cygdrive/f/builds/zap
 
 bu...@taurus ~
 $ ls -l /cygdrive/f/builds/zap
 -rwxrwxr-x 1   5 2010-10-06 16:11 /cygdrive/f/builds/zap
 
 Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds
 is not writeable, yet you can create and write files in
 /cygdrive/f/builds!
 THIS IS INCONSTENT BEHAVIOR.  Cygwin 1.5 did not have this behavior.
 
 Regarding the mount of drive letters via /etc/fstab. I am not sure what
 the documentation should say about this.  Overriding the default mount of
 a single drive letter in fstab actually seems to work, although it simply
 reproduces the same behavior as the default.
 
 Even if I understood the actual behavior, I regret that am not familiar
 with the ways of Cygwin source maintenance to make the documentation
 changes.  I have to leave this to somebody else more qualified.
 
 Cheers, Andy
 
 
  On Oct  6  1:48 Corinna Vischen wrote:
 
 
  On Oct  5 15:40, Andy Hall wrote:
   If instead, I map F: to /cygdrive/c with the following entry in
  /etc/fstab
  
   F: /cygdrive/f smbfs binary,noacl 0 0
  
   mount shows
  
   $ mount
   C:/cygwin/bin on /usr/bin

RE: In what way is /cygdrive special WRT to permissions?

[Andy Hall]

Corinna -

Thanks for the reply and clarification.  I have made the obvious change in
my mounts to get around this problem.   However, there has been a change in
behavior between 1.5 and 1.7.   I have 1.7.7 installed on Windows Server
2003 SP2.

The mount table shows

$ mount
//vega/repository on /repos type smbfs (binary,noacl)
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)
H: on /cygdrive/h type smbfs (binary,posix=0,user,noumount,auto)

F: also happens to be mapped to //vega/repository via the normal Windows
mechanisms.   

When signed on to the Administrator account you have:

administra...@taurus ~
$ ls -l /repos
total 2048
drwxr-xr-x 36 Administrator None 0 2010-10-04 19:30 builds
drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases

administra...@taurus ~
$ test -w /repos/builds  echo writeable
writeable

administra...@taurus ~
$ ls -l /cygdrive/f
total 2048
drwxrwxr-x 36   0 2010-10-04 19:30 builds
drwxrwxr-x 17   0 2010-10-04 18:23 releases

administra...@taurus ~
$ test -w /repos/builds  echo writeable
Writeable

When logged on as the non-admistrative user build you have:

bu...@taurus ~
$ ls -l /repos
total 2048
drwxr-xr-x 36 build None 0 2010-10-04 19:30 builds
drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases

bu...@taurus ~
$ test -w /repos/builds  echo writeable
writeable

bu...@taurus ~
$ ls -l /cygdrive/f
total 2048
drwxrwxr-x 36   0 2010-10-04 19:30 builds
drwxrwxr-x 17   0 2010-10-04 18:23 releases

bu...@taurus ~
$ test -w /cygdrive/f/builds  echo writeable

bu...@taurus ~
$ echo test /cygdrive/f/builds/zap

bu...@taurus ~
$ ls -l /cygdrive/f/builds/zap
-rwxrwxr-x 1   5 2010-10-06 16:11 /cygdrive/f/builds/zap

Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds
is not writeable, yet you can create and write files in /cygdrive/f/builds!
THIS IS INCONSTENT BEHAVIOR.  Cygwin 1.5 did not have this behavior.

Regarding the mount of drive letters via /etc/fstab. I am not sure what the
documentation should say about this.  Overriding the default mount of a
single drive letter in fstab actually seems to work, although it simply
reproduces the same behavior as the default.
  
Even if I understood the actual behavior, I regret that am not familiar with
the ways of Cygwin source maintenance to make the documentation changes.  I
have to leave this to somebody else more qualified.  

Cheers, Andy


 On Oct  6  1:48 Corinna Vischen wrote:
 
 
 On Oct  5 15:40, Andy Hall wrote:
  If instead, I map F: to /cygdrive/c with the following entry in
 /etc/fstab
 
  F: /cygdrive/f smbfs binary,noacl 0 0
 
  mount shows
 
  $ mount
  C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
  C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
  C:/cygwin on / type ntfs (binary,auto)
  F: on /cygdrive/f type smbfs (binary,noacl)
  C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
 
  And ls -l of /cygdrive/f shows
 
  $ ls -l /cygdrive/f
  total 2048
  drwxrwxr-x 36   0 2010-10-04 16:30 builds
  drwxrwxr-x 17   0 2010-10-04 15:23 releases
  [...]
  Why am I getting -1 for the uid and gid when I mount to /cygdrive/f but
 not
  to /repos1?
 
 That's a restriction of the cygdrive prefix handling.  You can't
 override the cygdrive mount options for a single drive.  It's an
 all or nothing thingy.  I guess it would help to refuse such paths
 in /etc/fstab or mount(1), or at least improve the documentation,
 but, well, http://cygwin.com/acronyms/#SHTDI.
 
 
 Corinna
 
 --
 Corinna Vinschen  Please, send mails regarding Cygwin to
 Cygwin Project Co-Leader  cygwin AT cygwin DOT com
 Red Hat
 
 --
 Problem reports:   http://cygwin.com/problems.html
 FAQ:   http://cygwin.com/faq/
 Documentation: http://cygwin.com/docs.html
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




--
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: In what way is /cygdrive special WRT to permissions?

[Andy Hall]

There is no doubt that this behavior changed from 1.5 to 1.7.  The instant I
upgraded from 1.5 to 1.7.7,  build scripts that test for the abilty to write
to the directories in F: instantly started reporting the directories were
not writeable using test -w, yet you can still create and write files via
Cygwin.  

Furthermore, the user build can also create files and directories in F:
using windows, so the OS apparently thinks the user build has these access
rights as well.  Is it possible that test -w may have a bug?

The thing that is weird is that the explicit mount of //vega/repository on
/repos with noacl has the the desireable effect.  It you log in as
Administrator the files appear to be owned by Administrator and if you log
in as build, the files appear to be owned by build.  I would assume this is
the result of guessing the permissions when noacl is used.

The explict mounting of //vega/repository is the workaround I eventually
settled on.

Andy 

 On Oct  6 12:43, Corinna Vischen wrote:
 On Oct  6 13:19, Andy Hall wrote:
  Notice that the test -w /cygdrive/f/builds reports that
 /cygdrive/f/builds
  is not writeable, yet you can create and write files in
 /cygdrive/f/builds!
  THIS IS INCONSTENT BEHAVIOR.  Cygwin 1.5 did not have this behavior.
 
 I somehow doubt that.  I'm just not sure if I can explain that
 correctly, given how tired I am.  The difference is that under 1.5 all
 smb drives were by default mounted with noacl, aka
 CYGWIN=nosmbntsec.  So all permissions were just faked and Cygwin's
 access call was more or less a wild guess.  With a drive mounted with
 acl the OS (yes, Windows itself) is asked if the current user has
 write permissions, based on the current user token and the ACL of the
 file.  Apparently non writable is what you get here, because the ACL
 returned by the Samba drive only contains the ACEs for the Linux user and
 group, not for your current Windows user and group.  You can add these
 Linux user's and groups to your local passwd and group file (see
 http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd and
 http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup), but it won't
 change what the OS returns in the access check.  I'm sorry, this bugs
 me for years, but there nothing Cygwin can do about this.  Nor can Samba
 do anything.  Yes, I asked on the samba developer mailing list at one
 point...
 
 The fact that the admin can write is normal, too, since admins (those
 not restricted by UAC) always have write permissions under Cygwin 1.7.7,
 just like a root user under Linux.  That's probably even documented
 somewhere, I just don't recall where.
 
 
 Corinna
 
 --
 Corinna Vinschen  Please, send mails regarding Cygwin to
 Cygwin Project Co-Leader  cygwin AT cygwin DOT com
 Red Hat
 
 --
 Problem reports:   http://cygwin.com/problems.html
 FAQ:   http://cygwin.com/faq/
 Documentation: http://cygwin.com/docs.html
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




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

In what way is /cygdrive special WRT to permissions?

[Andy Hall]

I have a vanilla 1.7.7 installation on Windows XP Professional which is a
standalone machine not in a domain.   The /etc/passwd and /etc/group files
have been refreshed from scratch.

The system has a remote file system (Samba) mounted as F: via the normal 
Windows mechanism for mapping network drives.   

With the default /etc/fstab file which has no specific mounts, the 
mount command shows

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)

and ls -l of /cygdrive/f shows

$ ls -l /cygdrive/f
total 2048
drwxrwxr-x 36   0 2010-10-04 16:30 builds
drwxrwxr-x 17   0 2010-10-04 15:23 releases

If instead, I map F: to /cygdrive/c with the following entry in /etc/fstab

F: /cygdrive/f smbfs binary,noacl 0 0

mount shows

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
F: on /cygdrive/f type smbfs (binary,noacl)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)

And ls -l of /cygdrive/f shows

$ ls -l /cygdrive/f
total 2048
drwxrwxr-x 36   0 2010-10-04 16:30 builds
drwxrwxr-x 17   0 2010-10-04 15:23 releases


If instead I now map F: to /repos1 via the following in /etc/fstab 

F: /repos1 smbfs binary,noacl 0 0

Mount shows

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
F: on /repos1 type smbfs (binary,noacl)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)

And ls -l of repos1 shows

$ ls -l /repos1
total 2048
drwxr-xr-x 36 ahall None 0 2010-10-04 16:30 builds
drwxr-xr-x 17 ahall None 0 2010-10-04 15:23 releases

Why am I getting -1 for the uid and gid when I mount to /cygdrive/f but not
to /repos1?

Andy




--
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.5 to 1.7 upgrade.

[Andy Hall]

I held off updating two machines from Cygwin 1.5 to 1.7 until this week
because they were critical to a product test and release process.  These
Cygwin installations are nearly vanilla and the upgrades went very smoothly
and except for one crucial item everything seems to have worked as expected.
Kudos to every one who contributed to this effort! 

Here's what didn't work.  Both machines map a Samba file system to the F:
drive via the normal windows mechanisms and I can read/write files in these
file system via windows.   However creating or writing files in these file
systems via Cygwin now fails whereas prior to the upgrade this was just
fine.

When I list the cygdrive directory, I get

$ ls -l
total 1024
drwxrwxr-x+ 1 Administrators SYSTEM   0 2010-10-02 02:08 c
drwxrwxr-x  4     0 2009-10-30 08:08 f

and 

$ ls -l -n
total 1024
drwxrwxr-x+ 1544 18 0 2010-10-02 02:08 c
drwxrwxr-x  4 4294967295 4294967295 0 2009-10-30 08:08 f

I can't remember what user / groups used to appear, but the fact that I get
the 4294967295 is clearly related to the problem.   

Mount shows

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)

which seems perfectly normal.   

The Samba version on the remote machine (Linux) is 3.0.10-1.4E.9.

Some time ago, I remember seeing e-mail in the cygwin mailing list reporting
similar issues, but I don't remember the resolution and searching has not
produced one.   

I ran the /bin/copy-user-registry-fstab script as a precaution, but this
understandably didn't do anything because I never had any mount points to
begin with. 

I don't particularly want to ask the sys admins to upgrade Samba and am
looking for a workaround.   Any help would be appreciated.

Andy Hall




--
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.5 to 1.7 upgrade.

[Andy Hall]

Slight embarrassment here.  Things are not quite as described below but
there is a problem.

1. The file systems in F: are indeed writeable, as test with echo
builds/test demonstrated.  This is what you would expect given the
permissions shown by ls despite the question marks in the uid and gid
fields.   What is bizarre is that on one machine which is Windows 2003
Server SP2, the following happens

bu...@taurus /cygdrive/f
$ ls -l
total 2048
drwxrwxr-x 36   0 2010-10-04 19:19 builds
drwxrwxr-x 17   0 2010-10-04 18:23 releases

bu...@taurus /cygdrive/f
$ test -w /cygdrive/f/builds

bu...@taurus /cygdrive/f
$ echo $?
1

Which is why I originally thought the file system is not writeable.

On the other machine which is Windows XP Professional, you have

$ ls -l
total 2048
drwxrwxr-x 36   0 2010-10-04 16:19 builds
drwxrwxr-x 17   0 2010-10-04 15:23 releases

ah...@ahall-pc /cygdrive/f
$ test -w /cygdrive/f/builds

ah...@ahall-pc /cygdrive/f
$ echo $?
0

Now if I explicitly mount the remote samba share by putting the following in
/etc/fstab

//10.1.13.25/repository /repos smbfs binary,noacl 0 0

Mount produces

ah...@ahall-pc /cygdrive/f
$ mount
//10.1.13.25/repository on /repos type smbfs (binary,noacl)
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)

and if I cd to /repos and do an ls, I get the following with a reasonable
uid and gid.  

ah...@ahall-pc /repos
$ ls -l
total 2048
drwxr-xr-x 36 ahall None 0 2010-10-04 16:30 builds
drwxr-xr-x 17 ahall None 0 2010-10-04 15:23 releases

Now without the explicit mounting of the directories, mount produced

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)

So the issue seems to be the difference between the use of noacl in my
explicit mount and the default one chosen by Cygwin.   How do I force the
default one to be mounted with noacl?


===


I held off updating two machines from Cygwin 1.5 to 1.7 until this week
because they were critical to a product test and release process.  These
Cygwin installations are nearly vanilla and the upgrades went very smoothly
and except for one crucial item everything seems to have worked as expected.
Kudos to every one who contributed to this effort! 

Here's what didn't work.  Both machines map a Samba file system to the F:
drive via the normal windows mechanisms and I can read/write files in these
file system via windows.   However creating or writing files in these file
systems via Cygwin now fails whereas prior to the upgrade this was just
fine.

When I list the cygdrive directory, I get

$ ls -l
total 1024
drwxrwxr-x+ 1 Administrators SYSTEM   0 2010-10-02 02:08 c
drwxrwxr-x  4     0 2009-10-30 08:08 f

and 

$ ls -l -n
total 1024
drwxrwxr-x+ 1544 18 0 2010-10-02 02:08 c
drwxrwxr-x  4 4294967295 4294967295 0 2009-10-30 08:08 f

I can't remember what user / groups used to appear, but the fact that I get
the 4294967295 is clearly related to the problem.   

Mount shows

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto)

which seems perfectly normal.   

The Samba version on the remote machine (Linux) is 3.0.10-1.4E.9.

Some time ago, I remember seeing e-mail in the cygwin mailing list reporting
similar issues, but I don't remember the resolution and searching has not
produced one.   

I ran the /bin/copy-user-registry-fstab script as a precaution, but this
understandably didn't do anything because I never had any mount points to
begin with. 

I don't particularly want to ask the sys admins to upgrade Samba and am
looking for a workaround.   Any help would be appreciated.

Andy Hall




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

RE: GREP: Memory Exhausted

[Andy Hall]

I get this error all the time from simple recursive greps on large
source directory trees.   E.g.

$ grep -r zap *
Binary file SDE/BUILD_DBG/dist/ship.tar matches
Binary file SDE/BUILD_DBG/ship/lib/servlet-api.jar matches
grep: memory exhausted

$ grep --version
GNU grep 2.5.3

Copyright (C) 1988, 1992-2002, 2004, 2005  Free Software Foundation,
Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

The same grep on Linux or Solaris usually works, but I think only
because virtual memory is handled differently. 

If you watch memory consumption on windows while grep is running, it
remains flat for about 30 seconds and then starts growing in sizeable
chunks until it fails.  

And BTW, there was an earlier version of grep that worked but I have
since lost the version number.

Andy Hall


 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
Behalf
 Of Christopher Faylor
 Sent: Tuesday, April 14, 2009 8:15 AM
 To: cygwin@cygwin.com
 Subject: Re: GREP: Memory Exhausted
 
 On Tue, Apr 14, 2009 at 10:45:44AM -0400, Ralph Hempel wrote:
  Dave Korn wrote:
  Shailesh Dadure wrote:
  Hello All,
 
  I am a support engineer from Microsoft trying to help my Customer
 Maziyar
  Samadzadeh. We have been notified by Maziyar that when they
perform a
  Query
  on a bigger database using GREP we get the following error
Would you like to use one of your two free phone support
incidents on
  this
  request, or will you be paying by credit or debit card for a paid
 support
  ticket?
 
  Geez Dave. I was going to suggest rebooting the machine to see if
that
  changed anything, and then upgrading to Windows 7. But then I
thought
  that it might be taken the wrong way...
 
  And why would anyone query a database using GREP?
 
 And a followup question:  Is it really Cygwin's grep?  The error
message
 looks
 suspicious.
 
 cgf
 
 --
 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/


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

Bash sometimes writes to stdout in MS_DOS format.

[Andy Hall]

I am having a very strange problem with bash 3.2.48-21 It goes like
this.

From a bash shell I invoke another bash shell as follows: 

ERROR_LOG=/tmp/error.$$.log
BUILD_LOG=/tmp/build.$$.log
...
./$PRODUCT_CMD  $BUILD_LOG 2$ERROR_LOG

All my files are mounted in binmode E.g.

C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)
d: on /cygdrive/d type system (binmode,noumount)

If $PRODUCT_CMD encounters an error, it will execute the following
function to write an error message to stderr and stdout and exit with a
specified non-zero exit code. 

errmsg () {
# Error information is written to the stderr in the
# form of parameter settings that can be read by a
# parent shell
echo BUILD_MASTER=\$BUILD_MASTER\ 12
echo PRODUCT_ENGINEERS=\$PRODUCT_ENGINEERS\ 12
echo ERROR_MESSAGE=\$1\ 12
# Log message to stdout as well.
[ $1 !=  ]  echo $1
[ $2 !=  ]  exit $2
}

The parent command on getting a non-zero exit code.  Does the following.

. $ERROR_LOG

Now here is the strange stuff.

1.  If I start the parent script from a bash window, this all works
fine. If the child script exits with a non-zero exit code, the .
command reads the $ERROR_LOG without a problem. 
2.  If the parent script is started by a Windows task running as the
cygwin user, the $ERROR_LOG will SOMETIMES be written in DOS format with
CR LF line endings.  It seems to depend on the depth of function nesting
at the time errmsg is invoked.  It is as if bash forgets some
attribute of file descriptor 2 under some curious circumstances.  This
is totally repeatable.  All I have to do is induce certain errors
detectable by the child script, $PROGRAM_CMD.

I have been unable to create a simple test case that exhibits this
behavior, probably because of #1. 

The scripts are pretty much platform independent and run on Linux,
Solaris and HP-UX without a problem.  There are only a few things which
are platform dependent. I can of course inject a work-around if the
script is running in the cygwin environment.  I am wondering if anybody
has any plausible explanation for this.  

Andy Hall


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

A question about cygstart

[Andy Hall]

I have build scripts for .NET and .NET CF apps, that require Visual Studio to 
be running in order for the build to complete.   Because these builds all run 
in the background I would like to start Visual Studio minimized so that it does 
not interfere with other activities while the build is running.

I start Visual Studio in the scripts as follows. 

cygstart --showminimized   /cygdrive/c/Program Files/Microsoft Visual Studio 
8/Common7/IDE/devenv.exe /edit

If Visual Studio is not ruining, Visual Studio will start minimized.   However, 
if Visual Studio is already running, a subsequent invocation of the same 
command will bring up the window maximized. 

No combination of options to cygstart seems to overcome this.   What other 
approaches are available. 



Andy Hall
ServicePower, Inc.
744 San Antonio Road
Phone: (650) 739-0988
E-Mail: a.h...@servicepower.com


--
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: Strange permissions problems running bash scripts from ssh

[Andy Hall]

If I ssh into the same cygwin account from a remote machine, and perform
the identical test, that is, changing directory to a directory in F:,
then run echo test zap fails with permission denied. 
I am sure is some weird problem with NT permissions or the account under
which the sshd is run, but I have not been able to figure it out.  BTW,
sshd was started from my cygwin account, not Administrator.  Can that be
the problem?   Setting CYGWIN to nontsec or ntsec does not seem to make
a difference.   


You should never run a service as Administrator.  There is no advantage
to this unless you've added permissions to Adminstrator that don't
ordinarily come with Windows or you just prefer having Administrator
running your service for some reason.

When you say that you're running 'sshd' as my cygwin account, how did
you accomplish this?  Did you use an altered form of '/bin/ssh-host-config',
did you just start 'sshd' from the command line, or something else?

I used the out-of-the-box /bin/ssh-host-config and then started sshd via
cygrunsrv -s sshd.   When installing, I answered no to the question about
privilege separation.  Could this be the root cause?

A review of http://cygwin.com/problems.html might help to get the basics 
covered.
Another annoyance is that when the bash scripts are run locally, e.g. in
a cygwin window started on the server, everthing works fine.   Under
SSH, I get minor failures because I start getting DOS line endings in
surprising places.  E.g. commands like basename and the result in a \r.

And you're sure that 'basename' is Cygwin's version?

Yes

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

Strange permissions problems running bash scripts from ssh

[Andy Hall]

I have a very strange permission problem with running bash scripts on a
Wndows server (2000) from a remote Linux box.   Here's the scenario.

The Windows Server where the bash scripts are run has a remote file
system mounted as F:  The file system mounted is from a samba server.
When the drive is mapped in, the userid and password of a user with
write permission is used.

When I login to the server either locally (or via VNC) using a my cygwin
account and then change directory to a directory in the F: drive, I can
happily create files there. E.g. the command, echo test zap, creates a
file named zap without a problem.  I can of course create files in any
directory in my cygwin account as well.  In short, everything works as
expected. 

If I ssh into the same cygwin account from a remote machine, and perform
the identical test, that is, changing directory to a directory in F:,
then run echo test zap fails with permission denied. 

I am sure is some weird problem with NT permissions or the account under
which the sshd is run, but I have not been able to figure it out.  BTW,
sshd was started from my cygwin account, not Administrator.  Can that be
the problem?   Setting CYGWIN to nontsec or ntsec does not seem to make
a difference.   

Another annoyance is that when the bash scripts are run locally, e.g. in
a cygwin window started on the server, everthing works fine.   Under
SSH, I get minor failures because I start getting DOS line endings in
surprising places.  E.g. commands like basename and the result in a \r.

--
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: fork: Resource temporarily unavailable

[Andy Hall]

The answers to Larry Hall's questions on my original posting are below.

Andy Hall wrote: 
It seems that somewhere between cygwin 1.5.19-4 and 1.5.21-2 some change was
made that causes this error.   I have a bash script that is used to create a
number of client processes that run in parallel and generate TCP/IP
conversations with a remote server being tested   This script can configure
and run any number of these clients executing simultaneously.  The clients
can be either .exe files based on .NET or a JVM (.exe) running a Java-based
client.   These scripts run flawlessly on Linux or Solaris (java clients
only) or on a Win2K Professional box running cygwin 1.5.19-4 (both java or
.NET clients)   They were also running flawlessly on a Win2K Server, until
it got upgraded to cygwin 1.5.2.21-2.   After that, the scripts run for a
while until the message fork: Resource temporarily unavailable occurs, at
which point there are all sorts of bizarre and unexplainable failures.  If
run for a reasonable amount of time these scripts will always result in this
error message.


The obvious question is,  How can we revert the Win2K Server back to cygwin
1.5.2.19.4 so that we can continue to run tests from this machine?

Alternatively, is there fix or patch available for this?

I have attached the output of cygcheck for both machines. 

Larry Hall's questions:

How does it run outside the terminal server?

 I did the experiment.  Running from the console fails as well.  

Has the virus scanner been installed/updated on the server?  How about
recently installed Logitech drivers?  Both of these have been implicated
in fork-related failures. 

 This is an out-of-the-box, vanilla W2K Server with up-to-date MS patches,
 simple CRT console and serial mouse.  No A/V SW or special drivers.
 The only third party software installed is:

 1. J2SE JDK 1.5
 2. MS .NET Framework 1.1
 3. MySQL (which is not running)
 4. Secure Shell (which was not running in the above experiment)
 5. Cygwin 1.5.2.21-2

Andy Hall
KonaWare, Inc.
www.konaware.com



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

fork: Resource temporarily unavailable

[Andy Hall]

It seems that somewhere between cygwin 1.5.19-4 and 1.5.21-2 some change was
made that causes this error.   I have a bash script that is used to create a
number of client processes that run in parallel and generate TCP/IP
conversations with a remote server being tested   This script can configure
and run any number of these clients executing simultaneously.  The clients
can be either .exe files based on .NET or a JVM (.exe) running a Java-based
client.   These scripts run flawlessly on Linux or Solaris (java clients
only) or on a Win2K Professional box running cygwin 1.5.19-4 (both java or
.NET clients)   They were also running flawlessly on a Win2K Server, until
it got upgraded to cygwin 1.5.2.21-2.   After that, the scripts run for a
while until the message fork: Resource temporarily unavailable occurs, at
which point there are all sorts of bizarre and unexplainable failures.  If
run for a reasonable amount of time these scripts will always result in this
error message.

The obvious question is,  How can we revert the Win2K Server back to cygwin
1.5.2.19.4 so that we can continue to run tests from this machine?

Alternatively, is there fix or patch available for this?

I have attached the output of cygcheck for both machines.  



w2ks.cygcheck.out
Description: Binary data


w2kp.cygcheck.out
Description: Binary data
--
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: Upgraded man command

[Andy Hall]

Igor -

I don't have /etc/postinstall/man.sh but I do have man.sh.done.  After
looking at the latter, I simply ran it as you suggested. It seemed to do
just what was required without error.  I will take your advice and check the
other postinstall scripts as well.  The setup.log says it ran.

BTW the way my mailer is OutLook (Look Out!) so I am not sure what you are
asking me to do in the way of display names.  Are you recommending I use the
cygwin mailer for this stuff?

I am not sure it is totally the -r option in less.  My memory fades quickly,
but I think the man -d was showing less -r when I was having the problem.

All is well now.

Andy

-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 24, 2004 8:32 AM
To: Andy Hall
Cc: [EMAIL PROTECTED]
Subject: RE: Upgraded man command

Andy,

Do you have both /etc/postinstall/man.sh and /etc/postinstall/man.sh.done?
If so, then the newer version of the postinstall script has not completed
properly.  I'd run /etc/postinstall/man.sh and then rename it to
/etc/postinstall/man.sh.done.  If the only thing you have is
/etc/postinstall/man.sh.done, then that's the script that you'll need to
re-run (don't worry about the timestamp, it doesn't have to be after the
install time).  When you copied the default config file, you did part of
the job of that postinstall script (AFAICS, creating manpath.exe is the
other part, hence the question).

What I'd be worried about if I were you is that none of the postinstall
scripts on that particular upgrade may have run properly.  It might make
sense to see for all packages that you upgraded what the postinstall
scripts were supposed to do, and whether they did it.

Two more points: first, http://cygwin.com/acronyms/#PCYMTNQREAIYR.  And
second, a small correction to my statement below -- the -Tascii is not a
problem, it was the fact that less was missing the -r flag.
Igor

On Tue, 23 Nov 2004, Andy Hall wrote:

 Perhaps not everything is as it should be

 1. /bin/manpath.exe is missing
 2. /etc/postinstall/man.sh.done is there but it was modified on a date
 preceding the date I upgraded.
 3. No errors for man.sh in /var/logs/setup and it shows it was run.

 But I simply copied the man.conf.default to man.conf, ensured the
 options matched yours and it now works.  Go figure.

 Thanks for the help.

 Andy

 -Original Message-
 From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 23, 2004 1:22 PM
 To: Andy Hall
 Cc: [EMAIL PROTECTED]
 Subject: RE: Upgraded man command

 On Tue, 23 Nov 2004, Andy Hall wrote:

  Igor -
 
  Thanks for the reply. This is a complete mystery to me.  See answers
  to your questions below.
 
  Andy
 
  -Original Message-
  From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, November 23, 2004 9:46 AM
  To: Andy Hall
  Cc: [EMAIL PROTECTED]

 http://cygwin.com/acronyms/#PCYMTNQREAIYR.  Thanks.

  Subject: Re: Upgraded man command
 
   On Tue, 23 Nov 2004, Andy Hall wrote:
  
I updated my cygwin system on my W2K SP4 systemto the latest release
of
cygwin and the man command started to display man pages as follows:
   
ESC[1mNAMEESC[0m
   ln - make links between files
   
ESC[1mSYNOPSISESC[0m
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m
[ESC[4mLINK_NAMEESC[24m]
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]...
ESC[4mTARGETESC[24m...
ESC[4mDIRECTORYESC[0m
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]...
ESC[4m--target-directory=DIRECTORYESC[24m ESC[4mTARGETESC[24m...
   
Interestingly, the man pages previously cached in /usr/man/cat1 seem
to
format just fine.  If I remove the cached version, I get something
akin to
the above.
   
I suspect this is some sort of setup problem, but I have been unable
to
track it down.  All involved commands seem to be up-to-date.
  
   I see that neither of MANPAGER, PAGER, and LESS is set in your
   environment.
 
  Right.  I use a pretty vanilla system for testing a fairly large
messaging
  system.  I tend to stay away from environment variables if I can.
 
   Are you running straight man, or is it aliased to
   something?
 
  Straight man.
 
   Is your /usr/share/misc/man.conf different from
   /usr/share/misc/man.conf.default?
 
  There is no /usr/share/misc/man.conf.  Do I need one?  I should think
not.

 You do, actually.  It was supposed to have been created by the man
 postinstall script.  Since you don't have it, I assume the postinstall
 scripts didn't run correctly, and so you might have a misconfigured
 system.

 Check if you have a /bin/manpath.exe as a symlink to man.exe.  Also check
 that you have a /etc/postinstall/man.sh.done (not
/etc/postinstall/man.sh).
 If you happened to not run setup.exe after that upgrade, please also look
 in /var/log/setup.log.full to see if you got any error messages from
 /etc/postinstall/man.sh.

   If it is, the differences might

Upgraded man command

[Andy Hall]

I updated my cygwin system on my W2K SP4 systemto the latest release of
cygwin and the man command started to display man pages as follows:

ESC[1mNAMEESC[0m
   ln - make links between files

ESC[1mSYNOPSISESC[0m
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m
[ESC[4mLINK_NAMEESC[24m]
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m...
ESC[4mDIRECTORYESC[0m
   ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]...
ESC[4m--target-directory=DIRECTORYESC[24m ESC[4mTARGETESC[24m...

Interestingly, the man pages previously cached in /usr/man/cat1 seem to
format just fine.  If I remove the cached version, I get something akin to
the above.

I suspect this is some sort of setup problem, but I have been unable to
track it down.  All involved commands seem to be up-to-date.

Andrew D. Hall
VP, Customer Services
KonaWare, Inc.
Tel: (650) 482-9122
E-Mail: [EMAIL PROTECTED]


cygcheck.out
Description: Binary data
--
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: Upgraded man command

[Andy Hall]

Igor -

Thanks for the reply. This is a complete mystery to me.  See answers to your
questions below.

Andy

-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 23, 2004 9:46 AM
To: Andy Hall
Cc: [EMAIL PROTECTED]
Subject: Re: Upgraded man command

On Tue, 23 Nov 2004, Andy Hall wrote:

 I updated my cygwin system on my W2K SP4 systemto the latest release of
 cygwin and the man command started to display man pages as follows:

 ESC[1mNAMEESC[0m
ln - make links between files

 ESC[1mSYNOPSISESC[0m
ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m
 [ESC[4mLINK_NAMEESC[24m]
ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m...
 ESC[4mDIRECTORYESC[0m
ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]...
 ESC[4m--target-directory=DIRECTORYESC[24m ESC[4mTARGETESC[24m...

 Interestingly, the man pages previously cached in /usr/man/cat1 seem to
 format just fine.  If I remove the cached version, I get something akin to
 the above.

 I suspect this is some sort of setup problem, but I have been unable to
 track it down.  All involved commands seem to be up-to-date.

I see that neither of MANPAGER, PAGER, and LESS is set in your
environment.  
Right.  I use a pretty vanilla system for testing a fairly large messaging
system.  I tend to stay away from environment variables if I can.
Are you running straight man, or is it aliased to
something?  
Straight man. 
Is your /usr/share/misc/man.conf different from
/usr/share/misc/man.conf.default?  
 There is no /usr/share/misc/man.conf.  Do I need one?  I should think
not.
If it is, the differences might give
you a clue as to what went wrong. 
 What is the output of man -cd ln |
tail -1?
Well the tail -1 did not work so the output of man -d must be on stderr.
Any way the last lines are:

not executing command:
  (cd /usr/man  (echo .pl 11i; cat '/usr/man/man1/ln.1') |
/usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -i
s)

I do know from experimentation that the zipped versions of the man pages
produced by the updated man command are different from the ones produced by
the old man command.

Andy



--
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: Upgraded man command

[Andy Hall]

Perhaps not everything is as it should be

1. /bin/manpath.exe is missing
2. /etc/postinstall/man.sh.done is there but it was modified on a date
preceding the date I upgraded.
3. No errors for man.sh in /var/logs/setup and it shows it was run.

But I simply copied the man.conf.default to man.conf, ensured the
options matched yours and it now works.  Go figure.

Thanks for the help.

Andy

-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 23, 2004 1:22 PM
To: Andy Hall
Cc: [EMAIL PROTECTED]
Subject: RE: Upgraded man command

On Tue, 23 Nov 2004, Andy Hall wrote:

 Igor -

 Thanks for the reply. This is a complete mystery to me.  See answers to
your
 questions below.

 Andy

 -Original Message-
 From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 23, 2004 9:46 AM
 To: Andy Hall
 Cc: [EMAIL PROTECTED]

http://cygwin.com/acronyms/#PCYMTNQREAIYR.  Thanks.

 Subject: Re: Upgraded man command

  On Tue, 23 Nov 2004, Andy Hall wrote:
 
   I updated my cygwin system on my W2K SP4 systemto the latest release
of
   cygwin and the man command started to display man pages as follows:
  
   ESC[1mNAMEESC[0m
  ln - make links between files
  
   ESC[1mSYNOPSISESC[0m
  ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m
   [ESC[4mLINK_NAMEESC[24m]
  ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]... ESC[4mTARGETESC[24m...
   ESC[4mDIRECTORYESC[0m
  ESC[1mln ESC[22m[ESC[4mOPTIONESC[24m]...
   ESC[4m--target-directory=DIRECTORYESC[24m ESC[4mTARGETESC[24m...
  
   Interestingly, the man pages previously cached in /usr/man/cat1 seem
to
   format just fine.  If I remove the cached version, I get something
akin to
   the above.
  
   I suspect this is some sort of setup problem, but I have been unable
to
   track it down.  All involved commands seem to be up-to-date.
 
  I see that neither of MANPAGER, PAGER, and LESS is set in your
  environment.

 Right.  I use a pretty vanilla system for testing a fairly large messaging
 system.  I tend to stay away from environment variables if I can.

  Are you running straight man, or is it aliased to
  something?

 Straight man.

  Is your /usr/share/misc/man.conf different from
  /usr/share/misc/man.conf.default?

 There is no /usr/share/misc/man.conf.  Do I need one?  I should think not.

You do, actually.  It was supposed to have been created by the man
postinstall script.  Since you don't have it, I assume the postinstall
scripts didn't run correctly, and so you might have a misconfigured
system.

Check if you have a /bin/manpath.exe as a symlink to man.exe.  Also check
that you have a /etc/postinstall/man.sh.done (not /etc/postinstall/man.sh).
If you happened to not run setup.exe after that upgrade, please also look
in /var/log/setup.log.full to see if you got any error messages from
/etc/postinstall/man.sh.

  If it is, the differences might give you a clue as to what went wrong.
   What is the output of man -cd ln | tail -1?

 Well the tail -1 did not work so the output of man -d must be on stderr.

Umm, yeah, sorry, that should have been man -cd ln 21 | tail -1.

 Any way the last lines are:

 not executing command:
   (cd /usr/man  (echo .pl 11i; cat '/usr/man/man1/ln.1') |
/usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -is)

Aha.  There you go.  It's the -Tascii that's the problem, as well as the
less flags.  In my installation, the command is as follows:

  (cd /usr/man  (echo .pl 11i; /usr/bin/cat '/usr/man/man1/ln.1') |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc | /usr/bin/less -isrR)

The commands above come from /usr/share/misc/man.conf, so yes, you do
need it.

 I do know from experimentation that the zipped versions of the man pages
 produced by the updated man command are different from the ones produced
by
 the old man command.

I'm not sure what you mean.  The zipped versions of the man pages aren't
produced by the man command.  They are used as inputs to the man command.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT




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