Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58704 > unrolled thread

strange problem

Back to article view | Back to comp.lang.c

Contents

  strange problem bilsch <king621@comcast.net> - 2015-03-23 02:10 +0000
    Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 03:03 +0000
      Re: strange problem Keith Thompson <kst-u@mib.org> - 2015-03-22 22:09 -0700
        Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 09:04 +0000
      Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 08:30 +0000
        Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 09:06 +0000
          Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 21:21 +0000
            Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 21:42 +0000
              Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 22:35 +0000
              Re: strange problem Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:20 -0700
            Re: strange problem Keith Thompson <kst-u@mib.org> - 2015-03-23 15:23 -0700
              Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 23:14 +0000
                Re: strange problem Keith Thompson <kst-u@mib.org> - 2015-03-23 17:10 -0700
    Re: strange problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-23 03:03 +0000
      Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 08:37 +0000
        Re: strange problem raltbos@xs4all.nl (Richard Bos) - 2015-03-23 09:37 +0000
          Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 21:27 +0000
            Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 21:43 +0000
              Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 22:36 +0000
                Re: strange problem Keith Thompson <kst-u@mib.org> - 2015-03-23 17:09 -0700
        Re: strange problem JohnF <john@please.see.sig.for.email.com> - 2015-03-23 13:02 +0000
          Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 13:10 +0000
            Re: strange problem Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:18 -0500
              Re: strange problem Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 00:28 +0000
                Re: strange problem Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:38 -0500
                Re: strange problem jt@toerring.de (Jens Thoms Toerring) - 2015-03-24 01:12 +0000
          Re: strange problem Keith Thompson <kst-u@mib.org> - 2015-03-23 08:10 -0700
          Re: strange problem Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-23 11:28 -0400
            Re: strange problem bilsch <king621@comcast.net> - 2015-03-23 21:47 +0000
              Re: strange problem Kaz Kylheku <kaz@kylheku.com> - 2015-03-23 21:53 +0000
              Re: strange problem Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-23 18:34 -0400
                Re: strange problem James Kuyper <jameskuyper@verizon.net> - 2015-03-23 18:58 -0400
      Re: strange problem raltbos@xs4all.nl (Richard Bos) - 2015-03-23 09:54 +0000
    Re: strange problem Kaz Kylheku <kaz@kylheku.com> - 2015-03-23 21:47 +0000

Page 2 of 2 — ← Prev page 1 [2]

#58739

bilsch <king621@comcast.net> wrote:
>> You could make it argc<=1, for example.
> 
> I tried that just now.  It doesn't fix the problem.
> This is truly a strange problem.

argc<2 is the usual test for no user-supplied command-line args.
But I've had problems with windows when the executable was in
a directory whose path contained spaces. Then the "pieces" of the
path were sometimes each counted as separate args (e.g., by mingw
compiler), and things got screwed up.

You have much debugging experience? The very first thing
I'd have tried immediately would've be
  #include <stdio.h>
  int main ( int argc, char *argv[] ) {
  int iarg;
  printf(" #args = %d\n", argc);
  if ( argc > 0 )
    for ( iarg=0; iarg<argc; iarg++ )
      printf(" arg#%d = \"%.64s\"\n",
      iarg, (argv[iarg]==NULL?"NULL":argv[iarg]) ); }
That ain't rocket science. So what happens?

To get around the windows problem described above,
I introduced the following kludge. You know how various
utilities use "--" to signal the end of command-line -switches?
I parsed my command-line args looking for a complementary "++"
to introduce command-line args. For example,
   C:\silly directory name\with spaces\myprog.exe ++ arg1 arg2 etc
That way I knew for sure where args started. If no ++ in any
of the argc's, I assumed argc>1 meant argv[1],...,[argc-1]
were user input (and tough luck for the user if not).
So linux users didn't have to do that, but it would work if they did.
Maybe a bit more pain for users, but I couldn't figure
an easier way to robustly check.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#58740

