Re: Keyboard issue: unresponsive keystroke
Thanks for the response, Eric, it helped me troubleshoot the issue. Seems I never set my HOME environment variable (sigh), so it all ended up in my Windows home directory. Asserting ~/.inputrc did not have DOS line endings didn't have any effect, but removing the file allowed me to type all chars again (that's a relief). The only thing I had in that custom ~/.inputrc were system beep suppression directives, namely: set bell-style no setterm -blength 0 After setting the HOME variable in my .bat file, I recreated .inputrc in vim and everything is fine again. I suspect permissions in the Windows user directory conflicted with Cygwin's installation. Cheers, Éric On Mon, Aug 30, 2010 at 6:58 PM, Eric Blake ebl...@redhat.com wrote: On 08/30/2010 10:52 AM, Eric Vautier wrote: Hello all, I've used the US-International keyboard layout for ages without issues. Recently, I fired cygwin and noticed the s key was unresponsive. Did you check whether ~/.inputrc has DOS line endings? If so, run d2u on it, and see if that fixes things. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.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
Keyboard issue: unresponsive keystroke
Hello all, I've used the US-International keyboard layout for ages without issues. Recently, I fired cygwin and noticed the s key was unresponsive. Restarting Vista didn't help. Changing to standard US layout before starting Cygwin didn't help. Restarting Cygwin didn't help. Scrapping the Cygwin directory (admittedly not the preferred uninstalling procedure) and re-doing the setup with a fresh setup.exe didn't help. Any pointers would be appreciated. Thanks, Eric -- 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: Design issue with new MS-DOS style path warning?
It may be good advice not to do it. However, there's the case of environment variables, or parameter files containing Windows-style paths used in build.xml, for example. It appears that those variables are not converted sometimes, resulting in failures. One of my build files refers to such a property. I get the DOS file warning at the start of the script, and further down, an error states that C:/cygdrive/c/Users/... couldn't be found. I wonder how Cygwin would come to creating such a hybrid path. Did anyone else run into this? The same script worked perfectly fine before I upgraded to 1.7. -e On Thu, Jan 21, 2010 at 5:59 AM, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 21/01/2010 01:11, Batson, Chuck wrote: That is, how to avoid the warning in a clean way without resorting to the 'nodosfilewarning' option? Say, for example, you create a Windows batch file containing the line: touch C:\foo.txt Well, don't do that then. cheers, DaveK -- 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: Design issue with new MS-DOS style path warning?
On Fri, Jan 22, 2010 at 4:45 PM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Fri, Jan 22, 2010 at 02:17:56PM +0100, Eric Vautier wrote: If you are getting warnings then Cygwin is working as designed. It is telling you that you're doing something that is not guaranteed to work. If you want to turn this off then use the CYGWIN environment variable. I understand that. One of my build files refers to such a property. And the property is? I'll try and investigate the issue further. I get the DOS file warning at the start of the script, and further down, an error states that C:/cygdrive/c/Users/... couldn't be found. I wonder how Cygwin would come to creating such a hybrid path. Did anyone else run into this? The same script worked perfectly fine before I upgraded to 1.7. It is likely that Cygwin didn't. It's much more likely that it is something local to your installation. If it wasn't then the mailing list would be full of complaints. Let me confirm that the script has not changed at all, and used to work fine under the previous version. You'll agree that arriving at a C:/cygdrive/c/... path is a little odd, regardless of setup. Perhaps a string is set that way some place, but I doubt it. -e -- 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: Design issue with new MS-DOS style path warning?
On Fri, Jan 22, 2010 at 6:01 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 22/01/2010 16:23, Eric Vautier wrote:
Let me confirm that the script has not changed at all, and used to
work fine under the previous version. You'll agree that arriving at a
C:/cygdrive/c/... path is a little odd, regardless of setup.
Nope, it's actually entirely sensible! Because : is not a drive-letter
separator in Linux; it's a separator between path-list components, like ; is
under DOS.
So if you say C:\foo\bar in a path-list context, you are specifying a list
of two paths: C and \foo\bar. Cygwin (or whatever utility is doing the
work) translates each one separately and then reconcatenates them. C in DOS
is a relative path to any subdirectory called C in the current dir; that
stays the same in unix syntax. \foo\bar in DOS is an absolute path relative
to the root of the current drive, which, being your C drive, translates into
/cygdrive/c/foo/bar. These two are then reconcatenated into a path list
separted by colons.
The older version was buggy in this regard, it handled dos paths correctly
at the expense of making a mess of colon-separated posix-style path lists
sometimes. That's why the behaviour has changed, because posix compatibility
wins out over windows compatibility as a design goal of cygwin, and that's why
there's now a warning, to let you know that what you are doing is not going to
work how you want it to.
Right :)
So essentially, I have a broken script now, that used to work fine.
Remains the challenge: how to fix it for non-buggy 1.7.
FYI, the faulty but perfectly logical path in one of the two
failures (I'll try to trace the other one as well) was arrived at
from:
0. Invocation from sh build.sh (mid-script):
ant clean get-common debug
1. Output of build script:
AndroidApp
BUILD FAILED
C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file
C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy.
2. Build target (lines 342-344):
target name=get-common
copy file=${common-jar} todir=libs /
/target
3. Properties:
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
4. Environment variable:
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Typing ant clean get-common debug works fine from the command line.
-e
--
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: Design issue with new MS-DOS style path warning?
So, you are lumbered with some massive mish-mash of complex build scripts, ANT, java, mixture of cygwin and native executables and god knows what else, and somewhere down in the middle of it something's invoking what it probably expects to be a win32 program and getting the cygwin version, or vice-versa. Ouch. You're going to have to figure out what's going on way down in the internals and try and extract a simple testcase. Yes, it's a slightly complicated build script, but it does the job properly when invoked manually. It only fails if it is invoked from inside a wrapping shell script. To sum up: all 5 builds (three maven, two ant) work fine when invoked manually from the command-line. The two ant builds fail in the overall build invocator (build.sh, but I should probably call it build-all.sh), whose sole task is to launch the 5 builds from inside their own directories; the three maven builds are fine. I see no reason why calling that ant build from inside a shell script should mess up the paths with C:\cygdrive\c\dev\ prefixes. build.sh does have #!/bin/sh at the top. Will investigate a little more. -e -- 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: Design issue with new MS-DOS style path warning?
Just to clear things up, none of the paths are hard-coded. They are all obtained from environment variables or paths relative to project root. Only in the output from ant do they look absolute (the build has to figure out an absolute path sooner or later...). Again, the build script works perfectly fine, as long as it's not called from within a shell script. ant clean get-common debug works fine from the command line, but the same line fails with the error mentioned when run from INSIDE a shell script. And it's starting to look like an old Ant/Cygwin interaction issue, slightly off-topic with regards to the original discussion. http://www.eyt.ca/blog/item/136/ (dated) http://ant.apache.org/manual/platform.html (mid-page: Cygwin is trouble!) Seems this issue crops up again every now and then when cygwin or ant comes out with an update. -e On Fri, Jan 22, 2010 at 10:53 PM, Warren Young war...@etr-usa.com wrote: On 1/22/2010 10:23 AM, Eric Vautier wrote: AndroidApp BUILD FAILED C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy. My first thought when I see things like this isn't oh, bad idea, DOS style paths in Cygwin. I think oh, bad idea, absolute paths hard-coded into a build system. That makes it hard to build on any other system, because it ranges from difficult to impossible to demand that everyone install outside dependencies in the same locations. There must be a tool you can use to generate the Ant files from something higher-level, which discovers the correct paths to use. That tool could also abstract away the difference in path styles. Something like Automake, Bakefile or CMake, but which knows how to create Ant files. That's where I'd put my effort, anyway. -- 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: Design issue with new MS-DOS style path warning?
Tried bash, -x, bash build.sh, bash -x build.sh, forward
slashes in Windows environment variables, to no avail. But thank you
for your time and patience, Dave!
-e
On Fri, Jan 22, 2010 at 7:25 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 22/01/2010 17:55, Eric Vautier wrote:
Yes, it's a slightly complicated build script, but it does the job
properly when invoked manually. It only fails if it is invoked from
inside a wrapping shell script.
That shell script presumably does some stuff first before invoking it; maybe
that's where the problem originates. Also, you're running it from sh in
that situation, instead of bash as you do from the command-line; that might
be relevant or might not. (sh is an alias for bash that invokes it with
slightly-altered behaviour.)
To sum up: all 5 builds (three maven, two ant) work fine when invoked
manually from the command-line. The two ant builds fail in the overall
build invocator (build.sh, but I should probably call it
build-all.sh), whose sole task is to launch the 5 builds from inside
their own directories; the three maven builds are fine.
I see no reason why calling that ant build from inside a shell script
should mess up the paths with C:\cygdrive\c\dev\ prefixes. build.sh
does have #!/bin/sh at the top. Will investigate a little more.
Adding -x flag to the shebang might help.
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Try not using mixed slashes. Both Cygwin and DOS should be fairly happy with
APP4_COMMON_ROOT = C:/dev/prj/app4/Common
--
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
