Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is bash.sh compiled or interpreted?

170 views
Skip to first unread message

Avoi...@gmail.com

unread,
Apr 3, 2013, 4:11:33 PM4/3/13
to
My previous query has exposed much of my confusion.
Pascal B's smpt.sh:-----------
...<initialise variables>
cat>$message
(
read line 0<&3 ; $trace "$line">$log
case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
echo "HELO $local_name" 1>&3
read line 0<&3 ; $trace "$line">$log
case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
echo "MAIL FROM: <${from}>" 1>&3
...
echo "QUIT" 1>&3
) 3<>/dev/tcp/$smtp_server/25
-----------------------

Is it right that FD3 is bound to "/dev/tcp/$smtp_server/25"
only at the last line of the script, whereas FD3 is USED
in previous lines;
so that the complete script must be compiled before the
<implementing code> is generated ?

So that this presents a very unnatural mental model for users
who are used to scientific or legal thinking, where the text
can be confirmed as being valid at intermediate stages?
----
Per Joe Beanfish;
cat>$message
means 'read from stdin and write that to File:message'.

Is this completed before the (instruction-sequence starts),
because `read line` will use stdin?
So what's the point of `cat>$message` ?
Is it just to write a little introduction, before the actual task
starts?

Do readers understand the WHOLE script as implementing
a mail-client -- other than just snippets?
And how it would it be decomposed into testable parts?

What are possible successive refinement versions of test
scripts for this task. I.e the 'hello world model' must be used.
Ie. each version must be stand-alone-complete, and
extended by later versions.

== TIA.






J G Miller

unread,
Apr 3, 2013, 5:10:33 PM4/3/13
to
On Wednesday, April 3rd, 2013 20:11:33 +0000, Chris Glur pondered:

> Is bash.sh compiled or interpreted?

Bourne shell, bash shell, ksh, zsh, csh, tcsh etc scripts
are all interpreted.

In your Bourne shell script put ``set -x'' at the top after the line

#! /bin/sh
set -x

and you will see the script executed, line by line.

The Natural Philosopher

unread,
Apr 3, 2013, 5:34:15 PM4/3/13
to
On 03/04/13 22:10, J G Miller wrote:
> On Wednesday, April 3rd, 2013 20:11:33 +0000, Chris Glur pondered:
>
>> Is bash.sh compiled or interpreted?
>
> Bourne shell, bash shell, ksh, zsh, csh, tcsh etc scripts
> are all interpreted.
>

no, they are all interpreters.

probably written in C, and compiled :-)



--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

unruh

unread,
Apr 4, 2013, 12:40:31 AM4/4/13
to
["Followup-To:" header set to comp.os.linux.misc.]
On 2013-04-03, The Natural Philosopher <t...@invalid.invalid> wrote:
> On 03/04/13 22:10, J G Miller wrote:
>> On Wednesday, April 3rd, 2013 20:11:33 +0000, Chris Glur pondered:
>>
>>> Is bash.sh compiled or interpreted?
>>
>> Bourne shell, bash shell, ksh, zsh, csh, tcsh etc scripts
>> are all interpreted.
>>
>
> no, they are all interpreters.

No, the scripts are interpreted. The programs themselves are compiled
but the scripts are interpreted.

Avoi...@gmail.com

unread,
Apr 4, 2013, 3:12:10 PM4/4/13
to
Without testing it:
<statements/commands> can extend over lines,
so <lines> can't execute atomically.

Since the <statements/commands> are potentially
nested, that further precludes line by line execution.

PLEASE boys! focus on the specific smtp.sh

cat>/mesgFile
(
read line 0<&3 ; echo "$line">$log case "$line" in 2*) ;; *) echo
"QUIT" 1>&3 ; exit 0 ;; esac echo "HELO $local_name" 1>&3
...55 similar lines ...
) 3<>/dev/tcp/$smtp_server/25

Based on Joe Beanfish's input,
it seems that the '(bracketed lines)' constitute a
nested-statement.

