On Wed, Apr 21, 2021 at 3:10 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On Wed, 21 Apr 2021 at 20:40, Peng Yu wrote: > > > > On Wed, Apr 21, 2021 at 2:22 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> > wrote: > > > It would probably be possible, but it would not be practical (as > mentioned, not all systems that GCC runs on have a good shell). The GCC > drivers do a lot more than just launch other processes, so "shell scripts > are good for launching other processes" isn't a good enough reason to do > it. Also "shell scripts are easier to maintain" is subjective, > > > > This is a general conclusion from the first principle. As long as the > > purpose is to glue things, shell should be by definition better (given > > the misconceptions that need to avoided when using shell). > > You are assuming its purpose is just "to glue things". No. That is not my assumption. I am saying for the part that is suitable for gluing, a shell is better used. For the part that is not suitable for gluing, it can stay in C. It does > non-trivial processing of command-line arguments and config files, as > well as translating diagnostic messages to different languages. It's > all possible in shell, but that doesn't mean it's the best solution > for a complex, cross-platform program. Nobody is saying it's > impossible. But you're stating it would be better with no evidence > (just general statements about shell programming, that may or may not > be relevant to the GCC driver programs). > > > Also, if bash is used and if you really want to have C-like > > performance for some time-costly parts, bash builtins can be made, as > > bash builtins are just shared libraries which are C-like fast by > > definition. However, if there is anything binary in nature is better > > to hide them from bash, as bash natively is not good at dealing with > > binary data. > > Not everybody who uses GCC has bash installed. There are other shells, > including simpler ones without features found in bash. > -- Regards, Peng
