Re: ImageMagick shared libraries missing?

[Sivaram Neelakantan]

"Larry Hall (Cygwin)"  writes:


[snipped 8 lines]

 montage: unable to read font
 `/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
   

[snipped 10 lines]

>
> You haven't mentioned yet whether this file exists and is accessible.

There's no such file in my installation.  Should it be there?

http://cygwin.com/cgi-bin2/package-grep.cgi?grep=arial.ttf didn't give
any package either.

And this is how I run the program. 

#merge the images together
montage `ls $OUTDIR/${base_filename}*.png`  -geometry 100x100% -frame \
5 -tile 2x3 $OUTDIR/${base_filename}_merged.png

I'm not sure why it should be asking for the font then.

 sivaram
 -- 


--
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: subversion-1.6.11-1 failure

[Greg Chicares]

[Reformatted--please see:
  http://cygwin.com/acronyms/#PCYMTWLL
Thanks.]

On 2010-04-24 06:17Z, Brad Bell wrote:
[...]
> P.S.
> I would have liked to make this message a reply to
>http://cygwin.com/ml/cygwin/2010-04/msg00892.html
> but I do not have an e-mail copy of that message and hence do not
> know how to do that. Is there a way ?

On the page you cited, click the "Other format: [Raw text]" link.
At the top, you'll see:

  From cygwin-return-162155-listarch-cygwin= ...

so send an empty email to
  cygwin-get.162...@plug_in_the_right_domain.com
and reply to the message you receive; threading will be preserved.
(This is explained in the "WELCOME" message you receive when you
first subscribe.)

--
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: subversion-1.6.11-1 failure

[Christopher Faylor]

On Sat, Apr 24, 2010 at 12:51:14PM +, Greg Chicares wrote:
>[Reformatted--please see:
>  http://cygwin.com/acronyms/#PCYMTWLL
>Thanks.]
>
>On 2010-04-24 06:17Z, Brad Bell wrote:
>[...]
>> P.S.
>> I would have liked to make this message a reply to
>>http://cygwin.com/ml/cygwin/2010-04/msg00892.html
>> but I do not have an e-mail copy of that message and hence do not
>> know how to do that. Is there a way ?
>
>On the page you cited, click the "Other format: [Raw text]" link.
>At the top, you'll see:
>
>  From cygwin-return-162155-listarch-cygwin= ...
>
>so send an empty email to
>  cygwin-get.162...@plug_in_the_right_domain.com
>and reply to the message you receive; threading will be preserved.
>(This is explained in the "WELCOME" message you receive when you
>first subscribe.)

Actually this is a canned message and it isn't accurate.  This mechanism
is not guaranteed to work reliably.

cgf

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

autoupdate script

[Rance Hall]

Thanks to comments from many on this list I've been working (slowly)
on a autoupdate script for cygwin.

I decided on three separate parts.

1) check setup version
2) check packages to be updated
3) update

My plan was to create a windows batch file that checked if a setup.exe
update was needed and to perform that function.
call a cygwin bash script to check packages and see if an update was
required, and actually run the update with the right command options.



steps 2 and 3 seem to work fine.  but checking the setup version
doesn't seem to be that easy.


a quick check of setup.exe --help does not show a -v option that would
output a version string that I could use in a string compare or other
test.

Seems the only way to check is to have a cygwin bash script wget the
setup from the web and checksum the temp copy and the standard copy to
see if they are the same, if not, replace.

Would it be possible to at a "-v" option to setup to display the
version number for use in scripts?

Is there a better way to check if setup is current prior to update
than what I have.


also setup --help seems to generate some errors on my windows 7 64bit host:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\rance>c:\cygwin\setup --help

C:\Users\rance>Starting cygwin install, version 2.697
io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or dir
ectory
io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or dir
ectory
io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or director
y
io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such fi
le or directory
Current Directory: C:\cygwin

Command Line Options:



Ending cygwin install
AddAccessAllowedAce(, owner) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, everyone) failed: 1337
AddAccessAllowedAce(, owner) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, everyone) failed: 1337


What do these error blocks indicate, and should I worry?


Thanks,


Rance

--
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: zsh 4.3.9-1: text-mode stdin problem (breaking base64)

[Yutaka Amanai]

2010/04/24 10:03 Peter A. Castro wrote:

Could you give me a simple test case that fails without
cygwin_premain0()? I set my filesystems as text-mode and tried to find
such cases, but I couldn't.


It's been a while since I've looked at this, but the problem was mostly
with binary-mode mounts, not text-mode mounts. The problem was that,
say, you had your root mounted as text-mode, but your /tmp mounted as
binary-mode. Zsh (and other utilities) create temp files fairly often
and feed those as input to itself or other programs. Or, reverse the
case (root mounted binary and /tmp mounted text).

{f}open() in Cygwin is context sensitive to the filesystem mount mode.
This leads to such situations as calling fopen("/tmp/foo","r") and
expecting it to read "text" lines, but "/tmp" is mounted binary and file
"foo" contains CRLF's because it was created by a Windows program or
editor. So, when you read the lines you will get the CR as well as the
LF, when you really only want the LF. Where as if "/tmp" was mounted
text, the CR would be stripped off as part of text processing.
Thank you. Indeed, even if a person mounts root (or some filesystems) as 
text-mode, still he might mount /tmp as binary-mode. So, I see that we 
need to take measures to meet such cases.



I thought about two cases:
* If you don't use CRLF scripts at all and mount all your filesystems as
binary-mode, there should be no problem (without premain hack).


In a pure Cygwin eco-system that might work. However, many Cygwin users
have to interact with non-Cygwin created data and files. If you ask the
good users on this mailing list you might find that people have any
combination of file systems mounted for their particluar needs.


* If you use CRLF scripts and mount all your filesystem as text-mode,
there should be no problem (without premain hack).


But, now, you won't get binary data from the files using a naked "open()"
as so many typically coded apps do.


Is it right?


If you could keep things strictly black-and-white like that, yes, in
theory these could work. Well, the first one would be preferable as
opposed to the second one. But the problem is that most Cygwin users
don't operate in such a strict environment.
I might have been shortsighted. Especially, I didn't consider so much 
about using text-mode and binary-mode simultaneously.



I don't know well about zsh code, but I think it will be hard to do the
hack without cygwin_premain0(), as you said. But, how about bash? bash
seems not to have such hacks, but it seems to work well. And I think
it's confusing that bash and zsh treat stdin as different mode.


Have a look at Bash code some time. I recall seeing some O_TEXT options
being set in the various {f}open()'s that it does. Again, I looked at
doing the same in Zsh code, but after some initial experiments it proved
that there were too many dependencies and assumptions about the
carriage-control of "text" files to make it work quickly.
I took a look at Bash code and found it sometimes opens filehandles in 
text-mode, although I didn't read in detail. Anyway, Bash is also 
apparently not perfect (for example, it can't read CRLF scripts on 
binary-mode filesystems), so I see that we can't say which is right.



Indeed, it's theoretically right that any programs which perform binary
I/O should set stdin/stdout as binary mode for portability. But
practically, it will be a heavy work to check that all programs on our
system follow the rule, and I think the check can't be perfect. I'd


Reguardless of how much work it might be, it's a matter of "due
diligence". When you find something that doesn't behave appropriately,
report it to the maintainers.

And, in that vein, yes, I acknowledge there are issues with Zsh in this
area. The premain is one "solution" that works for most cases. You
appear to have found one case that doesn't work as expected
(congratulations!). But, as I said, that particular case appears to be
more a matter of that the Stdin handle should be treated as and work
appropriately.

This problem is still under consideration. Having more than one type of
filesystem mode is part of the equasion and attempting to treat that
correctly is somewhat difficult in Zsh.
Yes, this seems not so simple problem as I thought. For the present, if 
I find a problem like Base64 again, I will report it.



rather keep all my scripts as LF than break my data by some programs
like base64, so I will continue to use the customized zsh.


If that works for you, great. That's why the source is available.
I do hope to get back to this issue at some point.
Thanks for pointing it out.
My pleasure. I understood that we need premain hack for now in the 
package for public. Thank you for considering about my post. And I 
appreciate you for maintaining Cygwin Zsh package.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://c

Re: Using nano in mintty : missing cursor

[Andy Koppe]

fergus wrote:
> Try editing a text document using nano in a mintty terminal.
> Press  to replace text.
> The typed search string at the bottom of the page lacks a visible cursor
> (though it is there, as evidenced by use of  and  and
> inserting text) which is a small inconvenience.

Fixed on svn trunk, which will eventually become mintty-0.7. (svn
checkout http://mintty.googlecode.com/svn/trunk)

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

renameutils fails to build, error linking libintl?

[d . sastre . medina]

Hello,

I'm trying to build renameutils[1], some tools for easy renaming
of files; it builds OOTB without nls support, but if I try to 
enable it, I crash against this:

(gettext and libintl's stuff while configuring)
...
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
...
checking for GNU gettext in libc... no
...
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl
...

(errors while compiling)
...
gcc -std=gnu99 -Wall -g -O2   -o qcmd.exe  apply.o display.o edit.o
list.o interactive.o plan.o qcmd.o quote.o variables.o
editformats/lib_editformats.a common/lib_common.a ../lib/libgnu.a
-lreadline
apply.o: In function `apply_plan':
/usr/local/packages/release/renameutils/renameutils-0.10.0/src/apply.c:110:
undefined reference to `_libintl_gettext'
...
list.o: In function `list_command':
/usr/local/packages/release/renameutils/renameutils-0.10.0/src/list.c:202:
undefined reference to `_libintl_ngettext'
...
qcmd.o: In function `main':
/usr/local/packages/release/renameutils/renameutils-0.10.0/src/qcmd.c:159:
undefined reference to `_libintl_bindtextdomain'
/usr/local/packages/release/renameutils/renameutils-0.10.0/src/qcmd.c:161:
undefined reference to `_libintl_textdomain'
...

