Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #798 > unrolled thread

magic/absurd bash interpreter/compiler ?

Back to article view | Back to comp.compilers

Contents

  magic/absurd bash interpreter/compiler ? Avoid9Pdf@gmail.com - 2012-12-23 11:04 +0000
    Re: magic/absurd bash interpreter/compiler ? J G Miller <miller@yoyo.ORG> - 2012-12-24 00:28 +0000
    Re: magic/absurd bash interpreter/compiler ? "Jonathan Thornburg" <jthorn@astro.indiana.edu> - 2012-12-24 03:57 +0000
    Re: magic/absurd bash interpreter/compiler ? Eric <eric@deptj.eu> - 2012-12-24 19:13 +0000
      Re: magic/absurd bash interpreter/compiler ? Barry Margolin <barmar@alum.mit.edu> - 2012-12-24 20:48 -0500
      Re: magic/absurd bash interpreter/compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-25 03:25 +0000
        Re: magic/absurd bash interpreter/compiler ? Eric <eric@deptj.eu> - 2012-12-26 12:51 +0000
          Re: magic/absurd bash interpreter/compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-28 03:17 +0000
            Re: magic/absurd bash interpreter/compiler ? Barry Margolin <barmar@alum.mit.edu> - 2012-12-28 10:25 -0500

#798 — 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]

[toc] | [next] | [standalone]

#799

On Sunday, December 23rd, 2012, at 11:04:07h +0000,
Chris Glurr burbled:

> We need a rigorous/formal syntax for computing.

Have you considered the Z formal specification notation,

  <http://formalmethods.wikia.COM/wiki/Z_notation>

now an ISO standard -- ISO/IEC 13568:2002

  <http://www.iso.ORG/iso/catalogue_detail.htm?csnumber=21573>

You can buy your own copy at a mere CHF 238 (approximately ZAR 2320).

[toc] | [prev] | [next] | [standalone]

#800

In comp.compilers Avoid9Pdf@gmail.com wrote:
> But this bash nonsense is infuriating me!  We
> need a rigorous/formal syntax for computing.
[[...]]
> 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.

If you want a shell with a well-defined formal structure, you might
find  rc  of interest.  It uses a YACC (i.e., LALR(1)) parser.  As usual,
Wikipedia has a reasonable intro with links to more information:
http://en.wikipedia.org/wiki/Rc

--
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn@astro.indiana-zebra.edu>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

[toc] | [prev] | [next] | [standalone]

#802

On 2012-12-23, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
> 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.

Why on earth would you expect all computer languages to parse with a
single pass from left to right? Neither Pascal nor Forth is a typical
computer language. Pascal has more-or-less the sort of parser you seem
to think should be universal, Forth does not! Bash (like other shells)
is an interactive command-line based user interface which can also be
used to write scripts, and it has evolved over many years, so why would
it be like that?

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

Bash has to use multiple passes and be recursive because of substitutions
and compound commands like "while" in the example. What it does, and in
what order, is actually in the man page. Redirects are picked out early,
and can actually be anywhere in the command line for a simple command, but
are more limited in a compound command. They are used last, just before
actual execution. There is no way that input/output is ever unspecified.

> 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?

Normal/proper syntax is exactly what you expect it to be? I doubt it.
There is no "normal", and "proper" can be a matter of opinion.

So many questions, on so many forums, are from people who expect the
language they are learning to be just like one they have already learnt.
The main thing that these people need to learn is to _not_ do that. You
can probably achieve the same results with the new language, but probably
not in an exactly analogous way.

