This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] AmigaOS 4 port contribution


zack@codesourcery.com (Zack Weinberg)  wrote on 07.10.03 in <87he2k4s0i.fsf@codesourcery.com>:

> DJ Delorie <dj@redhat.com> 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
> vectors.

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.)

MfG Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]