However, those symbols exist in:

$ nm /usr/lib/libintl.a
...
0380 T _libintl_bind_textdomain_codeset
0360 T _libintl_bindtextdomain
 T _libintl_gettext
 T _libintl_textdomain
 T _libintl_ngettext
...

$ cygcheck -c gettext libintl8
Cygwin Package Information
Package  VersionStatus
gettext  0.17-11OK
libintl8 0.17-11OK

Somebody has a hint about this?

Thanks and regards.

[1]http://www.nongnu.org/renameutils/

-- 
Huella de clave primaria: 0FDA C36F F110 54F4 D42B  D0EB 617D 396C 448B 31EB


pgpxDxWm7fC0o.pgp
Description: PGP signature

Re: renameutils fails to build, error linking libintl?

[Dave Korn]

On 24/04/2010 23:53, d.sastre.medina wrote:

> checking where the gettext function comes from... external libintl
> checking how to link with libintl... -lintl
> ...
> 
> (errors while compiling)
> ...
> gcc -std=gnu99 -Wall -g -O2   -o qcmd.exe  apply.o display.o edit.o
> list.o interactive.o plan.o qcmd.o quote.o variables.o
> editformats/lib_editformats.a common/lib_common.a ../lib/libgnu.a
> -lreadline
> apply.o: In function `apply_plan':
> /usr/local/packages/release/renameutils/renameutils-0.10.0/src/apply.c:110:
> undefined reference to `_libintl_gettext'

