magic/absurd bash interpreter/compiler ?

It's OK if your dog doesn't KNOW how he catches a ball, or even if you
don't know the algorithm of how you ride-a-bicycle, provided you can
instinctively do it. But this bash nonsense is infuriating me! We
need a rigorous/formal syntax for computing.


http://wiki.bash-hackers.org/howto/redirection_tutorial
    writes:
> Let's see another use case. We want to read a file line by line,
> this is easy, we just do:
>
> while read -r line;do echo "$line";done < file
----
Well, I have some experience in building compilers, eg. augumented
FiniteStateMachine: where the PASCAL-like syntax-railway-diagrams are just
drawn and the diagram has the corresponding action for the received token
which progreses past THAT node in the diagram.


And FORTH-like interpreters.


These all 'compile' from-left-to-right, with possibly one token look-ahead.


But this bash crap, seems to give a whole recursively-descendable-structure
and at the END, mentions ByTheWay <use FileIn as input>, whereas the
<InputFile> must be known at the BEGINING.


Does this thing use multiple passes. Eg. where the complete command-line
is FIRST analysed for "<", ">", and then LATER any function/s who's input
and/or output is not specified, can use the previous scan's stuff.


What kind of mental model must we develop to handle this bash syntax
which contradicts normal/proper syntax, or must we approach is like
an infant learns its first language, or like your dog catches a ball?


== TIA.
[The last time I checked, bash compiles commands into an internal form and
then interprets that.


I presume you know that bash is a modestly enhanced version of the Bourne
shell which has been part of Unix since 1977. I'd think that's been long
enough for people to get used to the syntax. It's nowhere near as bad
as the older Mashey shell. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.