Eric
--
ms fnd in a lbry
[I've had a lot of questions from people who seem unclear on the
difference between an interpreter and a compiler, and get confused as
soon as the language gets complex enough that it can't be handled a
line at a time by read-parse-interpret.  Most languages I know can indeed
be parsed in a single left to right pass, but all you have at that point
is a parse tree, with a lot of the compiler's work left to do. -John]

[toc] | [prev] | [next] | [standalone]

#803

In article <12-12-018@comp.compilers>, Eric <eric@deptj.eu> wrote:

> So many questions, on so many forums, are from people who expect the
> language they are learning to be just like one they have already learnt.
> The main thing that these people need to learn is to _not_ do that. You
> can probably achieve the same results with the new language, but probably
> not in an exactly analogous way.

Good point. I answered a question on Stack Overflow about PHP's $_POST
variable; variables like this are called superglobals in the PHP
documentation. The poster said that "superglobal" should mean that the
value is shared by all scripts, because his intuitive interpretation of
the term means that its scope should be wider than an ordinary global
variable. Never mind that this is not actually a common computer term,
the PHP designers coined it themselves to refer to their particular use
(these variables are "super" because they're automatically visible in
functions and methods, you don't have to use the "global" declaration).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

[toc] | [prev] | [next] | [standalone]

#804

In comp.compilers Eric <eric@deptj.eu> wrote:

(snip)
> Why on earth would you expect all computer languages to parse with a
> single pass from left to right? Neither Pascal nor Forth is a typical
> computer language. Pascal has more-or-less the sort of parser you seem
> to think should be universal, Forth does not! Bash (like other shells)
> is an interactive command-line based user interface which can also be
> used to write scripts, and it has evolved over many years, so why would
> it be like that?

(snip, our moderator wrote)
> [I've had a lot of questions from people who seem unclear on the
> difference between an interpreter and a compiler, and get confused as
> soon as the language gets complex enough that it can't be handled a
> line at a time by read-parse-interpret.  Most languages I know can indeed
> be parsed in a single left to right pass, but all you have at that point
> is a parse tree, with a lot of the compiler's work left to do. -John]

There are many interpreted languages that pretty much can't be
compiled, at least in the usual sense of compilation. Especially in
shell languages, but also ones like TeX and Mathematica, where you can
expand variables to be keywords that are then parsed.

I once wrote self-modifying code in Mathematica. Someone wanted, in
the and, a Mathematica notebook with all the results and graphs, but
not with the Mathematica code. I wrote the code that asks the front
end to delete the code from the notebook. (Be sure to save before
testing during debugging.)

TeX has \expandafter which allows for run-time generation of names of
macros to execute.

One problem with many unix shells is that redirection is done too early.
Specifically, before an if test is done.

-- glen

[toc] | [prev] | [next] | [standalone]

#805

On 2012-12-25, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> One problem with many unix shells is that redirection is done too early.
> Specifically, before an if test is done.

I am tempted to think that this is a conceptual misunderstanding, so an
example would be useful.

Eric
--
ms fnd in a lbry

[toc] | [prev] | [next] | [standalone]

#809

In comp.compilers Eric <eric@deptj.eu> wrote:

(snip, I wrote)
>> One problem with many unix shells is that redirection is done too early.
>> Specifically, before an if test is done.

> I am tempted to think that this is a conceptual misunderstanding, so an
> example would be useful.

From the man page for csh:

  "The single-command form of if does output redirection even if the
   expression is false and  the  command is not executed."

echo false > file
if( 1 > 2 ) echo true > file

The if statement will open (and truncate) file before
testing the condition. At least for csh, I didn't try others.

-- glen
[That's one of the many, many bugs in csh.  In posix shells such as
sh and bash, they do what you'd expect:

if [ 1 \> 2 ]; then echo true > file; fi   # doesn't create the file
if [ 1 \> 2 ]; then echo true; fi > file   # does create it

-John]

[toc] | [prev] | [next] | [standalone]

#813

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> In comp.compilers Eric <eric@deptj.eu> wrote:
>
> (snip, I wrote)
> >> One problem with many unix shells is that redirection is done too early.
> >> Specifically, before an if test is done.
>
> > I am tempted to think that this is a conceptual misunderstanding, so an
> > example would be useful.
>
> From the man page for csh:
>
>   "The single-command form of if does output redirection even if the
>    expression is false and  the  command is not executed."
>
> echo false > file
> if( 1 > 2 ) echo true > file
>
> The if statement will open (and truncate) file before
> testing the condition. At least for csh, I didn't try others.
>
> -- glen
> [That's one of the many, many bugs in csh.  In posix shells such as
> sh and bash, they do what you'd expect:
>
> if [ 1 \> 2 ]; then echo true > file; fi   # doesn't create the file
> if [ 1 \> 2 ]; then echo true; fi > file   # does create it
>
> -John]

csh is so broken, it's best ignored when talking about "Unix shells" in
general.  Even more so when someone says "many Unix shells", since one
exception hardly counts as "many".

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
[Several other people wrote to agree that csh is bad news. -John]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web