zsh-users
 help / color / mirror / code / Atom feed
* order of sourcing
@ 2023-01-17 21:07 Ray Andrews
  2023-01-17 21:24 ` Roman Perepelitsa
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2023-01-17 21:07 UTC (permalink / raw)
  To: Zsh Users

In my .zshrc, to source all my functions I just switch to the directory 
where they're stored and:

     for aa in *(.); do source $aa; done

... seems fine, but sometimes I'm editing one function or another and I 
run into 'not found' issues, like some subsidiary function has been 
'lost'.  Sourcing it's file fixes the 'not found' but I'm wondering if 
there's some standard way of insuring that function files are sourced in 
a preferred order.  For some of them I've renamed the files in an 
alphabetical order since the above code seems to source the files 
alphabetically.  But it's add hoc and messy.  Dunno, I could list them 
all in a file in preferred order and then source that file.  But what's 
the done thing?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-17 21:07 order of sourcing Ray Andrews
@ 2023-01-17 21:24 ` Roman Perepelitsa
  2023-01-17 21:34   ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Roman Perepelitsa @ 2023-01-17 21:24 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Tue, Jan 17, 2023 at 10:10 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> In my .zshrc, to source all my functions I just switch to the directory
> where they're stored and:
>
>      for aa in *(.); do source $aa; done
>
> ... seems fine, but sometimes I'm editing one function or another and I
> run into 'not found' issues, like some subsidiary function has been
> 'lost'.  Sourcing it's file fixes the 'not found' but I'm wondering if
> there's some standard way of insuring that function files are sourced in
> a preferred order.  For some of them I've renamed the files in an
> alphabetical order since the above code seems to source the files
> alphabetically.  But it's add hoc and messy.  Dunno, I could list them
> all in a file in preferred order and then source that file.  But what's
> the done thing?

The standard solution is to autoload functions. It solves a bunch of
other problems that you get when sourcing files with function
definitions:

- You no longer pay the startup time penalty.
- You can rely on the standard options being in effect when the
function is parsed.
- You can rely on there being no aliases when the function is parsed.

Roman.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-17 21:24 ` Roman Perepelitsa
@ 2023-01-17 21:34   ` Bart Schaefer
  2023-01-17 21:42     ` Roman Perepelitsa
  2023-01-17 21:48     ` Ray Andrews
  0 siblings, 2 replies; 11+ messages in thread
From: Bart Schaefer @ 2023-01-17 21:34 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, Zsh Users

On Tue, Jan 17, 2023 at 1:24 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> The standard solution is to autoload functions. It solves a bunch of
> other problems that you get when sourcing files with function
> definitions

One complication here is that, if Ray is able to use "source" to load
a function's definition, then he's not writing the file in the
ordinary autoload format -- that is, the file must in fact contain the
full
  funcname() {
   # funcbody
  }
whereas an autoload would normally be a file named "funcname"
containing only the function body.  To make autoloading work with
files designed to be sourced, one must employ additional tricks, such
as using "autoload -k".  Also, this remark --

> > run into 'not found' issues, like some subsidiary function has been
> > 'lost'.

-- also makes me suspect that Ray has more than one function per file,
which further messes with autoload.

> - You can rely on there being no aliases when the function is parsed.

That needs "autoload -U" I think?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-17 21:34   ` Bart Schaefer
@ 2023-01-17 21:42     ` Roman Perepelitsa
  2023-01-17 21:48     ` Ray Andrews
  1 sibling, 0 replies; 11+ messages in thread
From: Roman Perepelitsa @ 2023-01-17 21:42 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, Zsh Users

On Tue, Jan 17, 2023 at 10:34 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> On Tue, Jan 17, 2023 at 1:24 PM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > The standard solution is to autoload functions. It solves a bunch of
> > other problems that you get when sourcing files with function
> > definitions
>
> One complication here is that, if Ray is able to use "source" to load
> a function's definition, then he's not writing the file in the
> ordinary autoload format

Almost certainly. If he were to switch to autoloading (which I think
is a good idea), he would have to move things around.

> That needs "autoload -U" I think?

I usually go with `autoload -Uz` for good measure so that I don't have
to think about current options at all.

Roman.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-17 21:34   ` Bart Schaefer
  2023-01-17 21:42     ` Roman Perepelitsa
@ 2023-01-17 21:48     ` Ray Andrews
  2023-01-18 21:23       ` Bart Schaefer
  1 sibling, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2023-01-17 21:48 UTC (permalink / raw)
  To: zsh-users


On 2023-01-17 13:34, Bart Schaefer wrote:
> -- also makes me suspect that Ray has more than one function per file,
> which further messes with autoload.
True.  I have help screens as subsidiary functions but defined within 
the file named after the function itself.  I'd hate to have to clutter 
things up making files for each of them.  A few years back I 
experimented with autoload but gave up on it, tho perhaps I should give 
it another look.  Mind I'm happy just sourcing everything, but getting 
them in order is the small issue mentioned.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-17 21:48     ` Ray Andrews
@ 2023-01-18 21:23       ` Bart Schaefer
  2023-01-18 23:44         ` Ray Andrews
  0 siblings, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 2023-01-18 21:23 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Jan 17, 2023 at 1:48 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-17 13:34, Bart Schaefer wrote:
