[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: is there such a thing as "bytecode" for bash scripts? à la java "bytecode"? ...



On Sun, Sep 14, 2025 at 09:56:15 -0700, Mike Castle wrote:
> If you do the same thing in a loop:
> 
> 
> while true; do
>   echo "tom"
>   sleep 1
> done
> 
> It does not seem to reread.

That's because of how the bash parser works.  Compound commands (which
include while loops) are read, parsed and executed all at once.  Bash
doesn't re-read the input file during the loop's execution.  It won't
re-read the input file until the loop terminates (this one won't, but
in general, most loops do terminate).

> But for a sourced file, it does not appear to reread the sourced file.

I'm... not sure about that case.

> I did not try all variations, like functions and what not.

Function definitions count as compound commands, so the whole function
definition is read, parsed, and stored in memory as a single step.
Reading the input continues after that.

> This is all likely documented, but spending less than 10 seconds in
> bash's info doc, I did not find it.  But this is all probably by POSIX
> spec.

Um... it's complicated.  POSIX partially specifies some of this behavior,
but certain decisions are shell-specific.

Going from memory (I don't feel like doing the research right now),
POSIX requires shells to seek to a previously saved position in the input
file (script), or to behave as if they'd done so, at specific points.
It has something to do with here documents, if I remember correctly.

If you're really going this deep into the bash implementation details,
debian-user is not the best place to do so.  I suggest that you consider
subscribing to the bug-bash and help-bash mailing lists.  There are
actual shell developers on those.

As a shell *user*, my recommendation is that you simply be aware of these
issues, and take them into consideration when you modify shell scripts
that might be currently running.  In-place modification of a script
being executed is extremely dangerous, because the shell is quite likely
to end up seeking to the middle of a command and executing that partial
command.  You want to ensure that the new script uses a new file/inode,
which new instances of the program will read, while existing instances
continue reading the previous file/inode.


Reply to: