On Jul 1, 2016, at 4:40 PM, Warren Young wrote:
>
> I’ve written a script to do that automatically.
I’ve improved the script so that it no longer requires any parameters. It
finds the last-used setup.ini file and extracts the list of currently-installed
packages, all on its own.
Thus, calling
On Jul 1, 2016, at 4:12 PM, KARL BOTTS wrote:
>
> I use Cygwin32 on Windows-64.
Then you’re artificially making rebase’s job harder.
The list of 32-bit-only Cygwin packages is tiny these days, and you’ve just
rebuilt your Cygwin environment. With my new find-cyg-roots script, you could
rebui
On Jul 1, 2016, at 1:35 PM, Warren Young wrote:
>
> To clone an existing install using setup.exe:
>
> $ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \
>-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,)
[snip]
> ...you can prune the long list produced by that $() construct way do
> A VS installation shouldn’t affect the rebase setup of Cygwin.
I'm with you. But it did. I am not blaming Cygwin; I am a friend of Cygwin.
>> Eventually, I reinstalled a fresh cygwin
> Did you install all the same things, or a minimal install,
Most of the same packages, but a from-scratch
On Jul 1, 2016, at 2:52 PM, Hans-Bernhard Bröker wrote:
>
> Am 01.07.2016 um 20:36 schrieb Warren Young:
>
>> That means you have the DocBook tools installed but don’t have the
>> DocBook XSL stylesheets installed
>
> only docbox2x-texi is checked for by winsup/doc/configure.ac.
You’re in a fin
I don't know how this happened, and it was probably self-inflicted, but
one of the home directories in a new cygwin install has wound up owned
by Unknown+User and Unknown+Group, with permissions 750.
Opening the cygwin window "As Administrator" will not allow me to remove
the directory or chan
On July 1, 2016 Corinna Vinschen wrote:
On Jun 30 20:38, Kaz Kylheku wrote:
> I tracked this down to the fhandler_console::need_invisible() call in
> child_info_spawn::worker().
>
> Whatever that is supposed to do is not working properly because
> the invisible window is perfectly visible.
Try s
Am 01.07.2016 um 20:36 schrieb Warren Young:
That means you have the DocBook tools installed but don’t have the
DocBook XSL stylesheets installed, so it has to fetch them over the
Internet. Those Internet servers are heavily overloaded because of
all the *other* users with the same system misco
Cygwin seems to look up a symlink wrong:
When the target-file is unlinked while it is used by a process the file
still exists and the symlink should point to that file.
Test:
ln -s out1 lout1
exec >lout1
rm out1
[[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
rm lout1
Only on cygwin
On Jun 29, 2016, at 6:24 AM, KARL BOTTS wrote:
>
> A couple of weeks ago I installed Visual Studio 2015...It is a huge install
> -- 20GB disk space, more than an hour, a couple of reboots.
In a world where main storage is measured in 100s of MB per second, installing
20 gigs should not take ho
On Jun 30, 2016, at 11:19 AM, Kaz Kylheku wrote:
>
> It sat for a long time in "book set list ..." with the CPU idle.
That means you have the DocBook tools installed but don’t have the DocBook XSL
stylesheets installed, so it has to fetch them over the Internet. Those
Internet servers are hea
Hi Viacheslav,
On Jul 1 23:38, Бабенко Вячеслав wrote:
> Dear friends!
>
> The function ioctl return -1 (errno equal 95) if I use cygwin-x86_64 but
> return 0 if I use cygwin-x86.
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int c;
> int fd = sock
Dear friends!
The function ioctl return -1 (errno equal 95) if I use cygwin-x86_64 but return
0 if I use cygwin-x86.
#include
#include
#include
#include
#include
int main()
{
int c;
int fd = socket(AF_INET, SOCK_STREAM, 0);
if (ioctl(fd, FIONREAD, &c) == -1)
printf("err
Andrey Repin writes:
> Greetings, Henry S. Thompson!
>
>> Good news: My cygwin file tree survived a Windows (10) reinstall
>> Not-so-good news: I have a new SID, so not only do I not own those files
>> any more (that's easily fixed), but I don't have the permissions I
>> should, because they are n
Thanx to the responders to this issue. My problem, it turns out,
is due to my having set up Windows environment variable "HOME",
which conflicted with my Cygwin HOME. Apparently my Windows HOME
overrode my Cygwin HOME; deleting the Windows HOME allowed chere
to see my Cygwin HOME, and all is now
On Jun 30 20:38, Kaz Kylheku wrote:
> On 29.06.2016 15:28, Kaz Kylheku wrote:
> > Hi all,
> >
> > I've encountered a strange behavior. When a Cygwin C application that is
> > compiled with "-mwindows" tries to spawn another program, that
> > application
> > suddenly gets a console window!
>
> I t
--
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
Greetings, Fergus Daly!
> So far sed is the only operation where extreme sloth is exhibited. A
> favoured benchtest using a long computation within Cygwin has not suddenly
> slowed down, and remains consistent +/- 1 second within and between
> machines. More detective work required, I guess. And
Hi David,
On Jun 30 23:27, David Macek wrote:
> On 29. 6. 2016 23:45, David Macek wrote:
> > I can try watching them side by side in debuggers tomorrow, maybe I'll find
> > something.
>
> Yep, found something. TL;DR the issue is that Windows spins a thread
> in the process before our DLLs are lo
>> $ find archive -type f | wc
87 871698
>> $ time find archive -type f | xargs sed -i 's/string1/string2/g'
real1m2.587s
user0m1.200s
sys 0m12.884s
>> More than a minute for 90 files is just extraordinary.
>> Anybody else having a similar experience?
> $
On 13 June 2016 at 01:35, Ken Brown wrote:
> On 6/12/2016 7:26 PM, Mark McGregor wrote:
>>
>> Ken wrote:
>>>
>>> I obtained the output in the attachment, which looks good. Are you saying
>>> that the message is bogus and no action is needed?
>>
>>
>> Yes.
>>
>>
>> Ok, thanks! It is nice t
21 matches
Mail list logo
