Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Very strange command-line argument handling of /?

Reply
Thread Tools

Very strange command-line argument handling of /?

 
 
marctorrance
Guest
Posts: n/a
 
      03-04-2008
This is not strictly a problem concerning the C language, but I
figured clc might be the only place to find an answer. It's very
basic, I'm displaying the contents of the arguments vector:

int main(int argc, char* argv[])
{

/* counters */
long int i, j;

/* analyse command-line arguments */
for (i=1; i < argc; i++) {
j=0;
while (argv[i][j]!='\0') {
printf("%d %c ",argv[i][j],argv[i][j]);
j++;
}
printf("\n");
}
}

I'm on win32, using the latest stable release of gcc, mingw, compiling
on a FAT32 partition. It seems the whole problem is to do with this
combination.

When I execute "program /?" from the command-line it displays "47 /
99 c". This only happens if I execute the program from the FAT32
drive on which I compiled it.

If I copy the program to another drive (e.g. flash drive, NTFS
partition) it works fine, displaying "47 / 63 ?". On another machine
it's also fine. If I SUBST a new drive to point to the problem
directory and run from the SUBSTed drive, it works fine. However, if
the current directory (i.e. I guess "working directory") is anywhere
in the original FAT32 partition it displays "47 / 99 c".
"/?" is the only problem combination I've discovered (e.g. "program
-?" works OK in all cases), but it doesn't inspire me with a lot of
confidence.

Anyone seen this before or know where to look for an answer?

Thanks.
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
marctorrance <(E-Mail Removed)> wrote:
>This is not strictly a problem concerning the C language, but I
>figured clc might be the only place to find an answer. It's very
>basic, I'm displaying the contents of the arguments vector:


>I'm on win32, using the latest stable release of gcc, mingw, compiling
>on a FAT32 partition. It seems the whole problem is to do with this
>combination.


>When I execute "program /?" from the command-line it displays "47 /
>99 c". This only happens if I execute the program from the FAT32
>drive on which I compiled it.
>
>If I copy the program to another drive (e.g. flash drive, NTFS
>partition) it works fine, displaying "47 / 63 ?".


Possibly you are getting shell pattern matching. /? in some shells
might expand to any file in the directory / that had a single
character name. While you are executing under mingw there
are (if I recall correctly) aliases created for each drive letter
so /c /d and whatever else appropriate exist to be matched against.
But execute outside of mingw and the pattern matching might not occur
(because you are no longer in the shell), and probably those
other drives do not happen to have single-character file
(or directory) names immediately in the root of the drive.
--
"We may gather out of history a policy, by the comparison and
application of other men's forepassed miseries with our own like
errors and ill deservings." -- Sir Walter Raleigh
 
Reply With Quote
 
 
 
 
marctorrance
Guest
Posts: n/a
 
      03-04-2008
On Mar 4, 6:28*pm, (E-Mail Removed)-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. I guess shell pattern matching is something outside my
control (within the C program), but do correct me if I'm wrong.
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
marctorrance <(E-Mail Removed)> wrote:
>On Mar 4, 6:28=A0pm, (E-Mail Removed)-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. I guess shell pattern matching is something outside my
>control (within the C program), but do correct me if I'm wrong.


Try using "/?" as the argument. But of course if it is a Windows
system, users are going to expect /? without having to quote it.
Not much that can be done about that

--
"Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us." -- Ecclesiastes
 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      03-04-2008