> > -- also makes me suspect that Ray has more than one function per file,
> > which further messes with autoload.
> True.  I have help screens as subsidiary functions but defined within
> the file named after the function itself.

That should be fine as long as you never want to run the subsidiary
function without first running the primary function.

> Mind I'm happy just sourcing everything, but getting
> them in order is the small issue mentioned.

It does seem odd that the order of sourcing should matter, unless the
files so sourced actually do something other than defining functions.
E.g., do they either execute conditional expressions, or define
aliases that are then used in other files?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-01-18 21:23       ` Bart Schaefer
@ 2023-01-18 23:44         ` Ray Andrews
  0 siblings, 0 replies; 11+ messages in thread
From: Ray Andrews @ 2023-01-18 23:44 UTC (permalink / raw)
  To: zsh-users


On 2023-01-18 13:23, Bart Schaefer wrote:
> E.g., do they either execute conditional expressions, or define
> aliases that are then used in other files?
>
Ah!  Come to that, the functions that tend to get lost are, now that I 
think on it, called by aliases and we know that that's an issue.  I'm 
going to pay more attention next time it happens and nail that down.  Tx 
Bart.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-04-16 16:48   ` Ray Andrews
@ 2023-04-16 20:22     ` Ray Andrews
  0 siblings, 0 replies; 11+ messages in thread
From: Ray Andrews @ 2023-04-16 20:22 UTC (permalink / raw)
  To: zsh-users


On 2023-04-16 09:48, Ray Andrews wrote:
>
> On 2023-04-16 09:17, Roman Perepelitsa wrote:
>
> $ for aa in *(.); do source $aa; done
>
> ... doing that in my test directory cures the problem, but I still 
> have the problem with my real functions -- I have to re-source 
> function files that call other functions if the called function is 
> sourced latter than the calling function.

Here's the real example:

All functions in the directory are sourced with

$ for aa in *(.); do source $aa; done

... the two functions are 'i' and 'v', with the former calling the later.

4 /aWorking/Zsh/Source/Wk 3 % i zsh

_i:104: permission denied: v

4 /aWorking/Zsh/Source/Wk 3 % . i; i zsh

... All OK.  Could aliases have something to do with it?  I can't 
duplicate the problem with test functions tho.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-04-16 16:17 ` Roman Perepelitsa
@ 2023-04-16 16:48   ` Ray Andrews
  2023-04-16 20:22     ` Ray Andrews
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2023-04-16 16:48 UTC (permalink / raw)
  To: zsh-users


On 2023-04-16 09:17, Roman Perepelitsa wrote:
> This sources only one file. If you want to source multiple files, you
> need to run `source` (or `.`) multiple times.

Nuts yes.  I was attempting to make a minimal example of the issue.  In 
fact this happens with my real functions which are sourced in fact with:

$ for aa in *(.); do source $aa; done

... doing that in my test directory cures the problem, but I still have 
the problem with my real functions -- I have to re-source function files 
that call other functions if the called function is sourced latter than 
the calling function.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: order of sourcing
  2023-04-16 16:14 Ray Andrews
@ 2023-04-16 16:17 ` Roman Perepelitsa
  2023-04-16 16:48   ` Ray Andrews
  0 siblings, 1 reply; 11+ messages in thread
From: Roman Perepelitsa @ 2023-04-16 16:17 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Sun, Apr 16, 2023 at 6:15 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> 4 /aWorking/Zsh/Source/Wk/Test 0 $ . *    # Just sourcing 'aa' and 'bb'.

This sources only one file. If you want to source multiple files, you
need to run `source` (or `.`) multiple times.

Roman.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* order of sourcing
@ 2023-04-16 16:14 Ray Andrews
  2023-04-16 16:17 ` Roman Perepelitsa
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2023-04-16 16:14 UTC (permalink / raw)
  To: Zsh Users

I'd like to clear up a little bother:

file aa:

aa ()
{
     bb "howdy!"
}

file bb:

bb ()
{
     echo $1
}

4 /aWorking/Zsh/Source/Wk/Test 0 $ . *    # Just sourcing 'aa' and 'bb'.

4 /aWorking/Zsh/Source/Wk/Test 0 $ aa
aa:2: permission denied: bb

4 /aWorking/Zsh/Source/Wk/Test 0 $ . bb; aa
howdy!

... I think I get it:  'aa' is sourced first and thus 'aa ()' doesn't 
know what 'bb ()' looks like so throws an error until 'bb' is sourced 
again.  But shouldn't 'aa ()' sorta find 'bb ()'  in real time?  It's 
easy enough to deal with but I'm betting there's an easy and better 
solution that doesn't involve ad hoc re-sourcing.




^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-04-16 20:23 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-17 21:07 order of sourcing Ray Andrews
2023-01-17 21:24 ` Roman Perepelitsa
2023-01-17 21:34   ` Bart Schaefer
2023-01-17 21:42     ` Roman Perepelitsa
2023-01-17 21:48     ` Ray Andrews
2023-01-18 21:23       ` Bart Schaefer
2023-01-18 23:44         ` Ray Andrews
2023-04-16 16:14 Ray Andrews
2023-04-16 16:17 ` Roman Perepelitsa
2023-04-16 16:48   ` Ray Andrews
2023-04-16 20:22     ` Ray Andrews

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).