> However, those symbols exist in:
> 
> $ nm /usr/lib/libintl.a

  Yes, but for some reason the -lintl never made it through to the command
line it ended up using above.  You'll need to look into the makefile and
configure script to try and figure out how it got lost.  Or if you just want
to get the build completed, cut and paste that line and add -lintl manually.

  It's also possible, but less likely, that among those "(errors while
compiling)" is something which explains the disappearance.


cheers,
  DaveK


--
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/readline spinout in vi command mode (fix identified)

[ERIC HO]

I downloaded the readline source and reviewed the looping rountines identified. 
It seems that the loop heappens when it is a null command line. If the command 
line contains some characters, the loop does not happen. I'm not a  expert in C 
so I reported to the readline maintainer who responded with the following very 
quickly (thanks Chet!):

**
Thanks for the report.

I'm surprised it does anything at all, and I'm not surprised that it loops.
That should return immediately without doing anything, since there is no
previous search to repeat.

You end up searching in an undefined direction (dir == 0) for an empty
string, and basically stop if the empty string happens to match at the
end of the line (_rl_char_search_internal defaults, by chance, to searching
forward).  The bounds checks will fail, since they include checks for
`dir' which only test the defined range of values.  The contents of
_rl_vi_last_search_mbchar could also be random on cygwin, though the
_rl_vi_last_search_mblen should always be 0, so that should not matter.

Anyway, the right fix is to check to make sure `dir' is in the defined
range.  I suppose I could check for searching for NULL also.

