Le 28/10/2010 20:11, jean-luc malet a écrit :
>
> HI
> cygwin 1.7.7(0.230/5/3)
>
[snip don't know about bitk]
>
> in another program I spawn a ssh.exe with stderr, stdin, stdout
> redirected to pipes, and for some strange reason the 'Password:'
> string is still displayed on the terminal and is
Hello!
Using cygwin 1.7.7, tclsh84 does not pass its environment to a sub-process
created with exec command.
Test case:
# Starting from cygwin bash command line,
# record your current environment
$ env | sort > env0.txt
# Start tclsh84
$ tclsh84
# Execute the same command from tclsh84, exit
On 10/29/2010 6:16 PM, Eric Blake wrote:
On 10/29/2010 04:11 PM, Ken Brown wrote:
Thanks, Eric. I didn't know about any of this. (I was using a modification of
a configure test from the emacs sources.)
Probably worth pointing it out to the emacs upstream, then :)
But I get the same beh
Giorgos Tzampanakis sent the following at Friday, October 29, 2010 12:27 PM
>I created a database by running updatedb, and then i re-ran updatedb
>and it took roughly the same amount of time. After a short discussion
>in #linux at freenode, I think that this is because the cygwin updatedb
>does not
On 10/29/2010 04:11 PM, Ken Brown wrote:
>
> Thanks, Eric. I didn't know about any of this. (I was using a modification
> of a configure test from the emacs sources.)
Probably worth pointing it out to the emacs upstream, then :)
> But I get the same behavior with the following revised test c
On 10/29/2010 5:58 PM, Eric Blake wrote:
> On 10/29/2010 03:54 PM, Eric Blake wrote:
>> On 10/29/2010 03:44 PM, Ken Brown wrote:
>>> While trying to debug a timezone problem in the Cygwin build of emacs, I've
>>> come across a difference between Cygwin and Linux in the behavior of
>>> localtime w
On 10/29/2010 03:54 PM, Eric Blake wrote:
> On 10/29/2010 03:44 PM, Ken Brown wrote:
>> While trying to debug a timezone problem in the Cygwin build of emacs, I've
>> come across a difference between Cygwin and Linux in the behavior of
>> localtime with respect to TZ. Suppose I set TZ, call loca
Dear Ken --
You've described a *difference*, but it's not
clear to me that it's a *bug*. Some run-time
libraries cache values and some don't ...
Now if the Posix spec says it *must* act a
particular way and cygwin has it wrong, that's
a bit of a different story
Regards -- Eliot Moss
--
P
On 10/29/2010 03:44 PM, Ken Brown wrote:
> While trying to debug a timezone problem in the Cygwin build of emacs, I've
> come across a difference between Cygwin and Linux in the behavior of
> localtime with respect to TZ. Suppose I set TZ, call localtime, unset TZ,
> and call localtime again.
While trying to debug a timezone problem in the Cygwin build of emacs, I've
come across a difference between Cygwin and Linux in the behavior of localtime
with respect to TZ. Suppose I set TZ, call localtime, unset TZ, and call
localtime again. On Cygwin, the second call to localtime re-uses t
On 10/29/2010 9:21 AM, Tim Prince wrote:
> If your files are on a server, of course, you need synchronization
> between the server and local system clocks, at least daily.
Thanks for the suggestion, but no, they're not.
--
rmd
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 10/29/2010 3:24 AM, Oleksandr Gavenko wrote:
> > Sleeping helps, but you have to sleep for quite a while; even 2 seconds
> > may not be enough:
> do you build on FAT fs?
> It knows by lesser time precision (exactly 2 sec).
Interesting. But I'm building on NTFS.
c: hd NTFS946841Mb
"Larry Hall (Cygwin)" writes:
> On 10/29/2010 9:55 AM, J. David Boyd wrote:
>>
>> And I'll attach a run of cygcheck -k. Run in a plain bash window.
>>
>> I pressed the left arrow key, the right arrow key, the up arrow key, the
>> down arrow key, and q to quit.
>>
>> Note that the left and right
--- Ven 29/10/10, Simone chemelli ha scritto:
> I read a lot all over and cannot find
> a way to fix it:
>
> $ while (true); do date; done | uniq -c
> 7 Fri Oct 29 17:20:20 WEDT 2010
> 8 Fri Oct 29 17:20:21 WEDT 2010
> 7 Fri Oct 29 17:20:22 WEDT 2010
> 8 Fri Oct 29 17:20:
I read a lot all over and cannot find a way to fix it:
$ while (true); do date; done | uniq -c
7 Fri Oct 29 17:20:20 WEDT 2010
8 Fri Oct 29 17:20:21 WEDT 2010
7 Fri Oct 29 17:20:22 WEDT 2010
8 Fri Oct 29 17:20:23 WEDT 2010
8 Fri Oct 29 17:20:24 WEDT 2010
7 Fri O
On 10/29/2010 9:55 AM, J. David Boyd wrote:
And I'll attach a run of cygcheck -k. Run in a plain bash window.
I pressed the left arrow key, the right arrow key, the up arrow key, the
down arrow key, and q to quit.
Note that the left and right arrow keys do show they are pressed but
just once.
And I'll attach a run of cygcheck -k. Run in a plain bash window.
I pressed the left arrow key, the right arrow key, the up arrow key, the
down arrow key, and q to quit.
Note that the left and right arrow keys do show they are pressed but
just once. The other keys show key pressed, and key re
I must have done something wrong on the prior message, as my
cygcheck.out was there, but no text. Do I need to put something
between the two?
Anyway, what I am asking is that in my install of the newest cygwin, my
left and right arrow keys don't work.
Dave
--
Problem reports: http://c
On 10/29/2010 12:24 AM, Oleksandr Gavenko wrote:
On 28.10.2010 20:10, Robert McDougall wrote:
In running Make, I find targets being remade that shouldn't have to be
remade; being considered younger than the prerequisites from which
they've just been made. It seems to happen especially with
prer
> On 10/28/2010 10:37 PM, Brian Wilson wrote:
> > The ssh command and its response are just a cut and paste of the bash
screen.
> > Trying to execute ssh -v ncc-1701 gives exactly the same results (note
there
> > is no -v option in the displayed list).
>
> $ ssh wil...@ncc-1701
> usage: ssh [-
On Thu, Oct 28, 2010 at 11:02 PM, Larry Hall (Cygwin)
wrote:
> On 10/28/2010 10:37 PM, Brian Wilson wrote:
>>
>> The ssh command and its response are just a cut and paste of the bash
>> screen.
>> Trying to execute ssh -v ncc-1701 gives exactly the same results (note
>> there
>> is no -v option in
--- Ven 29/10/10, Matteo Cortese ha scritto:
> I've not seen any follow up on this issue for some time,
> and in fact I've just experienced a failure of bash's
> postinstall script fails due to the strange way DEVDIR is
> built.
Matteo,
I don't understand. The bash postinstall script have
nor D
On Thu, 30 Jul 2009, Eric said
>>> DEVDIR="$(cygpath -au "C:/$(cygpath -am /dev/)" | sed 's|/c/\(.\):/|/\1/|')"
>>> mkdir -p "$DEVDIR" || result=1
>>
>> Hmm, this looks kind of fragile. Not to say it looks wrong.
>
> I didn't invent this, but borrowed the idea from the old mkdev script
> (did I
On 28.10.2010 20:10, Robert McDougall wrote:
In running Make, I find targets being remade that shouldn't have to be
remade; being considered younger than the prerequisites from which
they've just been made. It seems to happen especially with
prerequisites created by `touch`: e.g.:
$ cat M
24 matches
Mail list logo