On 23/03/15 13:02, JohnF wrote:
> bilsch <king621@comcast.net> wrote:
>>> You could make it argc<=1, for example.
>>
>> I tried that just now.  It doesn't fix the problem.
>> This is truly a strange problem.
>
> argc<2 is the usual test for no user-supplied command-line args.
> But I've had problems with windows when the executable was in
> a directory whose path contained spaces.

Allowing spaces in filenames/pathnames was a monumentally bad design 
decision. Nevertheless, the workaround (for argv) is fairly simple - 
just enclose the pathname in "quotes", and all your troubles are over.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#58808

On Mon, 23 Mar 2015 13:10:49 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>On 23/03/15 13:02, JohnF wrote:
>> bilsch <king621@comcast.net> wrote:
>>>> You could make it argc<=1, for example.
>>>
>>> I tried that just now.  It doesn't fix the problem.
>>> This is truly a strange problem.
>>
>> argc<2 is the usual test for no user-supplied command-line args.
>> But I've had problems with windows when the executable was in
>> a directory whose path contained spaces.
>
>Allowing spaces in filenames/pathnames was a monumentally bad design 
>decision. Nevertheless, the workaround (for argv) is fairly simple - 
>just enclose the pathname in "quotes", and all your troubles are over.


Not allowing spaces in things that humans will name is a monumentally
bad user interface design decision.  There is no reason a user should
not be able to name their spreadsheet "2014 Sales Analysis".  That's a
perfectly reasonable name for the user.

While allowing a file to have more than one name, one allowing spaces
(and being the one most visible to the users), is possible, it
introduces a whole new set of difficulties.

[toc] | [prev] | [next] | [standalone]

#58809

On 24/03/15 00:18, Robert Wessel wrote:
> On Mon, 23 Mar 2015 13:10:49 +0000, Richard Heathfield
> <rjh@cpax.org.uk> wrote:

>>Allowing spaces in filenames/pathnames was a monumentally bad design
>>decision. [...]
>
>
> Not allowing spaces in things that humans will name is a monumentally
> bad user interface design decision.

Yes, it was. But, once that monumentally bad decision had been made, 
everybody was used to it, everybody knew the rules, nobody even /tried/ 
to put spaces in filenames... and then, suddenly, the second 
monumentally bad decision was made - i.e. to reverse the original 
monumentally bad decision.

Sometimes, once you've screwed it up, it's best to leave it screwed up, 
because that's one of your only two choices, the other of which is to 
screw it up even more.

If we'd had spaces in filenames right from the outset, they would never 
have been a problem.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#58810

On Tue, 24 Mar 2015 00:28:30 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>On 24/03/15 00:18, Robert Wessel wrote:
>> On Mon, 23 Mar 2015 13:10:49 +0000, Richard Heathfield
>> <rjh@cpax.org.uk> wrote:
>
>>>Allowing spaces in filenames/pathnames was a monumentally bad design
>>>decision. [...]
>>
>>
>> Not allowing spaces in things that humans will name is a monumentally
>> bad user interface design decision.
>
>Yes, it was. But, once that monumentally bad decision had been made, 
>everybody was used to it, everybody knew the rules, nobody even /tried/ 
>to put spaces in filenames... and then, suddenly, the second 
>monumentally bad decision was made - i.e. to reverse the original 
>monumentally bad decision.


Everyone was not used to it.  As computers changed from things being
used by computing specialists to things being used by
very-much-non-computing-specialists, who were definitely *not* used to
such a convention, it had to change.

And handling names with spaces is not actually that hard, even in
areas where they cause problems, like on command lines.  Just use
quotes.  And that burden is only on the specialists who can be assumed
to know enough to do that when required.


>Sometimes, once you've screwed it up, it's best to leave it screwed up, 
>because that's one of your only two choices, the other of which is to 
>screw it up even more.


I don't believe it would have been possible to *not* change.


>If we'd had spaces in filenames right from the outset, they would never 
>have been a problem.