**
I'm just about giving up resolving this issue.
Thanks for those who spent time helping on this issue.

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

Re: Cygwin slow on x64 systems

[StephenBartlett]

Same problem here. Has anyone figured out what it is yet ?


Vincent Richomme-2 wrote:
> 
> On Sat, 23 Jan 2010 11:19:36 -0600, David Morgan 
> wrote:
>> Hello all,
>> 
>>  We use cygwin for our build environment, and have observed that 
>> everything runs extremely slow on x64 systems, for versions newer than
>> approximately 1.5.12 (including 1.7.1).  
> ... 
> 
> Hope you will find something because I already have reported this but with
> no success.
> My QuadCore 3.GHz with 4GB feels like an old 386 when running cygwin on
> Windows 7 64 bits!
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Cygwin-slow-on-x64-systems-tp27288031p28354068.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

can get 'net use' to give remote share a drive letter when logged in directly but not from ssh session

[JJ Ottusch]

I have a Cygwin ssh server (OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007) running
on a Windows 2003 server (lets call it 'xxx'). I am able to use ssh on a remote
machine to reliably make a connection to my account on the server.

I have recently discovered that once I have remotely connected to the server I
can also gain access to a shared resource (let's call it '//yyy/zzz') by using
'net use'. This is great. I had previously assumed this to be impossible.

For example, if I open an RXVTerm running Cygwin on my remote machine, ssh to
'xxx', and run the following command

  net use yyy\\zzz /user:ddd\\uuu pw

where 'ddd' and 'uuu' represent the domain name and user name for my account on
'xxx' and 'pw' is my password, then I can 'cd' to '//yyy/zzz', access files
there, etc.

However, now that I can access '//yyy/zzz' from the ssh session, I would also
like to give it a drive letter so I can access it using '/cygdrive/z'. Normally
one would map '//yyy/zzz' to 'Z:' like this

  net use Z: yyy\\zzz /user:ddd\\uuu pw

This works if I make a Remote Desktop Connection to 'xxx', open an RXVTerm
running Cygwin there, and run this command. But from a remote ssh connection it
doesn't. I get this instead

  System error 85 has occurred.
  The local device name is already in use.

In fact, the local device name is not in use. Same result no matter which letter
I try. Replacing a specific letter by '*' doesn't work either.

Bottom line: I can use 'net use' to connect to a remote resource and associate
it with a drive letter when I log directly onto my domain account on 'xxx', but
not when I connect to 'xxx' via ssh.

Is there a way around this problem?

I'm not sure if this is relevant, but as a domain account user logged directly
onto 'xxx' I have Administrative privileges, whereas when I use ssh to connect
to 'xxx' I can access the same resources, but I'm not sure what my privilege
level is. I know that I am somehow going through the 'sshd_server' local user
account on the server, which only has User-level privileges.

jjo


--
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: ImageMagick shared libraries missing?

[Larry Hall (Cygwin)]

On 4/24/2010 6:44 AM, Sivaram Neelakantan wrote:

"Larry Hall (Cygwin)"  writes:


  We discourage feeding the
spammers around here.

<



[snipped 8 lines]


montage: unable to read font
`/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
   


[snipped 10 lines]



You haven't mentioned yet whether this file exists and is accessible.


There's no such file in my installation.  Should it be there?


This appears to be a bug with ImageMagick.  Last time it came up on this
list, there was a suggested workaround:



You may also want to do some research into this bug for ImageMagick
upstream.  There appears to be some related talk about things like this,
though I didn't dig into it myself.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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