This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] AmigaOS 4 port contribution
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 08 Oct 2003 08:48:00 +0200
- Subject: Re: [PATCH] AmigaOS 4 port contribution
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <email@example.com> <firstname.lastname@example.org> <200310071612.h97GCAf26666@greed.delorie.com> <200310071612.h97GCAf26666@greed.delorie.com> <email@example.com>
firstname.lastname@example.org (Zack Weinberg) wrote on 07.10.03 in <email@example.com>:
> DJ Delorie <firstname.lastname@example.org> writes:
> > As for your hidden agenda to discredit all OSs that do not follow The
> > Unix Way, consider one of the points the Unix Hater's Handbook
> > addresses:
> > find . -name *.c -print
> > The fact that the application has absolutely no control over how the
> > command line is interpreted is IMHO one of the worst "features" unix
> > forces on its users. DJGPP applications, OTOH, can choose how much
> > automatic processing the command line gets.
> You may be surprised to hear that I agree with this (with caveats
> having to do with being able to tell the difference between a file
> literally named "*.c" and a wildcard argument). But this is totally
> orthogonal to the question of argument strings versus argument
Strictly as an aside, the best idea so far that I have seen for this was
under MPW, where a command can have an externally-accessible data
structure (in the resource fork in this case, of course) that describes
the arguments it wants to see in enough detail to enable the shell to put
up a GUI dialogue to ask for them. Obviously, the same information could
be used for command completion, or even for parsing arguments in a
suitably defined command language. (I don't recall now if there are
options to escape to custom code; if so, *that* part wouldn't be ok "in
the wild" as it would make it too easy to make the shell execute malicious
code.) Sort of a shell-visible, enriched getopt.
As for why the C main() interface ... well, an option to hand over richer
data than just strings wouldn't be bad, as long as there still is the
option to hand over strings. Sometimes, what you want just doesn't fit in
whatever interface was preconceived. On the other hand, the option to
*return* more than an 8 bit integer would be much appreciated. (Many (not
all) instances of piping could be eliminated if, for example, it were
possible to return a string.)