Two questions about main's arguments

N

Nobody

I think it is clear, at this late date, that the so-called "MSDOS" way
of doing it is best, *provided* that the implementation provides a
standard library call to do the parsing that, in the Unix way, the shell
normally does for you. And makes it damn clear that every app should
invoke this function unless it has a damn good reason not to (something
like 'find' being a good example of a valid exception).

Then, every program which invokes another program has to escape or quote
any arguments which may be affected by the parsing which is built into
each program (at least, the ones which follow the edict).

With Unix, one of the first rules to be impressed on novice programmers is
to avoid system() like the plague, and use fork+exec* directly, so that
you aren't fighting the shell. Of course, that would be somewhat harder if
the "shell" was built into every program.
I see the "Unix way" (of handling the command line) as an attempt to
"standardize without standardizing" - that is, to nip the problem in the
bud, without requiring explicit/heavy-handed edicts that might be seen as
crimping fragile developer egos.

I see the Unix way as simply providing the most convenient interface.
Programs don't have to do any magic with their arguments, and invoking a
program doesn't have to undo said magic. Users who want the convenience of
all kinds of shorthands can use the shell of their choice.

The minor inconvenience of having to quote patterns for e.g. find isn't
worth the problems (e.g. the fact that any program invoking find needs to
know that it's invoking find and that it shouldn't be protecting arguments
against parsing).
Implicit in the above is the fact that neither Unix nor DOS/Windows
ever had the concept of "application developer discipline" (a term I
just made up). Developers were always encouraged to "go their own way",
to "live free" and to "follow their dreams". Contrast this with the Mac
way, where there were always clear guidelines (from Apple) telling you
how to do each little thing (and that you deviated at your peril).

On the contrary, Unix has a very strong sense of convention, particularly
"do what you're told". Command-line arguments are commonly passed directly
to API functions without modification or interpretation. This approach is
essential if you want to construct complex scripts; otherwise, as the
script becomes more complex, the probability that any particular value
will end up triggering some undesired "automagic" behaviour approaches
unity.
 
B

blmblm

I've had problems when globbing generated truly enormous command lines

I think it is clear, at this late date, that the so-called "MSDOS" way
of doing it is best, *provided* that the implementation provides a
standard library call to do the parsing that, in the Unix way, the shell
normally does for you. And makes it damn clear that every app should
invoke this function unless it has a damn good reason not to (something
like 'find' being a good example of a valid exception).[/QUOTE]

You know .... That sounds like a good point, even to Ms. UNIX
Bigot here, unless/until you try to define what you mean by "the
parsing ... the shell normally does for you". Which shell do
you mean? In UNIXworld there are of course several, and they have
different syntaxes and capabilities. This function you propose --
which of them should it emulate? Should it deal with input/output
redirection? Pipes [1]? Environment variables? Shell variables?
Command substitution [2]? and there are probably other shell features
I'm not thinking of ....

[1] Would that even be possible? I'm thinking no.

[2] Or whatever the right term is -- I'm thinking the Bourne-shell
feature whereby one can "nest" one command, enclosed in backticks,
within another, e.g.,

echo "The date is `date`"
 
R

Richard Bos

Denis McMahon said:
I think it's got nothing to do with the compiler, and everything to do
with how the cli or gui concerned prepares the parameters it invoking
main with.

Surprisingly (well, it surprised me), this is indeed the case. Under old
command.coms (it's obviously a M$ CLI the OP is using), the CLI did no
argument massaging at all. Various implementations would do (or not do,
or only do if you linked certain non-Standard libs) different kinds of
argument processing.
Under Windows (at least under XP, which is what I tested it under), both
cmd.exe and command.com do _some_ argument processing, including the
behaviour the OP noted. Still no globbing, though. A quick test compiled
with two different Windows implementations and one M$-DOS one shows that
one of the former does globbing of its own, but neither CLI does.

The most surprising thing about this, IMO, is that even command.com has
been changed from its old behaviour. I'd have expected cmd.exe to have
the new behaviour, and command.com to have kept the old.

Of course, as has already been noted, according to the Standard this is
all perfectly OK. In fact, it serves as a good example of why the
Standard couldn't reasonably specify argument processing any more
precisely: if even CLIs from the same vendor, and implementations
running under the same OS, can vary like this, how can you mandate any
specific behaviour?

Richard
 
S

Seebs

Brampton's lew pitcher, late of TDBank, is a person whose posts
are not off-topic spam, unlike mine.

Right you are. So why do you keep posting off-topic garbage no one cares
about under a top-secret anonymous name?

Allegations you don't have the guts to stand behind are just another way
of saying "false allegations". Your posts on this topic have done nothing
but establish, convincingly, that he's an innocent victim of an internet
nutjob.

But please, go right ahead and continue telling anyone who reads Usenet
that you're an anonymous idiot trying to throw mud! Might I recommend,
though, that you direct your posts to alt.test, where they will get a
readership that cares more?

-s
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,816
Messages
2,569,706
Members
45,495
Latest member
cberns21

Latest Threads

Top