How do you decide whether to make something a function or a script?

How do you decide whether to make something a function or a script?

[TJ Luoma]

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

I've been moving some of my more elaborate functions into their own files
and using the autoload feature to import them into other scripts.

But it's gotten me to wonder:

Why make any functions at all? Why not just make them all scripts? If they
are scripts in the $PATH then you can just call them by name and they work
in the login shell or in scripts. If they are functions, you have to
autoload them first.

So I've gotten to wonder… what makes you make something a function vs a
script?

TjL

--
TJ Luoma
TJ @ MacStories <http://www.macstories.net/author/tjluoma/>
Personal Website: luo.ma <http://luo.ma/> (aka RhymesWithDiploma.com
<http://rhymeswithdiploma.com/>)
Twitter: @tjluoma <http://twitter.com/tjluoma>

Re: How do you decide whether to make something a function or a script?

[Grant Taylor]

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

On 09/08/2018 07:22 PM, TJ Luoma wrote:
> But it's gotten me to wonder:

That can be dangerous.  ;-)

> Why make any functions at all? Why not just make them all scripts? If 
> they are scripts in the $PATH then you can just call them by name and 
> they work in the login shell or in scripts. If they are functions, 
> you have to autoload them first.
> 
> So I've gotten to wonder… what makes you make something a function vs 
> a script?

IMHO it all has to do with scope.  I tend to progress along the 
following sequence when I have reason to move to the next level:

1)  alias
2)  function
3)  script

IMHO aliases enable me to be lazy and not type things out completely, or 
make what seems to be custom commands like; alias myserver='ssh myserver'.

I upgrade from aliases to functions any time I need parameters or I want 
scripts to be able to use the same command.

I upgrade from functions to scripts when I want to be able to run the 
command from outside of the shell, like an ssh remote command:  ssh 
myserver openDB.  The remote command doesn't launch the shell, thus 
doesn't have access to functions, much less aliases.  But it does have 
access to scripts if I have my PATH configured properly.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: How do you decide whether to make something a function or a script?

[Daniel Shahaf]

Grant Taylor wrote on Sat, 08 Sep 2018 19:55 -0600:
> I upgrade from functions to scripts when I want to be able to run the 
> command from outside of the shell, like an ssh remote command:  ssh 
> myserver openDB.  The remote command doesn't launch the shell, thus 
> doesn't have access to functions, much less aliases. But it does have
> access to scripts if I have my PATH configured properly.

The remote command in 'ssh myserver foo bar' indeed doesn't have
access to functions or aliases, but it does go through a shell on the remote
end.  It simply uses a non-interactive shell.  That's why changes to PATH in
zshenv are honoured by ssh commands, and why functions aren't available
(zshrc isn't read).

Cheers,

Daniel
(I don't mean to nitpick; sometimes this distinction matters.)

Re: How do you decide whether to make something a function or a script?

[Grant Taylor]

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

On 09/08/2018 08:21 PM, Daniel Shahaf wrote:
> The remote command in 'ssh myserver foo bar' indeed doesn't have access to 
> functions or aliases, but it does go through a shell on the remote end. 
> It simply uses a non-interactive shell.  That's why changes to PATH in 
> zshenv are honoured by ssh commands, and why functions aren't available 
> (zshrc isn't read).

Okay.

There was a little doubt in my head when I wrote my reply, and there is 
more doubt now.

I still thought there was a way to get ssh to remotely execute commands 
/without/ invoking the shell.  Maybe that's ssh sub-systems.  They have 
a different method of invoking them.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: How do you decide whether to make something a function or a script?

[TJ Luoma]

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

> (I don't mean to nitpick; sometimes this distinction matters.)

A) I appreciate the distinction, as it's something I wouldn't have
necessarily thought about

B) Your reply also alerted me that I am not getting Grant's emails to the
list. I had to go to the mailing list archive (
http://www.zsh.org/mla/users//2018/msg00566.html) to see his initial post
and followup. Not sure why I'm not getting them, and they aren't in my spam
folder.

Thanks to all those who replied for the feedback!

Tj

--
TJ Luoma
TJ @ MacStories <http://www.macstories.net/author/tjluoma/>
Personal Website: luo.ma <http://luo.ma/> (aka RhymesWithDiploma.com
<http://rhymeswithdiploma.com/>)
Twitter: @tjluoma <http://twitter.com/tjluoma>

Re: How do you decide whether to make something a function or a script?

[Bart Schaefer]

On Sun, Sep 9, 2018 at 12:34 PM, TJ Luoma <luomat@gmail.com> wrote:
>
> B) Your reply also alerted me that I am not getting Grant's emails to the
> list.

Hmm, I'm not either, the last one I have is from almost a year ago.
Not in my spam, either; just never got here.

The SPF record for Grant's domain allows email from exactly one IP
address, and specifies that receiving systems should reject email from
that domain that originates from any other source, so probably when
the zsh-users exploder forwards the messages they are being discarded.
That's probably also the case for nearly all other mailing lists that
Grant is on.

Re: How do you decide whether to make something a function or a script?

[Bart Schaefer]

On Sat, Sep 8, 2018 at 6:22 PM, TJ Luoma <luomat@gmail.com> wrote:
>
> Why make any functions at all? Why not just make them all scripts?

The primary reason to make a program into a function is when it needs
to alter the state of the parent shell.  User-defined ZLE widgets are
the most obvious example, but there are other cases to want to make
persistent changes to the current shell.  (Yes, you can get some of
this with "source", but then you have to worry about parameter
scoping, etc.)

A secondary reason is efficiency.  Running a script requires forking a
subshell, examining the #! line to see if an external interpreter is
needed, and parsing the code, all before the script can begin doing
anything, and this happens every time it is run.  With functions,
there's no subshell, no guessing at the interpreter, and all the
parsing has been done up front (or is done only once on the first run,
in the case of an autoload).

Another reason is modularity.  A single file can define several
related functions, which leverages both of the first two advantages.

Yet another reason is to facilitate recursive programming.  A script
that runs itself creates many subshells, but a function that calls
itself only uses some recoverable memory space in the current shell.

There are more reasons, but most of them begin to be stylistic rather
than practical.  I'm sure others can add to my list.