My main concern is whether the redirection: `3<>...`
'belongs' to the '(bracketed lines)' SPECIFICALLY.
And if so I'm waiting for a comment on my observation
that since the () could be a zilllion lines, it's a crappy
syntax to have the 'initialisation' at the END.

And obviously the script can't interpret/run line-by-line,
because it can't know what to do until the last line -- in
this case.

WDYS?

Richard Kettlewell

unread,
Apr 4, 2013, 3:43:03 PM4/4/13
to
The relevant productions in the SUS version of the grammar[1] are:

command : simple_command
| compound_command
| compound_command redirect_list
| function_definition
;
compound_command : brace_group
| subshell
| for_clause
| case_clause
| if_clause
| while_clause
| until_clause
;
subshell : '(' compound_list ')'
;
redirect_list : io_redirect
| redirect_list io_redirect
;
io_redirect : io_file
| IO_NUMBER io_file
| io_here
| IO_NUMBER io_here
;
io_file : '<' filename
| LESSAND filename
| '>' filename
| GREATAND filename
| DGREAT filename
| LESSGREAT filename
| CLOBBER filename
;

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10

> And if so I'm waiting for a comment on my observation
> that since the () could be a zilllion lines, it's a crappy
> syntax to have the 'initialisation' at the END.

It is what it is. If you don’t like it, I suggest using some different
language with syntax more to your taste.

> And obviously the script can't interpret/run line-by-line,
> because it can't know what to do until the last line -- in
> this case.

Yes, obviously. So what? That’s true of lots of languages.

--
http://www.greenend.org.uk/rjk/

unruh

unread,
Apr 4, 2013, 6:55:05 PM4/4/13
to
On 2013-04-04, Avoi...@gmail.com <Avoi...@gmail.com> wrote:
> In article <kji5s8$31t$5...@dont-email.me>, J G Miller <mil...@yoyo.ORG> wrote:
>
>> On Wednesday, April 3rd, 2013 20:11:33 +0000, Chris Glur pondered:
>>
>> > Is bash.sh compiled or interpreted?
>>
>> Bourne shell, bash shell, ksh, zsh, csh, tcsh etc scripts
>> are all interpreted.
>>
>> In your Bourne shell script put ``set -x'' at the top after the line
>>
>> #! /bin/sh
>> set -x
>>
>> and you will see the script executed, line by line.
>
> Without testing it:

Perhaps you should test it and see what happens? Why in the world are
you theorizing about how it works, when an experiment (see above) is so
so easy to carry out.


><statements/commands> can extend over lines,
> so <lines> can't execute atomically.


>
> Since the <statements/commands> are potentially
> nested, that further precludes line by line execution.

No it does not.


>
> PLEASE boys! focus on the specific smtp.sh

You are the one interested in figuring it out, but you are unwilling to
put in any effort to learn. Why should anyone else waste any time on it?


>
> cat>/mesgFile
> (
> read line 0<&3 ; echo "$line">$log case "$line" in 2*) ;; *) echo
> "QUIT" 1>&3 ; exit 0 ;; esac echo "HELO $local_name" 1>&3
> ...55 similar lines ...
> ) 3<>/dev/tcp/$smtp_server/25
>
> Based on Joe Beanfish's input,
> it seems that the '(bracketed lines)' constitute a
> nested-statement.

No.

for bash, parentheses around a set of commands means "start up an new
version of bash and feed the commands in the parentheses to that new
version of bash to interpret and execute.



>
> My main concern is whether the redirection: `3<>...`
> 'belongs' to the '(bracketed lines)' SPECIFICALLY.

It "belongs" to that new version of bash that is started by the
parentheses.

> And if so I'm waiting for a comment on my observation
> that since the () could be a zilllion lines, it's a crappy
> syntax to have the 'initialisation' at the END.

Initialisation of what?
And the above would be a crappy way of writing a shell script in bash,
for exactly the reason you indicate. And if it really were a zillion
lines, you would run out of memory to hold the program, and your system
would first swap itself to death, and then perhaps crash. On the other
hand, if you stuck those zillion commands into a file, bash could then
do the redirections and read the lines one at a time.