That's certainly true.

[toc] | [prev] | [next] | [standalone]

#58813

Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 24/03/15 00:18, Robert Wessel wrote:
> > On Mon, 23 Mar 2015 13:10:49 +0000, Richard Heathfield
> > <rjh@cpax.org.uk> wrote:

> >>Allowing spaces in filenames/pathnames was a monumentally bad design
> >>decision. [...]
> >
> > Not allowing spaces in things that humans will name is a monumentally
> > bad user interface design decision.

> Yes, it was. But, once that monumentally bad decision had been made, 
> everybody was used to it, everybody knew the rules, nobody even /tried/ 
> to put spaces in filenames... and then, suddenly, the second 
> monumentally bad decision was made - i.e. to reverse the original 
> monumentally bad decision.

> Sometimes, once you've screwed it up, it's best to leave it screwed up, 
> because that's one of your only two choices, the other of which is to 
> screw it up even more.

> If we'd had spaces in filenames right from the outset, they would never 
> have been a problem.

What is the big problem with spaces in file names? Unix had,
for as long as I remember, only two characters excluded from
file names, '\0' (for obvious reasons to a C programmer) and
'/' as the path separator, allowing to have directories. Some
utilities (like shells) use spaces to separate e.g. command
line arguments, so spaces in a file name need escaping (or
enclosing file names in quotes) when used in that context
(which sometimes can be a bit of a PITA when writing shell
scripts, admittedly) - and for that reason they're probably
often avoided. But I can't see anything "monumentally bad"
about all that. And I don't have any idea what you mean by
a "second monumentally bad" decision. Or is that about some
software company from the northern-western coast of one of
your former colonies, shooting itself into its own feet over
and over again while trying to catch up with things others
already had for ages?
                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#58752

JohnF <john@please.see.sig.for.email.com> writes:
> bilsch <king621@comcast.net> wrote:
>>> You could make it argc<=1, for example.
>> 
>> I tried that just now.  It doesn't fix the problem.
>> This is truly a strange problem.
>
> argc<2 is the usual test for no user-supplied command-line args.
> But I've had problems with windows when the executable was in
> a directory whose path contained spaces. Then the "pieces" of the
> path were sometimes each counted as separate args (e.g., by mingw
> compiler), and things got screwed up.
[...]

So if the the executable is "C:\dir name\foo.exe", you'll
get "C:\dir" in argv[0] and "name\foo.exe" in argv[1]?  Ick.
Does quoting the executable name work around it?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58755

On Monday March 23 2015 09:02, in comp.lang.c, "JohnF"
<john@please.see.sig.for.email.com> wrote:

> bilsch <king621@comcast.net> wrote:
>>> You could make it argc<=1, for example.
>> 
>> I tried that just now.  It doesn't fix the problem.
>> This is truly a strange problem.
> 
> argc<2 is the usual test for no user-supplied command-line args.
> But I've had problems with windows when the executable was in
> a directory whose path contained spaces. Then the "pieces" of the
> path were sometimes each counted as separate args (e.g., by mingw
> compiler), and things got screwed up.

I believe that this behaviour is inherent in the way the Windows API manages
commandlines. The "real" entrypoint of any windows program is a function
called WinMain()[1], which *does not* receive argc/argv. I imagine that
most standard C implementations on Windows will use WinMain as a system
interface stub that does some environment prep (like reparsing argc/argv)
and then calls the C main() function.

In order to get a C-like argc/argv, you must call GetCommandLine()[2] to
retrieve the unparsed commandline string, and then pass that string to
CommandLineToArgvW()[3] to get "an array of pointers to the command line
arguments, along with a count of such arguments, in a way that is similar
to the standard C run-time argv and argc values."

It may be that CommandLineToArgvW() (or whatever homegrown commandline
parser the implementation uses) is not sophisticated enough to properly
recognize the argv[0] programname value when it includes spaces, or is
wrapped in quotes.


