On 15 Apr, Dyck, David wrote:
> how much control do you have on unix side?
> (you could create a symlink from ici.exe to ici on unix.
True. And I suppose there are only rare programs that would suffer
this problem.
> what about creating a new name for ici.exe and ici that
> could be found o
> Charles Wilson writes:
> Dr. Volker Zell wrote:
>> This is the relevant code block in alternatives.c where the above
>> file gets read by the function readConfig (buf should hold the
>> contents of the above file after the do loop):
>> curBufSz = READCONFIG_BUF_INITIALSZ;
Hi,
Check This Out,
http://si9.org/5
There is never any pressure or obligation. There
is no minimum you have to meet. Take your time
and work at your own pace.
If you want bigger checks it just means you have
to put in more time and effort just like anything else.
Regards,
Sheila Sabbe
http:/
Gregory Rosensteel wrote:
Hello,
I performed a fresh install of cygwin on windows XP. I am seeing
that some commands take a really long time to execute, I was wondering
if anyone else is experience this. For example, the 'which' command
takes 2s while the 'pwd' command runs just fine. Please s
We have the Ici scripting language installed on Windows. Ici expects a
directory called "ici" to exist alongside, where various libraries are
installedd to provide extra functionality.
Unfortunately, under Cygwin, if w try to run the command "ici" we get
the error "ici: command not found", be
Dr. Volker Zell wrote:
This is the relevant code block in alternatives.c where the above file
gets read by the function readConfig (buf should hold the contents of the above file
after the do loop):
curBufSz = READCONFIG_BUF_INITIALSZ;
totalBytesRead = 0;
numBytesRead = 0;
buf
Hugh Sasse wrote:
> Trying to copy a windows XP NTFS drive to a big disk using cygwin tools
> I encounter inaccessible files such as ntusers.dat. tar is not
ntuser.dat is the filename of the per-user registry hive
(HKEY_CURRENT_USER). It is opened by the system in exclusive mode, so
it cannot b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gregory Rosensteel on 4/15/2008 1:46 PM:
| Hello,
| I performed a fresh install of cygwin on windows XP. I am seeing
| that some commands take a really long time to execute, I was wondering
| if anyone else is experience this. For exam
FWIW, a little non-Cygwin (VS2008) test app to display results from
fstat(0,...) returns the same thing on XP and Vista Ent SP1:
0x2000 which means character special, and not regular.
On Tue, Apr 15, 2008 at 3:23 PM, smr <[EMAIL PROTECTED]> wrote:
> I've done some debugging of tail.exe on
I've done some debugging of tail.exe on XP (which works) and Vista
Enterprise SP1 (which doesn't), and so far have found two differences
when tailing output piped from another program:
1. S_ISREG (stats.st_mode) returns 0 on XP, but 1 on Vista (I
haven't yet determined if this is an Enterprise-on
Hugh Sasse wrote:
Trying to copy a windows XP NTFS drive to a big disk using cygwin tools
I encounter inaccessible files such as ntusers.dat. tar is not
particularly verbose about why things fail so I wrote something in
Ruby, but I only got about 70% of the contents of the disk across.
I suspect
Hello,
I performed a fresh install of cygwin on windows XP. I am seeing
that some commands take a really long time to execute, I was wondering
if anyone else is experience this. For example, the 'which' command
takes 2s while the 'pwd' command runs just fine. Please see my sample
output below an
Trying to copy a windows XP NTFS drive to a big disk using cygwin tools
I encounter inaccessible files such as ntusers.dat. tar is not
particularly verbose about why things fail so I wrote something in
Ruby, but I only got about 70% of the contents of the disk across.
I suspect this is a common pr
> Charles Wilson writes:
> I don't know what else to do here. Unless I can reproduce it, I can't
> debug it. The only possibility I can think of is this: are you
> actually using alternatives-1.3.29a-1, or some older version? The
> previous version had a serious bug in a routi
Hello List,
thank you very much for the great efforts you took on to help me solve our
problem ( see the OP below). Finally we managed not to solve the problem
itself but at least to find a workaround. Still we are not able to
identifiy the one of the tree possible parties responsible for the prob
On Apr 14 15:17, Christopher Faylor wrote:
> On Mon, Apr 14, 2008 at 02:55:50PM -0400, Charles Wilson wrote:
> > csih (cygwin-service-installation-helper) provides a library of shell
> > functions that can be used by other cygwin packages that provide servers
> > and daemons. It can assist in var
On Apr 14 21:17, Eric Blake wrote:
> Eric Blake byu.net> writes:
>
> > The cost of stat'ing a known symlink (which may involve spinning up a disk
> > or
> > doing a network access) just to color its target was deemed too expensive
> > for
> > the default. Coreutils 6.11 is due out this week,
If I understand, you're trying to compile wpa_supplicant for use by
windows? That's pretty weird...I'd post to this to the wpa_supplicant
mailing-list/team. They probably can help you better. AFAIK if_arp.h
is part of the linux/bsd kernels only. But, if you're trying to compile
targeting w
18 matches
Mail list logo