>
> And obviously the script can't interpret/run line-by-line,
> because it can't know what to do until the last line -- in
> this case.

No. It would read in everthing between the parentheses stick it into
temporary storage until it got to the end of the implicit bash command,
did the redirection, and then went through the program line by line and
interpreted it.


>
> WDYS?
>

or...@pwr.wroc.pl

unread,
Apr 4, 2013, 11:43:19 PM4/4/13
to
On 2013-04-04, Richard Kettlewell <r...@greenend.org.uk> wrote:
> Chris Glur writes:
>> And if so I'm waiting for a comment on my observation
>> that since the () could be a zilllion lines, it's a crappy
>> syntax to have the 'initialisation' at the END.
>
> It is what it is. If you don’t like it, I suggest using some different
> language with syntax more to your taste.

Or put () in file, remove redirections and use exec to open fds.

--
Pozdrawiam
orcus

Richard Kettlewell

unread,
Apr 5, 2013, 4:12:08 AM4/5/13
to
unruh <un...@invalid.ca> writes:
> for bash, parentheses around a set of commands means "start up an new
> version of bash and feed the commands in the parentheses to that new
> version of bash to interpret and execute.

It doesn’t “start a new version of Bash” or “feed” commands to it. Bash
forks but does not exec. You can readily verify this with strace.

--
http://www.greenend.org.uk/rjk/

J G Miller

unread,
Apr 5, 2013, 12:02:58 PM4/5/13
to
On Thursday, April 4th, 2013, at 22:55:05h +0000, UnRuh asked:

> Perhaps you should test it and see what happens?

It is below the dignity of persons of such high station to
waster their time testing things when they could be using
that time to think up even more esoteric questions related
to impractical scenarios to pose.

And the houseboy/maid is too busy with other menial chores
to do the testing.

> Why should anyone else waste any time on it?

For the satisfaction of helping one of the world's most eminent
and revered Usenet personalities.

If in doubt, remember the words of Jacob Zuma --

"We worked together on many things.
We were helping each other.
We also worked together underground.”

Unknown

unread,
Apr 5, 2013, 3:44:54 PM4/5/13
to
On Thu, 04 Apr 2013 22:55:05 +0000, unruh wrote:

> On 2013-04-04, Avoi...@gmail.com <Avoi...@gmail.com> wrote:
>> In article <kji5s8$31t$5...@dont-email.me>, J G Miller <mil...@yoyo.ORG>
>> wrote:
>>> and you will see the script executed, line by line.
>>
>> Without testing it:
>
> Perhaps you should test it and see what happens? Why in the world are
> you theorizing about how it works, when an experiment (see above) is so
> so easy to carry out.
>
>
>><statements/commands> can extend over lines,
>> so <lines> can't execute atomically.
>
>> Since the <statements/commands> are potentially nested, that further
>> precludes line by line execution.
>
> No it does not.
>
>
>> PLEASE boys! focus on the specific smtp.sh
>
> You are the one interested in figuring it out, but you are unwilling to
> put in any effort to learn. Why should anyone else waste any time on it?
>
If I told you that fairy-cinderella was hovering behind your back, would
you turn around to see?

Why can't somebody see the [pasted repeatedly] task whole-istically, and
propose a test sequence which demonstrates that/how it works. eg. the
'hello world concept' gives a fully demonstrable example, which is
extended, but which is testable from version1.

Instead of all standing around, saying "that's oxygen, that's hydrogen,
that's carbon ...., but nobody can tell "that's a horse, which can be
tested/confirmed by x,y,z".

Jerry Peters

unread,
Apr 5, 2013, 3:51:45 PM4/5/13
to
Because your question makes no sense. You have no clue how bash works,
yet you keep theorizing and asking *other* people to confirm your
endless theories. Bash is open source, if you're so concerned as to
how it works, get the source code and *read* it.

Jerry

Jerry Peters

