Re: Failure sending an email to cygwin@cygwin.com

[Gregg Levine]

On Fri, Jul 20, 2012 at 4:43 PM, SPC <> wrote:
>
>
> --
> 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
>

Hello!
Was it deliberate to present it to the list? Please refrain from doing
that in the future.


-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."

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

RAID devices not listed under /dev

[Aaron Schneider]

The tested computer has SSD dual (RAID 0), 2x64GB, partition type is MBR.

Fedora-17-x86_64-Live-Desktop shows the following devices:

(parted) print devices
/dev/sda (64.0GB)
/dev/sdb (64.0GB)
/dev/mapper/live-osimg-min (4295MB)
/dev/mapper/live-rw (4295MB)
/dev/sr0 (676MB)
/dev/md126 (128GB)
(parted) quit

/dev/md126 is the virtual c: drive presented to Windows.
The list of device's partition table:

---

[root@localhost liveuser]# parted -l
Error: Can't have a partition outside the disk!
Model: ATA TOSHIBA THNSNC06 (scsi)
Disk /dev/sda: 64.0GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Error: /dev/sdb: unrecognised disk label
Model: ATA TOSHIBA THNSNC06 (scsi)
Disk /dev/sdb: 64.0GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Model: Linux device-mapper (snapshot) (dm)
Disk /dev/mapper/live-osimg-min: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End SizeFile system  Flags
 1  0.00B  4295MB  4295MB  ext4

Model: Linux device-mapper (snapshot) (dm)
Disk /dev/mapper/live-rw: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End SizeFile system  Flags
 1  0.00B  4295MB  4295MB  ext4

Error: The partition's data region doesn't occupy the entire partition.
Ignore/Cancel? I
Error: Can't have overlapping partitions.
Model: MATSHITA DVD-RAM UJ892AS (scsi)
Disk /dev/sr0: 676MB
Sector size (logical/physical): 2048B/2048B
Partition Table: unknown
Disk Flags:

Model: Linux Software RAID Array (md)
Disk /dev/md126: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End SizeType File system  Flags
 1  1049kB  8450MB  8449MB  primary  ntfs diag
 2  8450MB  8555MB  105MB   primary  ntfs boot
 3  8555MB  128GB   119GB   primary  ntfs
---

--
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: Cannot Execute urxvt after upgrade

[Thomas Wolff]

Am 20.07.2012 14:12, schrieb K Stahl:

One word: mintty.

Although I appreciate the work and the robust nature of mintty, it
does not integrate into the window manager I am using.
Maybe if you describe how and why it does not integrate, a solution 
could be found for that?


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

ssh connection to localhost "closed by remote host" after recent updates

[Mirko Vukovic]

Hello,

This morning I updated cygwin.  At the same time, my Windows 7 (64bit)
was also updated.  Now I cannot ssh to my system.

I re-ran ssh-host-config and ssh-user-config.  I re-ran rebaseall with
default parameters (no -b 0x7...).

I can ssh to other systems.  But I cannot ssh to localhost

But the following fails:
>ssh -vv 977315@localhost
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/977315/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/977315/.ssh/id_rsa type 1
debug1: identity file /home/977315/.ssh/id_rsa-cert type -1
debug1: identity file /home/977315/.ssh/id_dsa type 2
debug1: identity file /home/977315/.ssh/id_dsa-cert type -1
debug1: identity file /home/977315/.ssh/id_ecdsa type 3
debug1: identity file /home/977315/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host


The contents of /var/log/sshd are:


  1 [main] sshd 2432 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x80) != child(0x48)
  0 [main] sshd 3680 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x80) != child(0x8C)
  1 [main] sshd 5296 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x5B) != child(0x5E)
  1 [main] sshd 848 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x5B) != child(0x61)
  1 [main] sshd 2576 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x5B) != child(0x64)
  1 [main] sshd 3660 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x5B) != child(0x80)
  1 [main] sshd 3836 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x63) != child(0x5A)
  1 [main] sshd 5628 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x63) != child(0x48)
  0 [main] sshd 5500 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x63) != child(0x5D)
  0 [main] sshd 5952 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x63) != child(0x48)
  1 [main] sshd 3884 child_info_fork::abort:
C:\cygwin\bin\cygcrypto-1.0.0.dll: Loaded to different address:
parent(0x63) != child(0x65)


