I've been trying to get a co-worker's linux build scripts for set of large grails apps to work in windows (via cygwin). He uses a lot of 'here documents' but I can reduce my problem down to a simple question - how, in windows or cygwin, do I get grails to accept a series of commands from stdin -- i.e. 'grails < cmds'. Every time I try this grails simply opens with the 'grails>' interactive prompt.
I have tried all variations of -Djline=jline.(Windows Linux Unsupported)Terminal with -non-interactive and cygwin and cmd (Windows 7 64 bit, grails 2.3.5 by the way) but in all it seems to ignore the redirection of stdin. I've even tried the variation 'cat cmds | grails ..... '
I've looked through the jiras but haven't found anything definitive. There were some comments about moving to different windows consoles (e.g. conemu) but that didn't solve anything for me.
Moving off windows is not an option :(
Anyone seen/solved this problem before or have any insights ?
What is grails? I mean, what exactly is started when you run it?
Look in Task Manager or Process Explorer for command line. Supposing, it runs java.exe, so you need to replicate full command line and just use trailing redirector of yours < cmds.
Related
I am trying to run the perl script through command line but it is not reorganizing the script file ie.
myscript.pl... is not working
but perl myscript.pl is working fine
I have tried the following suggestions but they didn't work either
How do I make my Perl scripts act like normal programs on Windows?
Perl execution from command line question
I am using Active Perl:- Perl 5 , Version 18.
It gives following warnings in both cases.
Using a hash as a reference is deprecated
earlier I installed strawberry perl before installing active perl, is that causing some problem.
The error message
Using a hash as a reference is deprecated
is a Perl message. Your script is being run just fine, but contains an error.
(It is remotely possible that you have two Perl versions installed, and that you configured Windows to use the wrong one. Reconfigure it to use the correct on then, using the guides you already found.)
I understand that console applications using git bash invoke sh.exe but I wonder how they continue to use sh.
I see on console apps often you do a sh.exe --login. I would guess this creates a session somewhere and I would presume that the console application would execute commands against it somehow?
Essentially I switched from UNIX to Windows. I have tried a lot of console apps (best being console2 and just git-bash) but they still do not work for me well.
Ia m annoyed enough that I fancy trying to programming a simple shell in Java. (I am a Java developer by trade.)
Any help would be great thanks to understand this, looking but searchs with console or git-bash in google generate so much random noise.
If you are using one of the various Unix shells ported to Windows, you should be aware that most of these shells use some heuristic to make Windows look like Unix, either to build a compatibility layout or for user convenience.
For instance, the git command is probably stored in a git.exe file but your shell scripts imported from your Unix workstation all say git so the shell will lookup git.exe if it does not find git.
Nobe of these heuristics works perfectly, so you have to expect regular inconsistencies and disagreements, especially if your are mixing several Unix ports together.
As for the meaning of --login, it is synonymous to -l and its main effect is to decide which initialization files are read by bash on startup`
-l Make bash act as if it had been invoked as a login shell (see
INVOCATION below).
i've installed DAMP on Windows Vista, and have created a profile in my drupal folder with a shell script that needs to run.
profiles/donor_rally/rebuild.sh
However, I don't know how to execute this shell script.
I am not familiar with shell script command language, would you be willing to provide me with a step-by-step instructions on how to execute this shell script?
Thanks.
It looks like you're trying to run a Bourne shell script, which would usually only run on a unix machine. Guessing from the name, this is supposed to rebuild something, likely the database, but that's just a guess.
The short answer is you can't run it, at least not easily. If you were to post the (edited) contents of the script you might get some answers about how you could port it to a Windows cscript or batch file.
For others who are uninitiated to shell scripting in Windows:
I did not find a straightforward solution for running shell scripts on AMP hosted on Windows.
Instead I got an account at webenabled.com
Then used PuTTy to tunnel in.
I found this guide to using UNIX: http://freeengineer.org/learnUNIXin10minutes.html
And lynda.com
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703
This is related to this question : How to get coloured file listing in windows cmd shell ?
I'm trying to get, wouldn't you believe it, coloured file listing in windows cmd shell. Windows are XP SP2, if that matters.
In the old DOS days there used to be little programs like hdir, adir and such which displayed that nice. Nowadays, such programs are no more.
There is however, ls, from unixkit-tiny or unixtools. Unfortunatelly, it uses ANSI escape codes for displaying colours, and cmd doesn't handle those too well.
There are several solutions which include loading ansi.sys and command.com, but command.com doesn't handle long filenames that well, and is awfully slow. Even then sometimes it has problems displaying colours.
So what I'm asking, is there a way to get coloured file listing in windows cmd shell, apart from using cygwin ? Or is there a way to get ANSI escape codes to work with cmd.exe in a way so that native ls will play nicely ?
I ran across ANSICON at http://adoxa.110mb.com/ansicon/index.html ansicon github repo
Using it to colorize NAnt output. ls --color is being processed correctly.
Source code is provided, but I haven't examined it.
Actually I reckon A+ for ansicon -- Use
ansicon.exe -I
Installs it as a filter on your CMD.exe sessions. Works a treat with HTTY (ruby gem).
:-)
You could start the builtin Telnet server, firewall it to only allow localhost access, and use a telnet client that understands such escapes - even the native one. (I know, an ugly hack.)
It's possible to patch cmd.exe....
http://gynvael.coldwind.pl/?id=130&lang=en