unread,
Apr 5, 2013, 3:54:27 PM4/5/13
to
In comp.os.linux.networking or...@pwr.wroc.pl wrote:
> On 2013-04-04, Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Chris Glur writes:
>>> And if so I'm waiting for a comment on my observation
>>> that since the () could be a zilllion lines, it's a crappy
>>> syntax to have the 'initialisation' at the END.
>>
>> It is what it is. If you don?t like it, I suggest using some different
>> language with syntax more to your taste.
>
> Or put () in file, remove redirections and use exec to open fds.
>

You don't need to go that far, put the code in a function definition,
call the function inside a subshell, with the necessary redirections.

Jerry

Jerry Peters

unread,
Apr 5, 2013, 3:58:45 PM4/5/13
to
> We also worked together underground.?

He's not the worst, though. There was some clown on one of the Python
lists who kept insisting that people needed to quit telling him that
what he wanted to do was impossible and just tell him how to do it!

Jerry

Joe Beanfish

unread,
Apr 8, 2013, 10:37:10 AM4/8/13
to
On Wed, 03 Apr 2013 20:11:33 +0000, Avoid9Pdf wrote:
> My previous query has exposed much of my confusion.
> Pascal B's smpt.sh:-----------
> ...<initialise variables>
> cat>$message
> (
> read line 0<&3 ; $trace "$line">$log case "$line" in 2*) ;; *) echo
> "QUIT" 1>&3 ; exit 0 ;; esac echo "HELO $local_name" 1>&3 read line
> 0<&3 ; $trace "$line">$log case "$line" in 2*) ;; *) echo "QUIT"
> 1>&3 ; exit 0 ;; esac echo "MAIL FROM: <${from}>" 1>&3
> ...
> echo "QUIT" 1>&3
> ) 3<>/dev/tcp/$smtp_server/25 -----------------------
>

() is a sub process. Very similar (but not identical) to having everything
in between in a separate script file and running
otherscript 3<>/dev/tcp/$smtp_server/25
Read the bash man page section "Compound Commands"

Depending on desired side-effects that code could also be put into
a function then call that function instead of putting it inline. e.g.

dosmtp(){
read line 0<&3 ...
}

cat >$message
dosmtp 3<>/dev/tcp/$smtp_server/25

> Is it right that FD3 is bound to "/dev/tcp/$smtp_server/25"
> only at the last line of the script, whereas FD3 is USED in previous
> lines;
> so that the complete script must be compiled before the <implementing
> code> is generated ?
> So that this presents a very unnatural mental model for users who are
> used to scientific or legal thinking, where the text can be confirmed as
> being valid at intermediate stages?

(), external command, and function call are all functional units that
may have their I/O redirected.

It doesn't help at all to debate the semantics of a language that's
been around for 30+. It works how it works and it's not going to change.
You have 2 choices:
1) Learn to deal with how it works regardless of how you want it to.
2) Move on.

> ----
> Per Joe Beanfish;
> cat>$message
> means 'read from stdin and write that to File:message'.
>
> Is this completed before the (instruction-sequence starts), because
> `read line` will use stdin?
> So what's the point of `cat>$message` ?
> Is it just to write a little introduction, before the actual task
> starts?

The "cat" is but one part of a larger script obviously. That script
is presumably given the mail message on stdin. Possibly like this
somescript <someMessageFile
or
somethingElse | somescript
or
somescript
(user types the message then hits ^D)
or
etc.

cat >$message

will take all of that input and write it to the filename in $message.
Then processing will continue with the subsequent line(s).
In the snippet provided above the message saved in the file is not used.

> Do readers understand the WHOLE script as implementing a mail-client --
> other than just snippets?
> And how it would it be decomposed into testable parts?
>
> What are possible successive refinement versions of test scripts for
> this task. I.e the 'hello world model' must be used.
> Ie. each version must be stand-alone-complete, and extended by later
> versions.

This is what programmers do. You can't expect to be taught how to program
and debug on usenet. Read books or take a course.

Tauno Voipio

unread,
Apr 8, 2013, 2:08:18 PM4/8/13
to
Chris,

Do you ever read the manuals?

Please stop morphing your send identifiers. A consistent net identity
increases your probability of getting useful responses.

--

-T.

0 new messages