Output of cygcheck /bin/cygcrypto-1.0.0.dll
C:\cygwin\bin\cygcrypto-1.0.0.dll
  C:\cygwin\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNELBASE.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\cygwin\bin\cygz.dll
C:\cygwin\bin\cyggcc_s-1.dll


Suggestions?  Criticisms?

Thanks,

Mirko

--
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: FAQ and Documentation translation to other languages

[SPC]

Hi. I'll try (again) to send this reply.

I understand your point about dedication to this project, of course.
And is a matter to discuss to have a correct idea of the whole
dedication needed before take a decision about it .

In the other hand, your proposal about create a side project appears
to be the logical way.

Regards

Sergio

2012/7/20 Corinna Vinschen :
> On Jul 19 22:38, SPC wrote:

> The documentation is written by the developers.  There's no doc team nor
> a translation team, given that we have only a tiny number of contributors
> to the Cygwin package codebase.  If you're interested in providing a
> spanish translation of the docs or the FAQs, we can certainly arrange a
> side project for translations in CVS, and the necessary web space to
> publish them.
>
> If you're interested, we could discuss the howto in the cygwin-apps
> mailing list.
>
> Btw., the same goes for anybody who would like to provide translations
> in any other language, naturally.  I would just like to ask that you
> make sure you mean that seriously and don't drop off right at the next
> stop.

--
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: /usr/sbin directory not included in PATH

[Eric Blake]

On 07/20/2012 02:34 PM, Aaron Schneider wrote:
> Package util-linux installs fdisk.exe in /usr/sbin but that path is not
> added to PATH variable, so can't be run directly,
> 
> $ echo $PATH
> /usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem
> 
> 
> Is this intentional?

Yes.  It matches how Fedora does things (both fdisk being in /usr/sbin,
and that /usr/sbin is not in the default PATH of non-root users unless
the user customizes things).

If you don't like it, then customize your PATH.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org





signature.asc
Description: OpenPGP digital signature

Re: Failure sending an email to cygwin@cygwin.com

[SPC]

global-allow-subscribe-spedraja=gmail@cygwin.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

/usr/sbin directory not included in PATH

[Aaron Schneider]

Package util-linux installs fdisk.exe in /usr/sbin but that path is not 
added to PATH variable, so can't be run directly,


$ echo $PATH
/usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

Is this intentional?

--
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: TeX now vs. Tex in legacy version

[Achim Gratz]

Ken Brown writes:
> There is no latex.exe in the Cygwin distribution.

Sorry if I had been unclear: I had a .exe file where there should have
been a symlink.  I was not trying to imply that Cygwin shipped with it.

> I have no idea why some people are having this problem.  No one
> reporting the problem has sent any information from their setup logs
> that might indicate what went wrong.  They also haven't reported
> whether or not the texlive-collection-* postinstall scripts have run
> successfully.

It's been a while since I had that problem.  As I said, I fixed the
links by hand and then re-created the formats (by looking through the
post-install scripts and then running the appropriate commands).  All
has been well ever since and the update from one TeXlive version to the
next has not been making any problems.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: TeX now vs. Tex in legacy version

[marco atzeri]

On 7/20/2012 10:06 PM, Yaakov (Cygwin/X) wrote:

On 2012-07-20 15:01, marco atzeri wrote:

This is a summary of all `failed' messages:
`xetex -ini  -jobname=xetex -progname=xetex -etex xetex.ini' failed
`xetex -ini  -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed


Do you have texlive-collection-xetex installed?  If not, then this is
harmless (and same goes for other such messages with --all).


Yaakov


xetex missing , I forgot to check

Regards
Marco



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

Re: TeX now vs. Tex in legacy version

[Yaakov (Cygwin/X)]

On 2012-07-20 15:01, marco atzeri wrote:

This is a summary of all `failed' messages:
`xetex -ini  -jobname=xetex -progname=xetex -etex xetex.ini' failed
`xetex -ini  -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed


Do you have texlive-collection-xetex installed?  If not, then this is 
harmless (and same goes for other such messages with --all).



Yaakov


--
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: TeX now vs. Tex in legacy version

[marco atzeri]

On 7/20/2012 9:08 PM, Ken Brown wrote:



I have no idea why some people are having this problem.  No one
reporting the problem has sent any information from their setup logs
that might indicate what went wrong.  They also haven't reported whether
or not the texlive-collection-* postinstall scripts have run successfully.

Ken



some feedback could be red herring.

In my case I had a malfunction of texi2dvi after last
texlive package upgrade.