[1]https://msdn.microsoft.com/en-us/library/windows/desktop/ff381406%28v=vs.85%29.aspx

[2]https://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx

[3]https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#58792

On Mon, 23 Mar 2015 11:28:11 -0400, Lew Pitcher wrote:

> On Monday March 23 2015 09:02, in comp.lang.c, "JohnF"
> <john@please.see.sig.for.email.com> wrote:
> 
>> bilsch <king621@comcast.net> wrote:
>>>> You could make it argc<=1, for example.
>>> 
>>> I tried that just now.  It doesn't fix the problem.
>>> This is truly a strange problem.
>> 
>> argc<2 is the usual test for no user-supplied command-line args. But
>> I've had problems with windows when the executable was in a directory
>> whose path contained spaces. Then the "pieces" of the path were
>> sometimes each counted as separate args (e.g., by mingw compiler), and
>> things got screwed up.
> 
> I believe that this behaviour is inherent in the way the Windows API
> manages commandlines. The "real" entrypoint of any windows program is a
> function called WinMain()[1], which *does not* receive argc/argv. I
> imagine that most standard C implementations on Windows will use WinMain
> as a system interface stub that does some environment prep (like
> reparsing argc/argv)
> and then calls the C main() function.
> 
> In order to get a C-like argc/argv, you must call GetCommandLine()[2] to
> retrieve the unparsed commandline string, and then pass that string to
> CommandLineToArgvW()[3] to get "an array of pointers to the command line
> arguments, along with a count of such arguments, in a way that is
> similar to the standard C run-time argv and argc values."
> 
> It may be that CommandLineToArgvW() (or whatever homegrown commandline
> parser the implementation uses) is not sophisticated enough to properly
> recognize the argv[0] programname value when it includes spaces, or is
> wrapped in quotes.
> 
> 
> [1]https://msdn.microsoft.com/en-us/library/windows/desktop/ff381406%
28v=vs.85%29.aspx
> 
> [2]https://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%
28v=vs.85%29.aspx
> 
> [3]https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%
28v=vs.85%29.aspx

I'm using Ubuntu not windows.

[toc] | [prev] | [next] | [standalone]

#58793

On 2015-03-23, bilsch <king621@comcast.net> wrote:
> I'm using Ubuntu not windows.

Because the code snippets that you post contain carriage returns, it is
reasonable to suspect that at some point you edited your code on Windows.

[toc] | [prev] | [next] | [standalone]

#58797

On Monday March 23 2015 17:47, in comp.lang.c, "bilsch"
<king621@comcast.net> wrote:

> On Mon, 23 Mar 2015 11:28:11 -0400, Lew Pitcher wrote:
> 
>> On Monday March 23 2015 09:02, in comp.lang.c, "JohnF"
>> <john@please.see.sig.for.email.com> wrote:
>> 
>>> bilsch <king621@comcast.net> wrote:
>>>>> You could make it argc<=1, for example.
>>>> 
>>>> I tried that just now.  It doesn't fix the problem.
>>>> This is truly a strange problem.
>>> 
>>> argc<2 is the usual test for no user-supplied command-line args. But
>>> I've had problems with windows when the executable was in a directory
>>> whose path contained spaces. Then the "pieces" of the path were
>>> sometimes each counted as separate args (e.g., by mingw compiler), and
>>> things got screwed up.
>> 
>> I believe that this behaviour is inherent in the way the Windows API
>> manages commandlines. The "real" entrypoint of any windows program is a
>> function called WinMain()[1], which *does not* receive argc/argv. I
>> imagine that most standard C implementations on Windows will use WinMain
>> as a system interface stub that does some environment prep (like
>> reparsing argc/argv)
>> and then calls the C main() function.
>> 
>> In order to get a C-like argc/argv, you must call GetCommandLine()[2] to
>> retrieve the unparsed commandline string, and then pass that string to
>> CommandLineToArgvW()[3] to get "an array of pointers to the command line
>> arguments, along with a count of such arguments, in a way that is
>> similar to the standard C run-time argv and argc values."
>> 
>> It may be that CommandLineToArgvW() (or whatever homegrown commandline
>> parser the implementation uses) is not sophisticated enough to properly
>> recognize the argv[0] programname value when it includes spaces, or is
>> wrapped in quotes.
>> 
>> 
>> [1]https://msdn.microsoft.com/en-us/library/windows/desktop/ff381406%
> 28v=vs.85%29.aspx
>> 
>> [2]https://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%
> 28v=vs.85%29.aspx
>> 
>> [3]https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%
> 28v=vs.85%29.aspx
> 
> I'm using Ubuntu not windows.

