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

Groups > comp.os.linux.misc > #7746 > unrolled thread

Is bash.sh compiled or interpreted?

Back to article view | Back to comp.os.linux.misc

Contents

  Is bash.sh compiled or interpreted? Avoid9Pdf@gmail.com - 2013-04-03 20:11 +0000
    Re: Is bash.sh compiled or interpreted? J G Miller <miller@yoyo.ORG> - 2013-04-03 21:10 +0000
      Re: Is bash.sh compiled or interpreted? The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 22:34 +0100
        Re: Is bash.sh compiled or interpreted? unruh <unruh@invalid.ca> - 2013-04-04 04:40 +0000
          Re: Is bash.sh compiled or interpreted? Allodoxaphobia <knock_yourself_out@example.net> - 2013-04-04 14:01 +0000
      Re: Is bash.sh compiled or interpreted? Avoid9Pdf@gmail.com - 2013-04-04 19:12 +0000
        Re: Is bash.sh compiled or interpreted? Richard Kettlewell <rjk@greenend.org.uk> - 2013-04-04 20:43 +0100
          Re: Is bash.sh compiled or interpreted? orcus@pwr.wroc.pl - 2013-04-05 03:43 +0000
            Re: Is bash.sh compiled or interpreted? Jerry Peters <jerry@example.invalid> - 2013-04-05 19:54 +0000
        Re: Is bash.sh compiled or interpreted? unruh <unruh@invalid.ca> - 2013-04-04 22:55 +0000
          Re: Is bash.sh compiled or interpreted? Richard Kettlewell <rjk@greenend.org.uk> - 2013-04-05 09:12 +0100
            Re: Is bash.sh compiled or interpreted? unruh <unruh@invalid.ca> - 2013-04-05 16:35 +0000
              Re: Is bash.sh compiled or interpreted? Richard Kettlewell <rjk@greenend.org.uk> - 2013-04-05 17:50 +0100
          Re: Is bash.sh compiled or interpreted? J G Miller <miller@yoyo.ORG> - 2013-04-05 16:02 +0000
            Re: Is bash.sh compiled or interpreted? Jerry Peters <jerry@example.invalid> - 2013-04-05 19:58 +0000
          Re: Is bash.sh compiled or interpreted? Unknown <dog@gmail.com> - 2013-04-05 19:44 +0000
            Re: Is bash.sh compiled or interpreted? Jerry Peters <jerry@example.invalid> - 2013-04-05 19:51 +0000
        Re: Is bash.sh compiled or interpreted? Surinder <Surinder.Singh@example.net> - 2013-04-09 11:20 +0530
    Re: Is bash.sh compiled or interpreted? Joe Beanfish <joebeanfish@nospam.duh> - 2013-04-08 14:37 +0000
      Re: Is bash.sh compiled or interpreted? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-04-08 21:08 +0300

#7746 — Is bash.sh compiled or interpreted?

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.
 

[toc] | [next] | [standalone]

#7747

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.

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

#7750

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.

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

#7757

["Followup-To:" header set to comp.os.linux.misc.]
On 2013-04-03, The Natural Philosopher <tnp@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.

>
> probably written in C, and compiled :-)
>
>
>

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

#7761

Awkward phrasing all way 'round...

On Thu, 04 Apr 2013 04:40:31 GMT, unruh wrote:
> ["Followup-To:" header set to comp.os.linux.misc.]
> On 2013-04-03, The Natural Philosopher <tnp@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?

There is no "bash.sh", unless you create such a file (for what purpose, 
only you know.)
  :
  |$ locate bash.sh
  |$ locate bash | grep bin
  |/bin/bash

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

Scripts are all interpreted (executed) by bourne shell, bash shell, 
ksh, zsh, csh, tcsh, etc.


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

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

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

#7764

In article <kji5s8$31t$5@dont-email.me>, J G Miller <miller@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:
<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? 

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

#7765

Chris Glur writes:
>J G Miller <miller@yoyo.ORG> wrote: 
>> 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:
> <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.

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/

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

#7768

On 2013-04-04, Richard Kettlewell <rjk@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

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

#7784

In comp.os.linux.networking orcus@pwr.wroc.pl wrote:
> On 2013-04-04, Richard Kettlewell <rjk@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

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

#7767

On 2013-04-04, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
> In article <kji5s8$31t$5@dont-email.me>, J G Miller <miller@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? 
>

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

#7769

unruh <unruh@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/

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

#7778

On 2013-04-05, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> unruh <unruh@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.

You are of course correct, but, for the discussion, 
 I would consider a fork a "new version" but that's fine. I doubt
that the detail would be of interest to the OP. 


>

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

#7779

unruh <unruh@invalid.ca> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> unruh <unruh@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.
>
> You are of course correct, but, for the discussion, 
>  I would consider a fork a "new version" but that's fine. I doubt
> that the detail would be of interest to the OP. 

The distinction isn’t academic.  A key way in which it’s distinct from
starting a ‘new’ Bash is that nonexported variables retain their values.

    $ x=1; (echo $x)
    1
    $ x=1; bash -c 'echo $x'

    $

The OP keeps asking for mental model help, so misleading descriptions
probably aren’t a good idea.

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

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

#7776

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

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

#7786

In comp.os.linux.networking J G Miller <miller@yoyo.org> wrote:
> 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.?

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

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

#7782

On Thu, 04 Apr 2013 22:55:05 +0000, unruh wrote:

> On 2013-04-04, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
>> In article <kji5s8$31t$5@dont-email.me>, J G Miller <miller@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".

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

#7783

In comp.os.linux.networking Unknown <dog@gmail.com> wrote:
> On Thu, 04 Apr 2013 22:55:05 +0000, unruh wrote:
> 
>> On 2013-04-04, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
>>> In article <kji5s8$31t$5@dont-email.me>, J G Miller <miller@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".
> 

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

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

#7819

Avoid9Pdf@gmail.com wrote:
> In article <kji5s8$31t$5@dont-email.me>, J G Miller <miller@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:
> <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? 
> 

Avoid9Pdf,

The main difference between compiled vs interpreted is whether you need 
a compiler to make executable of you source or not.

Interpreted pragramming language vs compilted programming language is 
different ballgame. e.g compiled pascal or interpreted pascal.

A shell script is not required to be converted into executable code.
A shell like bash would have two kinds of commands. built-in and
other programs.
read is built-in commands to read a line from a file
"ls" is just another program that can be used in shell script.

The constructs like "for" "if--then--endif" gets you do logical processing.


In compiled caes.
write source code in editor -->then compile --> then execute the binary

In Interpreted case.
write source code in editor ------------------> execute the script.

Once loaded in memory, shell would keep all variables available (after 
their first invocation) and you can have loops or if-blocks.

So its not run a line, move to another line, run it without holding 
context across lines.

when you are typing "ls" "ps" kind of commands on command line of bash,
you are giving one line at time for execution.
when you do
export APP=mygoodapp
the variable APP stays in memory for the next lines (and even the new 
programs started from this shell).


- Surinder

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

#7806

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.

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

#7810

On 8.4.13 5:37 , Joe Beanfish wrote:
> 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.
>


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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web