«

On Mar 7, 7:17*am, santosh <santosh....@gmail.com> wrote:
> marctorrance wrote:
> > On Mar 5, 2:16*pm, santosh <santosh....@gmail.com> wrote:
>
> I don't think DJ Delorie had anything to do with MinGW. His work is
> DJGPP, a DOS port of gcc.
Yes, and here's his workaround, dated 1995:
http://www.koders.com/c/fid033A3AD82...6267E2549.aspx

> > Globbing is off by default in the Win32/DOS shell (if you use "/") but
> > it seems that "problem" has a workaround built into mingw by default.
> > I suppose preventing the use of "/" helps you to make portable C,
>
> Should it?
No--but it does, by making simple argv processing blow up on platforms
where you might sensibly want to use "/".

> The '/' character is used as a command options delimiter
> under Windows, and a portable C program has to be able to handle it.
My point exactly, so why should mingw turn it from a command options
delimiter into a shell pattern matching switch?
Seems a bit of an odd thing to do to me, if the win32/dos shell
handles it differently to unix, then let it.
Anyway, it's a minor point and all those guys, Delorie, Navia, van der
Heijden, Peters, and all the others have done a great job. I suppose
it's just the human element coming through. Navia in particular gets a
lot of flames for that and he probably shouldn't.

On Fri, 7 Mar 2008 01:22:26 -0800 (PST), marctorrance
<> wrote:

> On Mar 7, 7:17*am, santosh <santosh....@gmail.com> wrote:
<snip: mingw-on-Windows globbing>
> > The '/' character is used as a command options delimiter
> > under Windows, and a portable C program has to be able to handle it.

> My point exactly, so why should mingw turn it from a command options
> delimiter into a shell pattern matching switch?

It doesn't really 'turn it ... into pattern matching'. Rather, (most)
Unix shells try to glob _all_ unquoted wildcard arguments, and pass
the results to the program; if a wildcard does not match any file, it
is left as a wildcard. Then, most programs treat any initial arguments
(and sometimes others) beginning with - as options/flags. (Yes, this
means that using a broad pattern like * when there exists in the
current directory a file whose name begins with - causes spurious
flags.) An argument beginning with / is treated as data; in the common
case that an argument is (treated as) a filename, initial slash makes
it an absolute pathname rather than a relative one.

In contrast, DOS/Windows command processors pass the whole command
line to a program, and many programs (not all) treat initial arguments
beginning with - OR / as options/flags, and then glob only arguments
identified as filenames (or not at all). Mingw by default emulates the
Unix way by globbing unquoted arguments. This includes both - and /;
but, as you discovered, there will always be some / names to match,
but usually no - names, so that 'accidentally' remains as you wanted.

> Seems a bit of an odd thing to do to me, if the win32/dos shell
> handles it differently to unix, then let it.

This is a longstanding argument. Some people want C programs written
in DOS/Win to work the DOS/Win native way; some people want C programs
ported from Unix to continue working. That's why there's the option.

- formerly david.thompson1 || achar(64) || worldnet.att.net

santosh wrote:
> marctorrance wrote:
>
>> On Mar 5, 2:16 pm, santosh <santosh....@gmail.com> wrote:
>>> This has almost certainly nothing to do with your compiler, but your
>>> command interpreter. Did you see it's documentation. Most shells have
>>> a way to turn of wildcard matching, globbing and the like. If it's a
>>> UNIXish shell try posting to comp.unix.shell where their expertise
>>> will be able to guide you better than here.
>> It seems it was mingw, or rather Delorie's attempt to make Win32/DOS
>> unix-like on the command-line, causing the pattern matching.
>
> I don't think DJ Delorie had anything to do with MinGW. His work is
> DJGPP, a DOS port of gcc.
>
> <http://www.mingw.org/history.shtml>
>
>> Globbing is off by default in the Win32/DOS shell (if you use "/") but
>> it seems that "problem" has a workaround built into mingw by default.
>> I suppose preventing the use of "/" helps you to make portable C,
>
> Should it? The '/' character is used as a command options delimiter
> under Windows, and a portable C program has to be able to handle it.
>
> <snip>
>
Does a portable C program need to know and take care of Windows command
line options conventions? Why? Of Unix conventions? Why?

