exit to shell from nested function calls.

exit to shell from nested function calls.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 4945 bytes --]

Don't read this closely, there's only one thing that's relevant, see  below:


# Create a directory:
_overlay_mkdir ()
{
     # Create backup directory if it hasn't already been done.
     [ -d $1 ] && { infomsg "\"$1\" already exists."; return 0 }

     mkdir -vp $1 ||
         { errormsg "Couldn't create directory: \"$1\"." && return 1 }
     return 0
}

# Synchronize two directories:
_overlay_rsync ()
{
     actionmsg "Synching \"$1\" to \"$2\" ..."
     # greysky uses: --delete-after

     rsync -aX --del --inplace --no-whole-file $1/* $2 ||
         { errormsg "Can't rsync \"$1\" to \"$2\"." && return 1 }
     return 0
}

# Run for each directory to be overlaid:
overlay ()
{
     [[ ! "$1" || "$1" == '-h' ]] && _overlay_syntax && return 0

     # NB, this check must run before initializing OR normal run.
     # '-x' = exact match. Note, even the firefox 'can't find profile' 
error msg. box triggers this:
     [ -n "$( pgrep -x ${program} )" ] &&
     errormsg "\"${program}\" is running, please quit before 
continuing." && return 1

     actionmsg "\nInitializing overlay for \"$1\" ..."

     local subject="$1" # Full path of directory to be overlayed.

     # renamed subject dir. (must borrow real name to create link to 
overlay).
     local active="${subject}-active"
     local backup="/aMisc/Overlay$subject"    # Backup.
     local target="/run/user/0$subject"        # The overlay directory.
     local working="${target}-working"        # Used by 'mount' internally.


# Rescue if we did not unoverlay properly, as when computer is shut down 
without quitting facebook first.  If subject is a link pointing to 
target we almost surely did an improper shut down:
[[ -h "$subject" && $( readlink -m "$subject" ) == "$target" ]] &&
{
     # Recreate target:
     _overlay_mkdir ${target} || return 1
     # And remount:
     mount -vt overlay -o 
lowerdir=${active},upperdir=${target},workdir=${working} overlay 
${target} || return 1
     return 0
}

     [[ -d "$subject" ]] ||
         { errormsg "\"${subject}\" seems not to be a directory,\n but 
we can only overlay directories!"; return 1 }

     # rsync subject to the backup directory: Do this here so that we 
get the backup no matter what.  This way the pointer does not exist yet.
     _overlay_mkdir ${backup}  || return 1
     _overlay_rsync "$subject" "$backup" || return 1

#"$subject" is: |/root/.mozilla|
#"$backup" is:  |/aOverlay/root/.mozilla-backup|
#"$active" is:  |/root/.mozilla-active|
#"$target" is:  |/run/user/0/root/.mozilla|
#"$working" is: |/run/user/0/root/.mozilla-working|

     if [[ -h "$subject" &&  $( readlink -m "$subject" ) == "$target" && \
     -d "$backup" && -d "$active" && -d "$target" && -d "$working" ]]; then
             infomsg "\"${subject}\" overlay is already initialized."
     else
         # Create directories if it hasn't already been done.
         _overlay_mkdir ${target}  || return 1
         _overlay_mkdir ${working} || return 1

         # Subject directory is renamed, and ...
         mv -v "$subject" "$active" || return 1
         # ... 'subject' is now a link to overlay.
         ln -sv "$target" "$subject" ||
             { errormsg "Couldn't link \"$subject\" to \"$target\"."; 
return 1 }

         actionmsg "\nCreating overlay: lowerdir=\"$active\" 
overlay=\"$target\" ..."

         # -v = verbose, -t overlay = type is overlay.  lowerdir is 
hidden by upperdir.  workdir is internal to mount.
         mount -vt overlay -o 
lowerdir=${active},upperdir=${target},workdir=${working} overlay ${target}
     fi
     return 0
}

---------------------------------------------------------------------------------------

... the above is part of a function hierarchy can can be four levels 
deep and if there's an error (it's being debugged so there's error tests 
everywhere), I need these 'return 1 ... return 1 ... return 1 ... return 
1 ... to break back to the shell.  Now, didn't we discuss something like 
this a few months back?  ... to do with zmv ... 'err-exit' or something 
like that.  I was complaining that zmv should NOT crash -- but Bart 
pointed out that it's not a crash it's a controlled thing, of course.  
And zmv was modified accordingly IIRC.

Anyway, it occurs to me that in the above, I want the opposite -- I DO 
want any of these errors, however many levels deep it might be, to 
exit/return directly back to the shell (but 'exit' itself quits the 
shell entirely) without having to return from each level one at a time.  
As always I wish I could search the archives and dig this up, because it 
was the same issue.

'err-exit'?  Or can a trap do this? or, if it was run in a subshell then 
'exit' would return to the calling shell?


[-- Attachment #2: Type: text/html, Size: 6424 bytes --]

Re: exit to shell from nested function calls.

[Roman Perepelitsa]

On Thu, May 16, 2024 at 4:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> [...]
>
> ... the above is part of a function hierarchy can can be four
> levels deep and if there's an error (it's being debugged so there's
> error tests everywhere), I need these 'return 1 ... return 1 ...
> return 1 ... return 1 ... to break back to the shell.

I'd turn this into a script (executable file) and use exit to bail
out. IMO, anything that can be a script is better off as a script.
Programming within the interactive shell is hard enough with all the
aliases, non-standard options and whatnot. No need to inject more code
into it than necessary.

Roman.

Re: exit to shell from nested function calls.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]



On 2024-05-16 13:26, Roman Perepelitsa wrote:
> I'd turn this into a script (executable file) and use exit to bail
> out. IMO, anything that can be a script is better off as a script.
I'm slowly figuring that out.  Yes, that's the motivator I need. Coming 
from C I just sorta started writing functions cuz that's what one does in C.

Thanks Roman.

BTW, just in case you're wondering, it's an overlay for mostly firefox 
which chatters to the disk almost constantly.  Got  a newer machine 
recently and it has a SSD, but I know they have limited R/W cycles so 
I'm using the overlay to deflect the chatter to RAM. Works good so far.  
Will try it with a few other progs too, and possibly /var.  It 's 
interesting watching 'fatrace -fW' for a while -- see who's a disk 
blabbermouth.



[-- Attachment #2: Type: text/html, Size: 1321 bytes --]

Re: exit to shell from nested function calls.

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

Functions are great, and I recommend using them - just use them _inside_
the script. For anything but the most trivial scripts I make the main body
of the script a function, too, something like this:

#!/usr/bin/env zsh
main() {
    main program code here
}

sub1() {
    called by main
}

sub2() {
    called by main or sub1
}
..
... other declarations ...
...
main "$@"


Only define functions inside your interactive shell when they need to make
changes that persist after they exit - like changing directories, or
updating variable values, etc.


On Thu, May 16, 2024 at 5:30 PM Ray Andrews <rayandrews@eastlink.ca> wrote:

>
>
> On 2024-05-16 13:26, Roman Perepelitsa wrote:
>
> I'd turn this into a script (executable file) and use exit to bail
>
> out. IMO, anything that can be a script is better off as a script.
>
> I'm slowly figuring that out.  Yes, that's the motivator I need.  Coming
> from C I just sorta started writing functions cuz that's what one does in C.
>
> Thanks Roman.
>
> BTW, just in case you're wondering, it's an overlay for mostly firefox
> which chatters to the disk almost constantly.  Got  a newer machine
> recently and it has a SSD, but I know they have limited R/W cycles so I'm
> using the overlay to deflect the chatter to RAM.  Works good so far.  Will
> try it with a few other progs too, and possibly /var.  It 's interesting
> watching 'fatrace -fW' for a while -- see who's a disk blabbermouth.
>
>
>
>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 3083 bytes --]

Re: exit to shell from nested function calls.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]



On 2024-05-17 08:40, Mark J. Reed wrote:
> Functions are great, and I recommend using them - just use them 
> _inside_ the script. For anything but the most trivial scripts I make 
> the main body of the script a function, too, something like this:
>
>     #!/usr/bin/env zsh
>     main() {
>         main program code here
>     }
>
Hmmm.  So we can have it both ways -- the flow control of functions but 
it all vanishes when the script exits?  I'll experiment with that.

...
> Only define functions inside your interactive shell when they need to 
> make changes that persist after they exit - like changing directories, 
> or updating variable values, etc.
That would limit their number considerably.  Ok, goodbye functions ... I 
mean ... how do you say it?  ... functions at the 'zero level' ... not 
within a script.  Hearing the same thing from yourself and Roman seals 
the deal.



[-- Attachment #2: Type: text/html, Size: 2035 bytes --]

Re: exit to shell from nested function calls.

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Fri, May 17, 2024 at 11:58 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 2024-05-17 08:40, Mark J. Reed wrote:
>
> Functions are great, and I recommend using them - just use them _inside_
> the script. For anything but the most trivial scripts I make the main body
> of the script a function, too, something like this:
>
> #!/usr/bin/env zsh
> main() {
>     main program code here
> }
>
> Just remember the *main "$@"* at the bottom, otherwise you've got a
script that just declares some functions and exits without calling them. :)


> Only define functions inside your interactive shell when they need to make
> changes that persist after they exit - like changing directories, or
> updating variable values, etc.
>
> That would limit their number considerably.
>

Indeed. As a point of comparison, over the years I've written about a
thousand little personal utility scripts that live in my ~/bin directory.
I've only accumulated about 50 functions.

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2240 bytes --]

Re: exit to shell from nested function calls.

[Bart Schaefer]

On Fri, May 17, 2024 at 8:58 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2024-05-17 08:40, Mark J. Reed wrote:
>
> Only define functions inside your interactive shell when they need to make changes that persist after they exit - like changing directories, or updating variable values, etc.
>
> That would limit their number considerably.  Ok, goodbye functions

Well, don't take the wrong lesson from this.  There are other reasons
to use functions in an interactive shell.  Aside from functions being
the only way to create custom ZLE actions (widgets), they are the best
way to implement simple repetitive tasks that don't need the overhead
of forking, and the only way to isolate temporary variables while
retaining access to globals that are not exported.

It's more a matter of determining which tasks are discrete.  If you're
writing something that needs neither to access nor to modify the state
of the interactive shell, make it a script first, then think about
whether it's simple enough to become a function.

Re: exit to shell from nested function calls.

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Fri, May 17, 2024, 10:04 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> ... make it a script first, then think about
> whether it's simple enough to become a function.
>

Forgot to mention, you can also get the best of both worlds by writing a
function with sections (up to even the whole function body) wrapped in
subshell parens.

>

[-- Attachment #2: Type: text/html, Size: 841 bytes --]

Re: exit to shell from nested function calls.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]



On 2024-05-17 10:36, Bart Schaefer wrote:
> On Fri, May 17, 2024, 10:04 AM Bart Schaefer 
> <schaefer@brasslantern.com> wrote:
>
>     ... make it a script first, then think about
>     whether it's simple enough to become a function.
>
>
> Forgot to mention, you can also get the best of both worlds by writing 
> a function with sections (up to even the whole function body) wrapped 
> in subshell parens.
My whole project of trying to learn zsh 'as you go', was wrong from the 
start.  There are things like the above that can only be learned by 
instruction -- or by endless grief.  Need zsh classroom where the 
teacher knows what you need to know before you know you need to know 
it.  A very good book would be nice too.


[-- Attachment #2: Type: text/html, Size: 1776 bytes --]

Re: exit to shell from nested function calls.

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

The Bolsky & Korn KornShell book is a good start, actually. Lots of stuff
zsh has added that's not in there, but as far as first principles go ...

Mark J. Reed <markjreed@gmail.com>


On Fri, May 17, 2024 at 14:53 Ray Andrews <rayandrews@eastlink.ca> wrote:

>
>
> On 2024-05-17 10:36, Bart Schaefer wrote:
>
> On Fri, May 17, 2024, 10:04 AM Bart Schaefer <schaefer@brasslantern.com>
> wrote:
>
>> ... make it a script first, then think about
>> whether it's simple enough to become a function.
>>
>
> Forgot to mention, you can also get the best of both worlds by writing a
> function with sections (up to even the whole function body) wrapped in
> subshell parens.
>
> My whole project of trying to learn zsh 'as you go', was wrong from the
> start.  There are things like the above that can only be learned by
> instruction -- or by endless grief.  Need zsh classroom where the teacher
> knows what you need to know before you know you need to know it.  A very
> good book would be nice too.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2376 bytes --]

Re: exit to shell from nested function calls.

[Ray Andrews]

On 2024-05-17 12:00, Mark J. Reed wrote:
> The Bolsky & Korn KornShell book is a good start, actually. Lots of 
> stuff zsh has added that's not in there, but as far as first 
> principles go ...
Yeah, it's the first principles.  Gotta start at the beginning. Peter's 
book was good, but even there, he tries to cover both bash and zsh, 
which is only confusing.  The User's Guide would have been it.

Actually in my case even starting at the beginning would have been too 
easy, since I first needed to unlearn so much DOS stuff.  Nuts, I still 
say 'switch' and I still declare my variab -- I mean parameters ;-)  
These things end up in your DNA.

Re: exit to shell from nested function calls.

[Bart Schaefer]

I cannot personally recommend any of the following books/videos
because I have not read them, but:

Learning Shell Scripting with Zsh
by Gastón Festari
https://www.oreilly.com/library/view/learning-shell-scripting/9781783282937/

Zsh in macOS: Terminal Commands for Unix
by Karl Hadwen
https://www.oreilly.com/library/view/zsh-in-macos/9781484263945/

Learning Modern Linux (Chapter 3 in particular)
by Michael Hausenblas
https://www.oreilly.com/library/view/learning-modern-linux/9781098108939/

Re: exit to shell from nested function calls.

[Thomas Lauer]

From: Ray Andrews <rayandrews@eastlink.ca>
Date: Thu, 16 May 2024 14:28:41 -0700

> 
> BTW, just in case you're wondering, it's an overlay for mostly firefox 
> which chatters to the disk almost constantly.  Got  a newer machine 
> recently and it has a SSD, but I know they have limited R/W cycles so 
> I'm using the overlay to deflect the chatter to RAM. Works good so far. 

Most if not all modern SSDs don't need this sort of massaging anymore.
(Having said that, I still have all browser caches (and much besides) on
a RAM disk.)

T

Re: exit to shell from nested function calls.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]



On 2024-05-17 10:29, Thomas Lauer wrote:
> Most if not all modern SSDs don't need this sort of massaging anymore.
> (Having said that, I still have all browser caches (and much besides) on
> a RAM disk.)
This might sound silly but for me it's a matter of principle, I believe 
in frugality for it's own sake, it cultivates the 'right' mindset.  But 
from what I understand these SSDs are very good at reallocating cells 
that have reached their write limits, so a nearly empty disk -- 
everything I have is under 30G and the disk is 240G -- gives lots of 
room for that kind of thing.  smartctl reports the disk has 92% of its 
life left.  I guess with solid state they can be quite sure of that  
number, vs. the rather harder to predict life of mechanical parts.

[-- Attachment #2: Type: text/html, Size: 1215 bytes --]