marctorrance wrote:
>
> This is not strictly a problem concerning the C language, but I
> figured clc might be the only place to find an answer. It's very
> basic, I'm displaying the contents of the arguments vector:
>
> int main(int argc, char* argv[])
> {
>
> /* counters */
> long int i, j;
>
> /* analyse command-line arguments */
> for (i=1; i < argc; i++) {
> j=0;
> while (argv[i][j]!='\0') {
> printf("%d %c ",argv[i][j],argv[i][j]);
> j++;
> }
> printf("\n");
> }
> }
>
> I'm on win32, using the latest stable release of gcc, mingw, compiling
> on a FAT32 partition. It seems the whole problem is to do with this
> combination.
>
> When I execute "program /?" from the command-line it displays "47 /
> 99 c". This only happens if I execute the program from the FAT32
> drive on which I compiled it.
>
> If I copy the program to another drive (e.g. flash drive, NTFS
> partition) it works fine, displaying "47 / 63 ?". On another machine
> it's also fine. If I SUBST a new drive to point to the problem
> directory and run from the SUBSTed drive, it works fine. However, if
> the current directory (i.e. I guess "working directory") is anywhere
> in the original FAT32 partition it displays "47 / 99 c".
> "/?" is the only problem combination I've discovered (e.g. "program
> -?" works OK in all cases), but it doesn't inspire me with a lot of
> confidence.
>
> Anyone seen this before or know where to look for an answer?


Look into whether or not your implementation and/or O/S will
expand wildcards on the command line.

For example, on Unix, passing "/?" (without the quotes) on the
command line will expand to all of the single-character filenames
in the root directory.

What happens with "/*" or "/??" (again, without quotes) on your
system?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>

 
Reply With Quote
 
marctorrance
Guest
Posts: n/a
 
      03-05-2008
> Try using "/?" as the argument. But of course if it is a Windows
> system, users are going to expect /? without having to quote it.

Yes quotes fixes it - there must be a way around having to do this.

> Not much that can be done about that

Surely something!

> Look into whether or not your implementation and/or O/S will
> expand wildcards on the command line.

Clearly the combination does expand wildcards - my latest thought is
there must be a way to turn it off using compiler options, any ideas?

> What happens with "/*" or "/??" (again, without quotes) on your
> system?

Yes, it blows up. Quite amusing really.

 
Reply With Quote
 
Mark Bluemel
Guest
Posts: n/a
 
      03-05-2008
marctorrance wrote:
>
> Clearly the combination does expand wildcards - my latest thought is
> there must be a way to turn it off using compiler options, any ideas?


Given that the expansion is almost certainly happening at the shell
(command line interpreter) level, before the program actually gets
invoked, it seems highly unlikely that anything you do to your program
will affect this.

I seem to recall that the Primos environment allowed you to control
this sort of thing, via non-portable interfaces, but I doubt you'll
have this option elsewhere.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-05-2008
marctorrance wrote:

>> Try using "/?" as the argument. But of course if it is a Windows
>> system, users are going to expect /? without having to quote it.

> Yes quotes fixes it - there must be a way around having to do this.
>
>> Not much that can be done about that

> Surely something!
>
>> Look into whether or not your implementation and/or O/S will
>> expand wildcards on the command line.

> Clearly the combination does expand wildcards - my latest thought is
> there must be a way to turn it off using compiler options, any ideas?


<snip>

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.

 
Reply With Quote
 
marctorrance
Guest
Posts: n/a
 
      03-06-2008
On Mar 5, 2:16*pm, santosh <(E-Mail Removed)> 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.
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, but
I didn't expect to find that behaviour in my simple C program (I guess
it isn't defined in the standard so the compiler can do what it
likes).

To turn it off I followed the one-line instruction at:
http://www.cygwin.com/ml/cygwin/1999-11/msg00052.html
add the following line with global scope (above main)
int _CRT_glob = 0;
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-07-2008
marctorrance wrote:

> On Mar 5, 2:16*pm, santosh <(E-Mail Removed)> 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>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Invalid postback or callback argument - Very Strange Error shapper ASP .Net 1 02-01-2008 02:02 AM
very very very long integer shanx__=|;- C Programming 19 10-19-2004 03:55 PM
very very very long integer Abhishek Jha C Programming 4 10-17-2004 08:19 AM
Quick Book file access very very very slow Thomas Reed Computer Support 7 04-09-2004 08:09 PM
very Very VERY dumb Question About The new Set( ) 's Raymond Arthur St. Marie II of III Python 4 07-27-2003 12:09 AM



Advertisments