Nothing to do with C really, the command shell is in charge. The '/'
character is reserved in the Unix shells, sh, ksh, etc. as a directory
separator and cannot be used (as far as I know) in any other way.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

In article <>,
Joe Wright <> wrote:
....
>Nothing to do with C really, the command shell is in charge. The '/'
>character is reserved in the Unix shells, sh, ksh, etc. as a directory
>separator and cannot be used (as far as I know) in any other way.

There's nothing to stop a Unix program from using the / (on the command
line) as an option indicator, or in any other way it chooses to.

On Mar 4, 11:37*am, marctorrance <marctorra...@googlemail.com> wrote:
> On Mar 4, 6:28*pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
> wrote:
>
> > Possibly you are getting shell pattern matching. /? in some shells
> > might expand to any file in the directory / that had a single
> > character name.
>
> Walter you are a genius. *I have a directory called "c" on that
> partition.

Do not follow this braindamaged convention. Consider supporting "--
help" as the help option.

> I guess shell pattern matching is something outside my
> control (within the C program), but do correct me if I'm wrong.

The Windows command interpreter doesn't expand patterns; they are
passed to the program. The Mingw environment must be arranging for
that expansion to be done; perhaps it can be turned off.

Windows command line programs have to explicitly match wildcards. This
has advantages and disadvantages. And note that certain Unix utilities
do the same thing. For instance when you run find . -name '*foo',
it's the
find program that performs the matching.

After 15 seconds of Googling I found this advice:

``By default compile, if you run a MinGW compiled command-line utility
and pass it a wildcard argument such as *.c, it acts exactly as a unix
utility and looks for every file ending in .c in your current file
directory, replacing the *.c argument with the name of every one of
those files so that your program never actually sees the *.c. To
prevent this "globbing," put CRT_noglob.o (in the MinGW library
directory) at the beginning of your link list when linking. ''

So if you want to write a proper Windows program according to Windows
conventions, that is what you should do: handle the globbing in your
application, and only for those arguments that are file specification.

In article <>,
Joe Wright <> wrote:

>Nothing to do with C really, the command shell is in charge. The '/'
>character is reserved in the Unix shells, sh, ksh, etc. as a directory
>separator and cannot be used (as far as I know) in any other way.

$ echo $SHELL
/bin/ksh
$ echo $((155/17))
9

That's at least one use of / in ksh in which '/' is used a
different way than as a directory seperator.

Then there is ksh's vi editting mode:

/string Search backward through history for a previous command
containing string. String is terminated by a "RETURN" or
"NEW LINE". If string is preceded by a ^, the matched
line must begin with string. If string is null the
previous string will be used.

--
"Man's life is but a jest,
A dream, a shadow, bubble, air, a vapor at the best."
-- George Walter Thornbury

Joe Wright wrote:

> santosh wrote:
>> marctorrance wrote:
>>
>>> On Mar 5, 2:16 pm, santosh <santosh....@gmail.com> wrote:
>>>> This has almost certainly nothing to do with your compiler, but
>>>> your command interpreter. Did you see it's documentation. Most
>>>> shells have a way to turn of wildcard matching, globbing and the
>>>> like. If it's a UNIXish shell try posting to comp.unix.shell where
>>>> their expertise will be able to guide you better than here.
>>> It seems it was mingw, or rather Delorie's attempt to make Win32/DOS
>>> unix-like on the command-line, causing the pattern matching.
>>
>> I don't think DJ Delorie had anything to do with MinGW. His work is
>> DJGPP, a DOS port of gcc.
>>
>> <http://www.mingw.org/history.shtml>
>>
>>> Globbing is off by default in the Win32/DOS shell (if you use "/")
>>> but it seems that "problem" has a workaround built into mingw by
>>> default. I suppose preventing the use of "/" helps you to make
>>> portable C,
>>
>> Should it? The '/' character is used as a command options delimiter
>> under Windows, and a portable C program has to be able to handle it.
>>
>> <snip>
>>
> Does a portable C program need to know and take care of Windows
> command line options conventions? Why? Of Unix conventions? Why?

The problem is a portable program can't assume that it is running on a
particular system. Therefore it might very well be given options
separated by '/', '-', '--', ' ', or by any other character. The best
option is of course to follow the conventions of the system under which
it runs, which means that it must use a generalised command parsing
code (like GNU getopt) and not hardwire the options delimiter.

<snip>