I had no setup error and all postinstall script were done.

running
 /usr/bin/fmtutil-sys --all

solved the issue.
I guess that an unexpected sequence between postinstall scripts could 
have caused the issue, or eventually a residual .texmf directory on my home.



Other issue, not really important;

"/usr/bin/fmtutil-sys --all" produce these failure  messages

-
fmtutil: Error! Not all formats have been built successfully.
Visit the log files in directory
  /var/lib/texmf/web2c
for details.
###

This is a summary of all `failed' messages:
`xetex -ini  -jobname=xetex -progname=xetex -etex xetex.ini' failed
`xetex -ini  -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed
---

Regards
Marco


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

Re: TeX now vs. Tex in legacy version

[Ken Brown]

On 7/20/2012 2:25 PM, Achim Gratz wrote:

Ken Brown writes:

On 7/20/2012 2:01 AM, Fergus wrote:

1. Currently, having recently upgraded, I can't use latex:
$ latex a8.tex
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Cygwin)
   restricted \write18 enabled.
---! /var/lib/texmf/web2c/pdftex/latex.fmt doesn't match pdftex.pool
(Fatal format file error; I'm stymied)


It looks like something went wrong with your installation of
texlive-collection-latex.  See


This happened to me as well when first upgrading from teTeX to TeXlive.
The error message indicates that a different binary produced the format
file than the binary that is now trying to use it.  When this happens
after upgrading it seems to be related to a symlink not pointing to
where it should (in this case there seems to be a latex.exe file where
there should be a symlink from latex->pdftex.exe).  Since re-installing


There is no latex.exe in the Cygwin distribution.


the whole of TeXlive takes so much time I just re-linked everything and
ran the script that creates the format files.  I think the fact that
some of these links are created from texconfig may be the source of the


The links are not created by texconfig.  For example, the link latex -> 
pdftex.exe is in the installation tarball for texlive-collection-latex. 
 So it should already be in place before any postinstall scripts are run.



problem, maybe you could check if the installation really cleans all
symlinks (and unexpected executables where a symlink should be
installed) before creating the formats.  The executables generally
seem to come from the updated distribution, so I think it may just be an
interaction between some of the postinstall scripts.


I have no idea why some people are having this problem.  No one 
reporting the problem has sent any information from their setup logs 
that might indicate what went wrong.  They also haven't reported whether 
or not the texlive-collection-* postinstall scripts have run successfully.


Ken


--
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: TeX now vs. Tex in legacy version

[Achim Gratz]

Ken Brown writes:
> On 7/20/2012 2:01 AM, Fergus wrote:
>> 1. Currently, having recently upgraded, I can't use latex:
>> $ latex a8.tex
>> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Cygwin)
>>   restricted \write18 enabled.
>> ---! /var/lib/texmf/web2c/pdftex/latex.fmt doesn't match pdftex.pool
>> (Fatal format file error; I'm stymied)
>
> It looks like something went wrong with your installation of
> texlive-collection-latex.  See

This happened to me as well when first upgrading from teTeX to TeXlive.
The error message indicates that a different binary produced the format
file than the binary that is now trying to use it.  When this happens
after upgrading it seems to be related to a symlink not pointing to
where it should (in this case there seems to be a latex.exe file where
there should be a symlink from latex->pdftex.exe).  Since re-installing
the whole of TeXlive takes so much time I just re-linked everything and
ran the script that creates the format files.  I think the fact that
some of these links are created from texconfig may be the source of the
problem, maybe you could check if the installation really cleans all
symlinks (and unexpected executables where a symlink should be
installed) before creating the formats.  The executables generally
seem to come from the updated distribution, so I think it may just be an
interaction between some of the postinstall scripts.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: rebaseall invocation error

[Mirko Vukovic]

On Fri, Jul 20, 2012 at 1:48 PM, Christopher Faylor  wrote:
> On Fri, Jul 20, 2012 at 01:36:07PM -0400, Mirko Vukovic wrote:
>>Problem fixed ... see below
>>
>>On Fri, Jul 20, 2012 at 1:04 PM, Christopher Faylor
>> wrote:
>>> On Fri, Jul 20, 2012 at 01:00:45PM -0400, Mirko Vukovic wrote:
Hello,

I am running rebaseall manually to enable X11:  I found a post
suggesting to rebase to 0x7700

I am following instructions on http://cygwin.wikia.com/wiki/Rebaseall
>>>
>>> You realize that the project web site is: http://cygwin.com/ right?  You
>>> can't expect instructions from unrelated sites to work.  You shouldn't
>>> need to use the above anymore with new improvements to reabase.
>>
>>True.  But I did not find anything else better and the instructions on
>>that site jibed with what I read on the cygwin mailing list over the
>>years.  That's why I went with it.
>
> But this wasn't actually "better".  Just running rebaseall, as suggested
> by the official Cygwin FAQ is the correct advice.
>

I agree

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

--
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: rebaseall invocation error

[Christopher Faylor]

On Fri, Jul 20, 2012 at 01:36:07PM -0400, Mirko Vukovic wrote:
>Problem fixed ... see below
>
>On Fri, Jul 20, 2012 at 1:04 PM, Christopher Faylor
> wrote:
>> On Fri, Jul 20, 2012 at 01:00:45PM -0400, Mirko Vukovic wrote:
>>>Hello,
>>>
>>>I am running rebaseall manually to enable X11:  I found a post
>>>suggesting to rebase to 0x7700
>>>
>>>I am following instructions on http://cygwin.wikia.com/wiki/Rebaseall
>>
>> You realize that the project web site is: http://cygwin.com/ right?  You
>> can't expect instructions from unrelated sites to work.  You shouldn't
>> need to use the above anymore with new improvements to reabase.
>
>True.  But I did not find anything else better and the instructions on
>that site jibed with what I read on the cygwin mailing list over the
>years.  That's why I went with it.

But this wasn't actually "better".  Just running rebaseall, as suggested
by the official Cygwin FAQ is the correct advice.

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

Re: rebaseall invocation error

[Mirko Vukovic]

Problem fixed ... see below

On Fri, Jul 20, 2012 at 1:04 PM, Christopher Faylor
 wrote:
> On Fri, Jul 20, 2012 at 01:00:45PM -0400, Mirko Vukovic wrote:
>>Hello,
>>
>>I am running rebaseall manually to enable X11:  I found a post
>>suggesting to rebase to 0x7700
>>
>>I am following instructions on http://cygwin.wikia.com/wiki/Rebaseall
>
> You realize that the project web site is: http://cygwin.com/ right?  You
> can't expect instructions from unrelated sites to work.  You shouldn't
> need to use the above anymore with new improvements to reabase.

True.  But I did not find anything else better and the instructions on
that site jibed with
what I read on the cygwin mailing list over the years.  That's why I
went with it.

>
>>I restarted Windows 7 (64bit) in safe mode (no networking) and opened
>>a command prompt where I executed:
>>
>>cd \cygwin\bin
>>dash
>>PATH=.
>>rebaseall -v
>>
>>I got the following error:
>>
>>rebaseall: only ash or dash processes are allowed during rebasing
>>Exit all Cygwin processes and stop all Cygwin services.
>>Execute ash (or dash) from Start/Run... or a cmd or command window.
>>Execute '/bin/rebaseall' from ash (or dash).
>>
>>I get the same error from a regular Windows session (with sshd
>>stopped, and no other cygwin processes running - as far as I can see).
>>
>>Are there some other Cygwing processes running?  How can I check for
>>that.  Or is something else amiss?
>
> Task Manager would probably tell you if something else is running.

Against my better judgment I went and looked in Task Manager.  After all I was
certain I did not start any cygwin process.  And in there I found
aspell -- it was
started during Windows Emacs startup.  I use Emacs to write down notes
during debugging.

rebaseall works as advertised.


>
> cgf
>

Mirko

--
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: rebaseall invocation error

[Christopher Faylor]

On Fri, Jul 20, 2012 at 01:00:45PM -0400, Mirko Vukovic wrote:
>Hello,
>
>I am running rebaseall manually to enable X11:  I found a post
>suggesting to rebase to 0x7700
>
>I am following instructions on http://cygwin.wikia.com/wiki/Rebaseall

You realize that the project web site is: http://cygwin.com/ right?  You
can't expect instructions from unrelated sites to work.  You shouldn't
need to use the above anymore with new improvements to reabase.

>I restarted Windows 7 (64bit) in safe mode (no networking) and opened
>a command prompt where I executed:
>
>cd \cygwin\bin
>dash
>PATH=.
>rebaseall -v
>
>I got the following error:
>
>rebaseall: only ash or dash processes are allowed during rebasing
>Exit all Cygwin processes and stop all Cygwin services.
>Execute ash (or dash) from Start/Run... or a cmd or command window.
>Execute '/bin/rebaseall' from ash (or dash).
>
>I get the same error from a regular Windows session (with sshd
>stopped, and no other cygwin processes running - as far as I can see).
>
>Are there some other Cygwing processes running?  How can I check for
>that.  Or is something else amiss?

Task Manager would probably tell you if something else is running.

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

rebaseall invocation error

[Mirko Vukovic]

Hello,

I am running rebaseall manually to enable X11:  I found a post
suggesting to rebase to 0x7700

I am following instructions on http://cygwin.wikia.com/wiki/Rebaseall

I restarted Windows 7 (64bit) in safe mode (no networking) and opened
a command prompt where I executed:

cd \cygwin\bin
dash
PATH=.
rebaseall -v

I got the following error:

rebaseall: only ash or dash processes are allowed during rebasing
Exit all Cygwin processes and stop all Cygwin services.
Execute ash (or dash) from Start/Run... or a cmd or command window.
Execute '/bin/rebaseall' from ash (or dash).

I get the same error from a regular Windows session (with sshd
stopped, and no other cygwin processes running - as far as I can see).

Are there some other Cygwing processes running?  How can I check for
that.  Or is something else amiss?

Thanks,

Mirko

--
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: length in gawk returns wrong value

[Reini Urban]

On Thu, Jul 19, 2012 at 12:02 PM, Eric Blake  wrote:
> On 07/19/2012 10:53 AM, Aaron Schneider wrote:
>> I can't find such csh or cshell on my system, I've searched from
>> packages and I only see scsh, slsh, posh, mosh, tcsh, zsh, mksh that I
>
> Both scsh and tcsh are from the csh family of shells.
>
> posh, zsh, mksh, bash, dash, and ksh are from the Bourne family of shells
>
> No idea what slsh or mosh are

No login shells.

mosh is a a remote shell, a better ssh for slow or varying
connections. http://mosh.mit.edu/

slsh is the S-Lang shell. A different beast.
http://www.jedsoft.org/slang/doc/html/slang-2.html#ss2.1
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

--
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: Cannot Execute urxvt after upgrade

[K Stahl]

For reference, it seems that Charles Wilson ran into the same issues I
am with compiling urxvt under cygwin:
see: http://cygwin.com/ml/cygwin/2006-12/msg00630.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

Re: Cannot Execute urxvt after upgrade

[K Stahl]

> One word: mintty.

Although I appreciate the work and the robust nature of mintty, it
does not integrate into the window manager I am using.

--
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: Internal echo of shell beaves (sometimes) different to external echo

[Ralf]

Andy Koppe  gmail.com> writes:


> 
> It's because setting LC_ALL in a bash script is too late for the bash
> process itself, which will be using the default C.UTF-8 locale unless
> something else is set when bash is invoked.
> 
Now I understand. Setting LC_ALL before calling ttt.sh works:

C:\>set LC_ALL=de_DE
C:\>bash ttt.sh
CYGWIN_NT-6.0-WOW64 WIESWEG 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
Rücken
000   R   ü   c   k   e   n  \r  \n
010
Rücken
000   R   ü   c   k   e   n  \n
007
Rücken
000   R   ü   c   k   e   n  \n
007

Thanks!


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

Re: Internal echo of shell beaves (sometimes) different to external echo

[Andy Koppe]

On 20 July 2012 11:46, Ralf wrote:
> My problem is not that the script is in ISO-8859-1, nor that the strings
> or ttt.txt are in ISO-8859.1. They have to be in ISO-8859-1 because all my
> scripts are in ISO-8859-1 and they are used together with Windows-Programs
> (in the DOS-Box) which read and write only ISO-8851-1.
>
> My Problem is to handle in Shell-Scripts strings which are coded in
> ISO-8851 (and line-endings which depend on relative/absolute filenames,
> mounting and so on) without rewriting all the stuff.
>
> So what't the best setting in cygwin to echo ISO-88591? I still don't
> unterstand why the internal echo behaves in a different way from the external
> echo.

It's because setting LC_ALL in a bash script is too late for the bash
process itself, which will be using the default C.UTF-8 locale unless
something else is set when bash is invoked.

When stuff is written to a console (but not a pty-based terminal), the
Cygwin DLL converts it from the process charset (UTF-8 in this case)
to UTF-16 to pass it to the relevant Windows API function. Your
ISO-8859-1 encoded 'ü' is an invalid byte when interpreted as UTF-8,
hence the error character.

/usr/bin/echo on the other hand is invoked as a separate process, with
LC_ALL already set appropriately, hence they're you're getting the
expected output.

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: Internal echo of shell beaves (sometimes) different to external echo

[Ralf]

My problem is not that the script is in ISO-8859-1, nor that the strings
or ttt.txt are in ISO-8859.1. They have to be in ISO-8859-1 because all my
scripts are in ISO-8859-1 and they are used together with Windows-Programs
(in the DOS-Box) which read and write only ISO-8851-1.

My Problem is to handle in Shell-Scripts strings which are coded in
ISO-8851 (and line-endings which depend on relative/absolute filenames,
mounting and so on) without rewriting all the stuff.

So what't the best setting in cygwin to echo ISO-88591? I still don't
unterstand why the internal echo behaves in a different way from the external
echo.




--
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: TeX now vs. Tex in legacy version

[Ken Brown]

On 7/20/2012 2:01 AM, Fergus wrote:

1. Currently, having recently upgraded, I can't use latex:
$ latex a8.tex
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Cygwin)
  restricted \write18 enabled.
---! /var/lib/texmf/web2c/pdftex/latex.fmt doesn't match pdftex.pool
(Fatal format file error; I'm stymied)


It looks like something went wrong with your installation of 
texlive-collection-latex.  See


  http://cygwin.com/ml/cygwin/2012-07/msg00339.html

Ken


--
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: setup.exe fails on Windows 7 - please help

[Corinna Vinschen]

On Jul 20 08:53, Paul Maier wrote:
> Hi,
> 
> setup.exe brings hundreds of identical popups with error message:
> 
> bash.exe:
> The application could not be started (0xc00d).  *)
> 
> All the .exe files are there in the bin folder, but when I double click on 
> bash.exe or any other .exe,
> I get the same message.
> 
> Only ps.exe works normally.
> 
> Cygwin worked without problem for a year on the same machine.
> 
> I had completely deleted the folder D:\program\cygwin from my drive and 
> started over, but it's the same.
> 
> Thank you for any help!
> 
> Regards,
>   Paul
> 
> 
> *): original German text: Die Anwendung konnte nicht korrekt gestartet werden 
> (0xc00d).

Very weird, 0xC00D is "Invalid parameter".  I would guess that you
have a BLODA problem:

http://cygwin.com/faq/faq.using.html#faq.using.bloda


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

Re: FAQ and Documentation translation to other languages

[Corinna Vinschen]

On Jul 19 22:38, SPC wrote:
> Hello. I'm a Cygwin lists subscriber (with some problems from time to
> time to send mails but this is another story).
> 
> The message about outdated FAQs of yesterday let me think in the
> general lack of translations of Unix-like-items documentation to
> spanish language.
> 
> Exists something traslated under Cygwin to Spanish ? Some kind of team
> doing it ?
> 
> In negative case I could dedicate some time to this project, including
> translations inside source code.

I hope you mean the documentation sources.  I'm not fluent in spanish
and converting my english comments in the Cygwin sources to spanish
would left me a bit puzzled :)

The documentation is written by the developers.  There's no doc team nor
a translation team, given that we have only a tiny number of contributors
to the Cygwin package codebase.  If you're interested in providing a
spanish translation of the docs or the FAQs, we can certainly arrange a
side project for translations in CVS, and the necessary web space to
publish them.

If you're interested, we could discuss the howto in the cygwin-apps
mailing list.

Btw., the same goes for anybody who would like to provide translations
in any other language, naturally.  I would just like to ask that you
make sure you mean that seriously and don't drop off right at the next
stop.


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

Re: Cannot Execute urxvt after upgrade

[Corinna Vinschen]

On Jul 19 16:30, Larry Hall (Cygwin) wrote:
> On 7/19/2012 4:15 PM, Aaron Schneider wrote:
> >On 19/07/2012 22:00, K Stahl wrote:
> >>>urxvt depends on cygperl5_10.dll, which was removed in the upgrade to
> >>>perl 5.14.  Either urxvt needs to be rebuilt, or the old perl 5.10
> >>>libraries need to be restored for a bit longer.
> >>
> >>Knowing that there are numerous dependencies on the perl upgrade,
> >>could we get someone to update the urxvt package?
> >>
> >
> >I couldn't find any version of urxvt on cygwin's release mirror, so, no
> >packages to start from.
> 
> 
> 
> >Furthermore, for what you are looking for, isn't
> >rxvt pretty much the same?
> >
> >http://cygwin.com/ml/cygwin/2009-05/msg00078.html
> 
> Pretty much, minus the unicode support and some other niceties mentioned
> in the message you quoted above.  Of course, stepping back to rxvt puts you
> in the realm of dead code.  So if bit-rot is OK with you... ;-)

One word: mintty.


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

Re: Internal echo of shell beaves (sometimes) different to external echo

[Corinna Vinschen]

On Jul 20 07:08, Ralf wrote:
> Cyrille Lefevre  laposte.net> writes:
> 
> > 
> > Le 19/07/2012 16:51, Ralf a écrit :
> > > Is there a way to get the right umlaut with the internal echo of the 
> > > shell?
> > > Example script:
> > >
> > > export LC_ALL=de_DE
> > 
> > seems to default to iso8859-1 or something like that, let's try
> > 
> > export LC_ALL=de_DE.UTF-8
> > 
> > which should work better...
> > 
> 
> export LC_ALL=de_DE.UTF-8 gives following output:
> 
>  C:\>bash ttt.sh
>  CYGWIN_NT-6.0-WOW64 WIESWEG 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
>  R▒cken
>  000   R 374   c   k   e   n  \r  \n
>  010
>  R▒cken
>  000   R 374   c   k   e   n  \n
>  007
>  R▒cken
>  000   R 374   c   k   e   n  \n
>  007

What you don't seem to see is that the codeset doesn't play any role
anymore *at this point in time*.  You already created the string
"Rücken" in ISO-8859-1 at the time you created the script and your
script will diligently create the file ttt.txt with the word Rücken in
ISO-8859-1, because that's how it's stored in the script.  Thus, it
doesn't matter what codeset you have set when running that script.

Here's an idea for you to test:

Replace

  echo "Rücken" > ttt.txt

with

  read -p "Enter: " foo
  echo "$foo" > ttt.txt

And then start your script with LANG set to, for instance, C.UTF-8, as is
the default when running an interactive Cygwin shell like bash or tcsh.
(though I would prefer to use POSIX paths rather than DOS paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames)


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

Re: Internal echo of shell beaves (sometimes) different to external echo

[Ralf]

Cyrille Lefevre  laposte.net> writes:

> 
> Le 19/07/2012 16:51, Ralf a écrit :
> > Is there a way to get the right umlaut with the internal echo of the shell?
> > Example script:
> >
> > export LC_ALL=de_DE
> 
> seems to default to iso8859-1 or something like that, let's try
> 
> export LC_ALL=de_DE.UTF-8
> 
> which should work better...
> 

export LC_ALL=de_DE.UTF-8 gives following output:

 C:\>bash ttt.sh
 CYGWIN_NT-6.0-WOW64 WIESWEG 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
 R▒cken
 000   R 374   c   k   e   n  \r  \n
 010
 R▒cken
 000   R 374   c   k   e   n  \n
 007
 R▒cken
 000   R 374   c   k   e   n  \n
 007


> also, check your that terminal setting is UTF-8 both for input/output.

How do I check that my terminal setting is UTF-8 both for input/output?
All settings I use are made in inputrc:
 C:\>cat ~/.inputrc
 set meta-flag on
 set convert-meta off
 set output-meta on
And in my environment variables:
 ...
 BASH=/usr/bin/sh
 BASHOPTS=cmdhist:expand_aliases:extquote:force_fignore:hostcomplete:interactive
 _comments:progcomp:promptvars:sourcepath
 BASH_ALIASES=()
 BASH_ARGC=()
 BASH_ARGV=()
 BASH_CMDS=()
 BASH_LINENO=()
 BASH_SOURCE=()
 BASH_VERSINFO=([0]="4" [1]="1" [2]="10" [3]="4" [4]="release" [5]="i686-
 pc-cygwin")
 BASH_VERSION='4.1.10(4)-release'
 ...
 CYGWIN=nodosfilewarning
 ...
 POSIXLY_CORRECT=y
 ...
 SHELL=/bin/bash
 SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-
 comments:monitor:posix
 ...
 TERM=cygwin
 
> 
> tried using fr_FR vs fr_FR.UTF-8 and echo vs /bin/echo, both work well 
> in all case !
> 

Do you use rxvt, mintty or something like that?

Regards
Ralf


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