Kevin Layer wrote:
I'm really perplexed by the following behavior:
[EMAIL PROTECTED] ~
$ cat -v foo1.sh
echo 8010 foo1.out
[EMAIL PROTECTED] ~
$ cat -v foo2.sh
sh foo1.sh
version=`cat foo1.out`
echo ${version}.bar foo2.out
cat -v foo2.out
[EMAIL PROTECTED] ~
$ sh foo2.sh
Nicolas Roche wrote:
t=`gcc --print-multi-lib` where gcc is a mingw gcc.
As my gcc is a mingw program, it outputs CR/LFs. In previous versions
bash used to ignore the CR, so t variable was not containing any CR.
Now this is no more the case and this is causing some troubles
Looking back to
Eric Blake wrote:
But I'm not sure whether making
igncr the default in 'bash --posix', aka '/bin/sh', is wise, since
POSIX
does not permit this behavior. My only concern is that by making
igncr
cognizant of whether posix behavior is requested, people will start
asking
'why does my script
Eric Blake wrote:
First, if a script is
specified with a DOS path instead of a POSIX path (although this is
not
the recommended behavior in cygwin), bash will ensure that the
underlying
mount mode is respected, rather than the default cygwin behavior of
using
binary mode, allowing the use of
I really am getting a bad feeling that, rather than FIXING THE
SCRIPTS,
everyone is reverting to using text mode mounts which are not what we
generally recommend.
cgf
As much as I would love to work in a pure cygwin environment it's not
always possible. In our particular case the
IIRC, Cygwin explicitly treats out-of-mount (Win32) paths as binary.
Igor
Yes, that's fits my recollection as well. Since both of us recall
this,
there's no need for anyone to check the source. Two IIRCs means we
must
be right! ;-)
:) That's how my rulebook works too.
So
Apologies that this is being written the day after without real output.
I'm now at my desk without easy access to the machine in question.
But...
We've been using Cygwin with text-mode mounts for a long time without
any problems. A new engineer started the other day, installed a
Apologies that this is being written the day after without real
output.
I'm now at my desk without easy access to the machine in question.
But...
We've been using Cygwin with text-mode mounts for a long time
without
any problems. A new engineer started the other day, installed a
Alexander Gottwald wrote:
Jay Smith wrote:
Hi Alexander,
Yes, I did get crashing from simple cases (i.e. plain text in a basic
KDE
xterm [konsole]). In a couple cases the crash was within a few seconds
and
in other cases I was able to do two or three copy/paste operations
before
it
On June 2 Kris Thielemans wrote:
As I already mentioned, occassionally my mouse pointer does not display
anymore. This then happens for all open and new X-windows.
I believe that this problem has been fixed in the source code but has
not made its way into an official build. If possible grab
After a bit of sleuthing I think I understand why the cursor is
disappearing inside X windows after a remote desktop session.
Unfortunately I don't understand enough of the motive of the current
code in order to suggest a fix.
It appears that there is some sort of misunderstanding between
Jesse Burson wrote:
I'm using XWin.exe 6.7-4
I am not able to cut or copy from Windows apps.
Wait until the next version. Some Windows apps, Remote Desktop for one
really mess up the Windows clipboard chain. You can see this using the
old clipbrd.exe tool as well. Versions of XWin post -4
Harold L Hunt II wrote:
I'm including the small fix from winclipboardwndproc.c in the next
release, but the changes to the debug messages should probably be
done using the newer logging functions that accept a log level and
verb.
I think the small fix got lost. At least I couldn't find
Alexander Gottwald wrote:
- debugging output: winDebug(format, args...)
- non important configuration messages: winErrorFVerb(2, format, args)
-logverbose 3...? can give debug messages with differing severity
eg -logverbose 3 may print simple traces
while -logverbose 10 will also dump all
Symptom: After coming back from remote desktop session first copy
operation might crash XWin when using -clipboard (maybe
requiring -multiwindow too).
Cause: XWin becomes its own next window in the clipboard chain
after trying to ensure that it is still in the
Looks like the newer versions of XWin are having cursor problems when
coming out of remote desktop (XP Pro). After a remote desktop session
the cursor completely disappears in the X window client area.
Here's what I'm seeing:
- Run a cygwin bash shell
- XWin -multiwindow -clipboard
- Run xterm
I've just recently started using Cygwin/X but occasionally paste from Win32
to X fails. I'm using -multiwindow and -clipboard. I tracked down one
source of the failures: XP's remote desktop. Remote desktop does not
properly restore the clipboard chain when it shuts down. Result is that
XWin no
Noob alertHey all/Noob alert
With that out of the way... Last Friday (4/15/04) I updated my Cygwin tools
(longtime user) and installed (for the first time) all the Cygwin/X servers
apps (setup/x11-base 6.7.0.0-7, cygcheck XFree86-xserv 4.3.0-68). I got
up and running over a PuTTY-supplied ssh
18 matches
Mail list logo