Perhaps, but that's not what I was responding to.

If I may quote the post I replied to:

>>> I've had problems with windows when the executable was in a directory
>>> whose path contained spaces. Then the "pieces" of the path were
>>> sometimes each counted as separate args (e.g., by mingw compiler), and
>>> things got screwed up.

Note the reference to Windows.

And, apparently, Keith thought the same as I did. His reply (Message-ID:
<87oanju4vk.fsf@kst-u.example.com>) to the same message asked

> So if the the executable is "C:\dir name\foo.exe", you'll
> get "C:\dir" in argv[0] and "name\foo.exe" in argv[1]?  


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#58801

On 03/23/2015 06:34 PM, Lew Pitcher wrote:
> On Monday March 23 2015 17:47, in comp.lang.c, "bilsch"
> <king621@comcast.net> wrote:
>> On Mon, 23 Mar 2015 11:28:11 -0400, Lew Pitcher wrote:
>>> On Monday March 23 2015 09:02, in comp.lang.c, "JohnF"
>>> <john@please.see.sig.for.email.com> wrote:
>>>> bilsch <king621@comcast.net> wrote:
...
>> I'm using Ubuntu not windows.
> 
> Perhaps, but that's not what I was responding to.
> 
> If I may quote the post I replied to:
> 
>>>> I've had problems with windows when the executable was in a directory
>>>> whose path contained spaces. Then the "pieces" of the path were
>>>> sometimes each counted as separate args (e.g., by mingw compiler), and
>>>> things got screwed up.
> 
> Note the reference to Windows.

It's lower-case "windows", so it might be a reference to the X Window
System, rather than to Microsoft Windows. However, that seems
inconsistent with him talking about mingw, which I believe is
exclusively targeted at Microsoft Windows platforms. I'm certainly
misunderstanding something.

[toc] | [prev] | [next] | [standalone]

#58730

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> bilsch <king621@comcast.net> wrote:
> > Please see code below.  The intention is to execute the 'else' path if 
> > there are any command line arguments.  If no arguments then execute the 
> > 'if' path (hard coded values).  Two weeks ago that is how it worked but 
> > now it takes the 'else' path even when no arguments.  As shown I've tried 
> > testing either argv[1] and argc but neither works.  Does anyone know what 
> > might be wrong?
> 
> http://crasseux.com/books/ctutorial/argc-and-argv.html

Be careful! That is a Ganuck tutorial, not a C one. There doesn't seem
to be any embrace-and-extend mudslingery on that page, but there
certainly is on others on that site. Take with many grains of salt.

Richard

[toc] | [prev] | [next] | [standalone]

#58791

On 2015-03-23, bilsch <king621@comcast.net> wrote:
> Two weeks ago that is how it worked

Then go back through your version control history to find out where
it broke. If you are using git, read up on "git bisect".

(Obviously what worked one week ago is not the same as the code which doesn't
work this week. Unless the code checks the system time and misbehaves according
to date, or has some other external environmental ependency that has changed in
a week's time.)

What, don't use version control? Okay, go to your filesystem backup and
retrieve the version of the source file from one week ago.

What, no version control or backups? Change your moronic ways.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web