This is the mail archive of the
mailing list for the Cygwin project.
Re: Does not work well: rlwrap + rxvt + cmd
On 8/25/2011 12:51 AM, Ronald Fischer wrote:
On Wed, 24 Aug 2011 11:56 -0400, "Eliot Moss"<firstname.lastname@example.org> wrote:
This behavior is well known. However why does it matter? Are you saying
that you have to "source" a .bat file to set up the environment and then
execute another .bat file that requires those environment settings???
I'm not saying this doesn't happen but it's not a very good practice.
On 8/24/2011 11:52 AM, Ronald of Steiermark wrote:
You can *run* them, but the effect is not always the same.
You can run .bat files from bash and other Cygwin shells.
On Wed, 24 Aug 2011 08:39 -0700, "Andrew DeFaria"<Andrew@DeFaria.com>
For instance, to test the cruel BAT files which we are going to deliver.
For example, setting an environment variable within a batch file under
CMD.EXE results in the environment variable being visible in the calling
environment (similar to "sourcing" a file in bash), while calling the
batch file from bash leaves the environment intact.
Why should this be an issue? I mean if you exec some .bat file and it
calls "copy" does it not work?
Also, some internal commands (for example COPY) are not present in bash,
though this can be easily remedied using an alias or a shell function.
Again, why is this a problem? If your .bat file has "copy
C:\Windows\some.dll C:\Temp" does it not work? Or are you saying that
you may need to do from bash:
Other problems are related to the use of \ as a path separator. Imagine
that some of your BATCH files generate environment variables containing
a Windows path,
$ some.bat <Windows path>
If this is there are a lot of solutions including cygpath, doubling
backslashes, quoting file names or just using forward slashes (which
Windows often works just fine with).
We all know that bash interprets things the bash way. And no doubt cmd
interprets things it's way. I do not see cmd's interpretation as superior.
and simply because bash command lines are interpreted differently than
Windows CMD command line (for example, when it comes to quoting or
The main problem, however, is: If you are going to deliver something,
which is supposed to run under CMD.EXE, most customers won't accept it
until you really have tested it under CMD.EXE, and for good reason.
$ cmd /c somescript.bat
comes in. That does run it under cmd.exe doesn't it? Why do you need
anything more? Why do you need to enter multiple commands and have
command history? Why not simply:
$ cmd /c testscript1.bat
$ # That worked!
$ cmd /c testscript2.bat
$ # That worked too...
$ # etc...
Just re-write your .bat scripts in Perl! ;-)
In fact, even though I got running rxvt with cmd thanks to all the
suggestions to my post, I will do some *final* tests still in plain,
native Windoze Command-Windows, just for the safe side.
Using a bash shell as a "main work horse" is great, but when you have
the pleasure to create and test batch files, you will sooner or later be
happy to also have a CMD shell available...
It's really not that hard. Just s/\\/\/g! That often is enough. Or do a
cygpath -w <posix path> or whatever.
In both cases you generally to present Windows paths, of course;
cygpath can help with that.
I use cygpath in several of my scripts and it's extremely useful, but
dealing with the various path representations in interactive work is,
for me at least, an annoyance...
Andrew DeFaria <http://defaria.com>
My wife keeps complaining I never listen to her ...or something like that.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple