Gerhard Fiedler wrote:
> Olin Lathrop wrote:
> > Dr Skip wrote:
> > > Quoting just the variable, as in "%1" in the bat file passes
> > > the quotes to tar, and no quotes fails on dirs with spaces such as
> > > Program Files. Blasted Microsoft!!
> > 
> > This is not the shell's fault, but rather the fault of the program that
> > can't handle command line arguments quoted.  The shell passes quotes
> > from the command line to the target program just like it should.  A
> > shell that thinks it's clever about what you meant on the command line
> > would only cause a lot more trouble in other areas.  I'd rather have a
> > dumb shell than one that's too clever by a half.
> 
> Exactly. FWIW, I wouldn't call that "too clever", not even by a half :)
> Quoted command line argument are simply standard in Windows. Any CLI
> program meant to run on Windows should understand these, and strip the
> (double) quotes appropriately. 

Yes, on an archaic system like the Windows command-line processor (which
has distant roots in the original CP/M CCP), the application programs
must do some of the work of handling the "raw" command line. In particular,
having one ".BAT" file invoke and pass arguments correctly to another
".BAT" file is incredibly arcane. This is unfortunate, but a large number
of programmers have grown up under this system and don't seem to expect
anything better.

On a modern system (since the mid-1970s -- note the irony there), such as
any *ix shell, the shell itself correctly handles ALL of the command-line
issues, and passes arrays of fully parsed arguments and environment
variables directly to the application program. The application can be a
binary executable or an interpreted script (another instance of the shell,
or Perl, or ...) and it all Just Works.

> That's what I meant with "partly ported": such a program seems to be
> "ported" so that it runs on Windows, but using *ix CLI conventions. That
> may be useful when you have a shell that also uses *ix CLI conventions,
> but it doesn't do what it should in a Windows shell. So the solution for
> using these programs without too many surprises is probably using a (also
> partly ported :) *ix shell on Windows, like bash.

I'm not sure what stones you are trying to cast here. In what way would a
*ix shell be only "partly ported"? I've been running Cygwin bash here for
several years now, and have never run into any "porting" problems. Indeed,
I often get confused as to whether I'm using my local shell, or I'm ssh'd
to my web hosting provider (which is running FreeBSD), because, for all
practical purposes, the environments feel identical.

> Skip, you said you installed cygwin. That's a biggie, and it seems to
> come with its own set of integration problems. A smaller solution is
> MinGW (MSYS); it seems to work well in the sense that it has most of
> the common *ix CLI tools, but with less integration hassles.

Yes, Cygwin does have some integration problems, but not related to
command-line handling. I've seen coLinux promoted as an alternative way
to run *ix tools on a Windows host, but I haven't tried it myself yet.
See

   http://www.colinux.org/

... and this Circuit Cellar article provides a nice overview:

   http://www.dtweed.com/circuitcellar/caj00213.htm#3618

MinGW is a more restricted environment than Cygwin; it is oriented pretty
much around developing software only -- specifically, using GNU compiler
tools to produce Windows applications. Cygwin is a much more diverse
environment, supporting all of the GNU tools and a lot of other GPL
software as well.

-- Dave Tweed
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist