From Newsgroup: comp.unix.shell

So typically, when I need to do something a little complex, I will write
a shell script.

My boss, on the other hand, will write a shell function that he sources
into his shell.

I'm curious about the pros/cons of each method.

The biggest "pro" that I see for a shell script over a shell function
is how easily/quickly I can update it. If I have (say) 10 screen
sessions running, a shell function needs to be re-sourced into every
one, while a shell script is instantly available.

Other thoughts? (or facts?)

--hymie! http://nasalinux.net/~hymie hymie@nasalinux.net --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

hymie! <hymie@nasalinux.net> wrote:

So typically, when I need to do something a little complex, I will write
a shell script.

My boss, on the other hand, will write a shell function that he sources
into his shell.

Interesting approach your boss uses, I wouldn't have thought to
do that. Do you know why he prefers to do it that way?

I can imagine that it might be a little faster, given that it won't
have to load from disk and parse the shell script every time it is
invoked, but I'd speculate that on today's hardware the difference
is insignificant.

Just for fun, I tried both and timed the execution. In both cases,
the action is a simple "sleep 5". Here's the shell script:

real 0m5,007s
user 0m0,001s
sys 0m0,006s

And here's the sourced shell function:

real 0m5,003s
user 0m0,000s
sys 0m0,003s

I tried a couple of times, and the numbers stay the same.

So yeah, you gain (on my machine) 4ms by using a shell function :)

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12 13:13, hymie! wrote:

So typically, when I need to do something a little complex, I will write
a shell script.

My boss, on the other hand, will write a shell function that he sources
into his shell.

I'm curious about the pros/cons of each method.

The biggest "pro" that I see for a shell script over a shell function
is how easily/quickly I can update it. If I have (say) 10 screen
sessions running, a shell function needs to be re-sourced into every
one, while a shell script is instantly available.

Other thoughts? (or facts?)

That question can not be clearly answered. It depends on what
type of function you use, how you use it, the software design,
and it also depends on the shell you use. A couple aspects...

First the used shell; I presume you have the choice of using
any common shell. Using Kornshell (ksh) you have a couple more
options than, e.g., with Bash. So the following is assuming a
Kornshell.

You don't need to source the functions in Kornshell; you can
define an FPATH variable (similar to PATH) that points to a
list of directories where the functions are organized and
accessible by an FPATH search (as opposed to sourcing with
absolute paths or having the dot-files locally). FPATH is
more flexible.

Functions are faster. They're loaded once and need not be
read every time you call it. Kornshell has also an 'autoload'
feature that loads functions through FPATH only on demand!

POSIX functions, 'f()', may make use of side effects, while
Kornshell functions, 'function f', may have local variables,
own signal handling, own 'getopts' parameter processing. The
latter is more self contained, comparable with external shell
scripts, but not that "isolated". Shell programs have no side
effects on the calling shell script programs, they are more
self contained. (But you can of course employ a defensive
coding style and handle the functions in a similar way.)

Myself I'm never (almost never) sourcing shell functions in
my shell programs; I have them embedded in the programs.
I'm constructing complex shell program systems by dedicated
shell scripts which I use as I do with other Unix commands;
like a tool box. If I'd had many independent simple functions
that are used in different shell program contexts then I'd
build a directory structure to collect them and load them
with the FPATH mechanism, organized like "topical" libraries.

You may have noticed that your point ("how easily/quickly I
can update") isn't really convincing in the light of ksh's
function features.

So far some aspects just off the top of my head.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

hymie! <hymie@nasalinux.net>:

So typically, when I need to do something a little complex, I
will write a shell script.

My boss, on the other hand, will write a shell function that he
sources into his shell.

I'm curious about the pros/cons of each method.

[rCa]

Other thoughts? (or facts?)

It might be very hard or even impossible to make a shell function
free of its context.-a For example, a shell function might iterate
over its given positional parameters:
sum()
(
unset -v sum arg &&
sum=0 &&
for arg
do
sum="$(( sum + arg ))"
done &&
printf '%s\n' "$sum"
)
Now, if one invokes it like
readonly arg sum && sum 1 2 3
it will fail.
In this particular example, though, that problem can be avoided:
sum()
{
if ! : ${1+:} false
then
set -- 0
else
while ${2+:} false
do
set -- "$@" "$(( ${1} + ${2} ))"
shift 2
done
fi
printf '%s\n' "$1"
}
On the other hand, a shell script of its own, like
#!/bin/sh
sum()
{
sum=0 &&
for arg
do
sum="$(( sum + arg ))"
done &&
printf '%s\n' "$sum"
} &&
sum "$@"
won't fail.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

POSIX functions, 'f()', may make use of side effects, while
Kornshell functions, 'function f', may have local variables,
own signal handling, own 'getopts' parameter processing.

Side note: The syntax for defining a POSIX function is actually

f() command

The commonly used braces { ... } are _not_ part of the syntax. You
can define a minimal shell function that consists of a single
command. For multiple commands, you need to use a form of grouping,
which is where the braces come in. However, you can also use
( ... ) to inherently run the function body in a subshell.

f() ( ... )

I have actually used this.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 12 May 2026 11:13:27 GMT, hymie! wrote:

So typically, when I need to do something a little complex, I will
write a shell script.

My boss, on the other hand, will write a shell function that he
sources into his shell.

I'm curious about the pros/cons of each method.

I have used shell functions where I wanted to do some direct
manipulation of the shellrCOs internal state. For example, a bash shell function can directly return a sequence of values in a bash array.
Also they are handy because they define commands that are available
regardless of your PATH setting--like builtins.

Downsides of shell functions:
* shell-specific
* stay memory-resident once loaded (until explicitly unloaded)

Typically I want to write a program, and I donrCOt want to tie it to the specific shell the user might be running. An executable shell script
is one way to do this--and I can use any shell available on the target
system. Sometimes the need becomes too complex for a shell
script--e.g. manipulation of filespecs that might have funny
characters in them. Then I switch to another
quick-development-friendly language, like Python.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Christian Weisgerber <naddy@mips.inka.de>:

Side note: The syntax for defining a POSIX function is actually

f() command

The commonly used braces { ... } are _not_ part of the syntax. You
can define a minimal shell function that consists of a single
command. For multiple commands, you need to use a form of grouping,
which is where the braces come in. However, you can also use
( ... ) to inherently run the function body in a subshell.

f() ( ... )

I have actually used this.

I didn't read the POSIX standard, but refrain from defining a
function body without using either rCR( rCa )rCL or rCR{ rCa }rCL anyway:
On my debian 11 system, when running the command using a rCRbashrCL
(
for shell in bash dash
do
(
set -x &&
exec -a sh -- \
"$shell" -c 'f() "$@"; f "$@"' "$shell" \
printf %s\\n 'Hello, world!'
)
done
)
I get the following output:
+ exec -a sh -- bash -c 'f() "$@"; f "$@"' bash printf '%s\n' 'Hello, world!'
bash: -c: line 1: syntax error near unexpected token `"$@"'
bash: -c: line 1: `f() "$@"; f "$@"'
+ exec -a sh -- dash -c 'f() "$@"; f "$@"' dash printf '%s\n' 'Hello, world!'
Hello, world!

Apparently rCRbashrCL does not like that syntax, while rCRdashrCL is

quite happy with it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12 20:46, Christian Weisgerber wrote:

On 2026-05-12, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

POSIX functions, 'f()', may make use of side effects, while
Kornshell functions, 'function f', may have local variables,
own signal handling, own 'getopts' parameter processing.

Side note: The syntax for defining a POSIX function is actually

f() command

Yes. But how is that related to what I said; above I just showed
the functions' form without any function body party, in both cases
to indicate the syntactic difference of the two existing forms.

The commonly used braces { ... } are _not_ part of the syntax. You
can define a minimal shell function that consists of a single
command. For multiple commands, you need to use a form of grouping,
which is where the braces come in. However, you can also use
( ... ) to inherently run the function body in a subshell.

f() ( ... )

I have actually used this.

I've used that too. - But rarely, since this form addresses just one
aspect of Kornshell functions, the sub-shell context.

The point with Kornshell functions is not only the sub-shell context
but also with availability of a separate getopts, signal, etc. layer.
That's why I almost always use the 'function f' form. (And meanwhile
it's supported by other prominent shells as well. Though non-POSIX,
thus may not be possible to use in all contexts if there's project
restrictions defined.)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12 19:52, Helmut Waitzmann wrote:

hymie! <hymie@nasalinux.net>:

So typically, when I need to do something a little complex, I will
write a shell script.
My boss, on the other hand, will write a shell function that he
sources into his shell.
I'm curious about the pros/cons of each method.

[rCa]

Other thoughts?-a (or facts?)

It might be very hard or even impossible to make a shell function free
of its context.-a For example, a shell function might iterate over its
given positional parameters:

That's one reason why I'm using Kornshell functions (as opposed
to POSIX functions), that allow you to iterate separately from
the top-level script getopts over its own arguments in its own
context, and not interfering.

Janis

-a sum()
-a (
-a-a-a unset -v sum arg &&
-a-a-a sum=0 &&
-a-a-a for arg
-a-a-a do
-a-a-a-a-a sum="$(( sum + arg ))"
-a-a-a done &&
-a-a-a printf '%s\n' "$sum"
-a )

Now, if one invokes it like

-a-a readonly arg sum && sum 1 2 3

it will fail.

In this particular example, though, that problem can be avoided:

-a-a sum()
-a-a {
-a-a-a-a if ! : ${1+:} false
-a-a-a-a then
-a-a-a-a-a-a set -- 0
-a-a-a-a else
-a-a-a-a-a-a while ${2+:} false
-a-a-a-a-a-a do
-a-a-a-a-a-a-a-a set -- "$@" "$(( ${1} + ${2} ))"
-a-a-a-a-a-a-a-a shift 2
-a-a-a-a-a-a done
-a-a-a-a fi
-a-a-a-a printf '%s\n' "$1"
-a-a }

On the other hand, a shell script of its own, like

-a #!/bin/sh
-a sum()
-a {
-a-a-a sum=0 &&
-a-a-a for arg
-a-a-a do
-a-a-a-a-a sum="$(( sum + arg ))"
-a-a-a done &&
-a-a-a printf '%s\n' "$sum"
-a } &&
-a sum "$@"

won't fail.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12 23:16, Lawrence DrCOOliveiro wrote:

On Tue, 12 May 2026 11:13:27 GMT, hymie! wrote:

So typically, when I need to do something a little complex, I will
write a shell script.

My boss, on the other hand, will write a shell function that he
sources into his shell.

I'm curious about the pros/cons of each method.

I have used shell functions where I wanted to do some direct
manipulation of the shellrCOs internal state. For example, a bash shell function can directly return a sequence of values in a bash array.
Also they are handy because they define commands that are available regardless of your PATH setting--like builtins.

That's where Kornshell (as opposed to Bash) uses FPATH for exactly
that reason.

Downsides of shell functions:
* shell-specific

You have the option to program in the _standardized_ (POSIX) shell
subset. Common prominent shells like Ksh, Bsh, Zsh, etc. allow that.

* stay memory-resident once loaded (until explicitly unloaded)

[...]

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Christian Weisgerber wrote:

Side note: The syntax for defining a POSIX function is actually

f() command

Not quite. If you look at the formal grammar in POSIX.1-2024 you'll
see that the relevant part is:

function_definition : fname '(' ')' linebreak function_body
;
function_body : compound_command
| compound_command redirect_list
;

I.e. POSIX doesn't require every type of command to be accepted as
the function body, only a compound command optionally followed by
redirections.

As well as the two grouping commands, compound commands include for,
case, if, while and until.

[snip], you can also use ( ... ) to inherently run the function
body in a subshell.

f() ( ... )

I have actually used this.

I've used that too, but I don't remember ever using any of the
non-grouping compound commands as the body, or putting redirections at
the end of the definition (i.e. not within a grouping command).
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <qm7edm-ijt.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:
...

As well as the two grouping commands, compound commands include for,
case, if, while and until.

Amazing. This actually works (in bash):

$ foo() for ((i=1; i<5; i++));do echo "i=$i";done
$ foo
i=1
i=2
i=3
i=4
$

I never would have guessed that...
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-12, Helmut Waitzmann <nn.throttle@erine.email> wrote:

f() command
The commonly used braces { ... } are _not_ part of the syntax. You
can define a minimal shell function that consists of a single
command.

Apparently rCRbashrCL does not like that syntax, while rCRdashrCL is

quite happy with it.

Right. The perils of writing from memory without checking.

Looking it up again, I see that POSIX requires the function body
to be a compound command, i.e., { }, ( ), for, case, if, while, or
until. So while some shells also accept a single command, that is
not required and bash doesn't.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

The point with Kornshell functions is not only the sub-shell context
but also with availability of a separate getopts, signal, etc. layer.
That's why I almost always use the 'function f' form. (And meanwhile
it's supported by other prominent shells as well. Though non-POSIX,

And you should be very careful about the semantics of Korn-style
vs. Bourne/POSIX-style function definitions in other shells. For
instance, a quick perusal of the Bash man page indicates that Bash
makes no difference between the two.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>:

On 2026-05-12 19:52, Helmut Waitzmann wrote:

It might be very hard or even impossible to make a shell
function free of its context.-a For example, a shell function
might iterate over its given positional parameters:

That's one reason why I'm using Kornshell functions (as opposed
to POSIX functions), that allow you to iterate separately from
the top-level script getopts over its own arguments in its own
context, and not interfering.

The problem I presented is not related to getopts but to the fact
that a readonly variable neither can be assigned a new value nor
can be unset-arCo even if the assignment resp.-a unset statement
occurs in a subshell environment.
Are you going to say that that won't fail using Kornshell?-a So,
what would be the working Kornshell equivalent to the notrCEworking
command
(
sum()
(
sum=0 &&
for arg
do
sum="$(( sum + arg ))"
done &&
printf '%s\n' "$sum"
) &&
readonly arg sum && sum 1 2 3
)
when given to a POSIXrCEShell?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-13 23:28, Helmut Waitzmann wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>:

On 2026-05-12 19:52, Helmut Waitzmann wrote:

It might be very hard or even impossible to make a shell function
free of its context.-a For example, a shell function might iterate
over its given positional parameters:

That's one reason why I'm using Kornshell functions (as opposed to
POSIX functions), that allow you to iterate separately from the top-
level script getopts over its own arguments in its own context, and
not interfering.

The problem I presented is not related to getopts but to the fact that a readonly variable neither can be assigned a new value nor can be unset-arCo even if the assignment resp.-a unset statement occurs in a subshell environment.

Are you going to say that that won't fail using Kornshell?-a So, what
would be the working Kornshell equivalent to the notrCEworking command

-a (
-a-a-a sum()
-a-a-a (
-a-a-a-a-a sum=0 &&
-a-a-a-a-a for arg
-a-a-a-a-a do
-a-a-a-a-a-a-a sum="$(( sum + arg ))"
-a-a-a-a-a done &&
-a-a-a-a-a printf '%s\n' "$sum"
-a-a-a ) &&
-a-a-a readonly arg sum && sum 1 2 3
-a )

when given to a POSIXrCEShell?

Trying to change a read-only variable must of course fail since
it's declared 'readonly'. But it makes little sense guessing what
your intention here is.

Initially you had said: "For example, a shell function might
iterate over its given positional parameters [...]"
And that is no problem since you use a Kornshell function with its
own scope.

Summing up values passed to a function, in ksh, I'd just do

function sumup
{
typeset sum=0 # a local variable
typeset arg # a local variable
for arg
do
(( sum += arg ))
done
printf '%d\n' sum
}

readonly sum sum # no problem but unnecessary - just remove that
# declaration irrelevant since you'd work with local vars in sumup
# and it makes no sense to have the variables in sumup as r/o
sumup 1 2 3

I think the code is clear enough and don't see where you see a problem.

If that's not what had been your point, please formulate more clearly
what you actually want to achieve. (And please also try to formulate
the code without unnecessary irritating obfuscations as naming a
function and a variable by the same name, even if it's functionally no problem.)

Thanks.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-13 15:44, Christian Weisgerber wrote:

On 2026-05-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

The point with Kornshell functions is not only the sub-shell context
but also with availability of a separate getopts, signal, etc. layer.
That's why I almost always use the 'function f' form. (And meanwhile
it's supported by other prominent shells as well. Though non-POSIX,

And you should be very careful about the semantics of Korn-style
vs. Bourne/POSIX-style function definitions in other shells. For
instance, a quick perusal of the Bash man page indicates that Bash
makes no difference between the two.

Thanks, that was actually new to me. - I saw some support in Bash but
haven't checked its semantics. I assumed Bash just copied the feature.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>:

On 2026-05-13 23:28, Helmut Waitzmann wrote:

The problem I presented is not related to getopts but to the
fact that a readonly variable neither can be assigned a new
value nor can be unset-arCo even if the assignment resp.-aunset
statement occurs in a subshell environment.


Are you going to say that that won't fail using Kornshell?-a So,
what would be the working Kornshell equivalent to the
notrCEworking command


-a (
-a-a-a sum()
-a-a-a (
-a-a-a-a-a sum=0 &&
-a-a-a-a-a for arg
-a-a-a-a-a do
-a-a-a-a-a-a-a sum="$(( sum + arg ))"
-a-a-a-a-a done &&
-a-a-a-a-a printf '%s\n' "$sum"
-a-a-a ) &&
-a-a-a readonly arg sum && sum 1 2 3
-a )

when given to a POSIXrCEShell?

Trying to change a read-only variable must of course fail since
it's declared 'readonly'. But it makes little sense guessing what
your intention here is.

My intention is the one of the OP, as hymie!
<hymie@nasalinux.net> wrote:
rCLSo typically, when I need to do something a little complex, I
will write a shell script.
My boss, on the other hand, will write a shell function that he
sources into his shell.
I'm curious about the pros/cons of each method.rCY
The example (summing up the positional parameters by means of a
rCLforrCY loop) showed a usecase where some implementation using a
shell function (the boss' way) will fail when used in an invoking
shell environment where the shell variable rCLargrCY or rCLsumrCY happens
to be a readonly variable.
On the other hand, the implementation using a shell script
(hymie!'s way) will succeed, even when used in an invoking shell
environment where the shell variable rCLargrCY or rCLsumrCY happens to be
a readonly variable.

Initially you had said: "For example, a shell function might
iterate over its given positional parameters [...]"

And that is no problem since you use a Kornshell function with
its own scope.

It is no problem with a POSIX shell as well:-a Each function has
got its own scope regarding the positional parameters.

Summing up values passed to a function, in ksh, I'd just do

function sumup
{
typeset sum=0 # a local variable
typeset arg # a local variable
for arg
do
(( sum += arg ))
done
printf '%d\n' sum
}

readonly sum sum # no problem but unnecessary - just remove that
# declaration

No.-a Removing that declaration is not an option, as it is part of
the invoking shell environment which is neither known to nor in
charge of the rCLsumuprCY implementor.

# irrelevant since you'd work with local vars in sumup

# and it makes no sense to have the variables in sumup as r/o

sumup 1 2 3

I think the code is clear enough and don't see where you see a
problem.

If that's not what had been your point, please formulate more
clearly what you actually want to achieve.

If you had bothered to run the given example you would have seen
the shell's error messages stating that the readonly attribute is
the problem rather than any rCLlocalrCY variable (which is by the way
not part of the POSIX standard and in this case unnecessary, as
the function creates a subshell environment of its own by means
of the function definition using parentheses for the body of the
function).
The problem:-a The implementor of the rCLsumuprCY function doesn't
have any means to remove the readonly attribute of any variable
defined in the invoking shell environment which happens by
coincidence to have the same name like a variable used in the
rCLsumuprCY function.
I gave that example using a rCLforrCY loop for summing up the
positional parameters to show that in some cases there might
exist an implementation (here: using a rCLwhilerCY loop which doesn't
make use of any shell variables besides of the positional
parameters) which doesn't suffer from the rCLreadonlyrCY attribute
inherited from the invoking shell environment.

(And please also try to formulate the code without unnecessary
irritating obfuscations as naming a function and a variable by
the same name, even if it's functionally no problem.)

A variable reference is clearly distinguishable from a function
reference by the presence of either a rCL=rCY (when assigning) or a
rCL$rCY (when evaluating).-a So, which lines of the given example were
unclear to you?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-05-14 19:03, Helmut Waitzmann wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>:

On 2026-05-13 23:28, Helmut Waitzmann wrote:

The problem I presented is not related to getopts but to the fact
that a readonly variable neither can be assigned a new value nor can
be unset-arCo even if the assignment resp.-aunset statement occurs in a >>> subshell environment.

Are you going to say that that won't fail using Kornshell?-a So, what
would be the working Kornshell equivalent to the notrCEworking command

-a-a (
-a-a-a-a sum()
-a-a-a-a (
-a-a-a-a-a-a sum=0 &&
-a-a-a-a-a-a for arg
-a-a-a-a-a-a do
-a-a-a-a-a-a-a-a sum="$(( sum + arg ))"
-a-a-a-a-a-a done &&
-a-a-a-a-a-a printf '%s\n' "$sum"
-a-a-a-a ) &&
-a-a-a-a readonly arg sum && sum 1 2 3
-a-a )

when given to a POSIXrCEShell?

Trying to change a read-only variable must of course fail since it's
declared 'readonly'. But it makes little sense guessing what your
intention here is.

My intention is the one of the OP, as hymie! <hymie@nasalinux.net> wrote:

rCLSo typically, when I need to do something a little complex, I will
write a shell script.

My boss, on the other hand, will write a shell function that he sources
into his shell.

I'm curious about the pros/cons of each method.rCY

The example (summing up the positional parameters by means of a rCLforrCY loop) showed a usecase where some implementation using a shell function
(the boss' way) will fail when used in an invoking shell environment
where the shell variable rCLargrCY or rCLsumrCY happens to be a readonly variable.

On the other hand, the implementation using a shell script (hymie!'s
way) will succeed, even when used in an invoking shell environment where
the shell variable rCLargrCY or rCLsumrCY happens to be a readonly variable.

Initially you had said: "For example, a shell function might iterate
over its given positional parameters [...]"
And that is no problem since you use a Kornshell function with its own
scope.

It is no problem with a POSIX shell as well:-a Each function has got its
own scope regarding the positional parameters.

Summing up values passed to a function, in ksh, I'd just do

-a-a-a-a function sumup
-a-a-a-a {
-a-a-a-a-a-a typeset sum=0-a # a local variable
-a-a-a-a-a-a typeset arg-a-a-a # a local variable
-a-a-a-a-a-a for arg
-a-a-a-a-a-a do
-a-a-a-a-a-a-a-a (( sum += arg ))
-a-a-a-a-a-a done
-a-a-a-a-a-a printf '%d\n' sum
-a-a-a-a }

-a-a-a-a readonly sum sum-a-a # no problem but unnecessary - just remove that
-a-a-a-a # declaration

No.-a Removing that declaration is not an option, as it is part of the invoking shell environment which is neither known to nor in charge of
the rCLsumuprCY implementor.

Yes. And I pointed out that you can leave it there or just remove it;
it makes no difference in context of a self-contained separate Ksh
'function' - which is effectively different from your using of a POSIX
style function.

-a-a-a-a # irrelevant since you'd work with local vars in sumup

-a-a-a-a-a # and it makes no sense to have the variables in sumup as r/o

-a-a-a-a sumup 1 2 3

I think the code is clear enough and don't see where you see a problem.

If that's not what had been your point, please formulate more clearly
what you actually want to achieve.

If you had bothered to run the given example you would have seen the
shell's error messages stating that the readonly attribute is the
problem rather than any rCLlocalrCY variable (which is by the way not part of the POSIX standard and in this case unnecessary, as the function
creates a subshell environment of its own by means of the function definition using parentheses for the body of the function).

The problem:-a The implementor of the rCLsumuprCY function doesn't have any means to remove the readonly attribute of any variable defined in the invoking shell environment which happens by coincidence to have the same name like a variable used in the rCLsumuprCY function.

The point being is why shall it try to remove a readonly attribute
from a variable _from the environment_; the point is that, as with
separate defined scripts that are called, you want a consistent
effect of the function, and one without side-effects. (Or that's
what I'd want at least. YMMV.)

I gave that example using a rCLforrCY loop for summing up the positional parameters to show that in some cases there might exist an
implementation (here: using a rCLwhilerCY loop which doesn't make use of any shell variables besides of the positional parameters) which doesn't
suffer from the rCLreadonlyrCY attribute inherited from the invoking shell environment.

(And please also try to formulate the code without unnecessary
irritating obfuscations as naming a function and a variable by the
same name, even if it's functionally no problem.)

A variable reference is clearly distinguishable from a function
reference by the presence of either a rCL=rCY (when assigning) or a
rCL$rCY (when evaluating).-a So, which lines of the given example were unclear to you?

First; I had run your code and your intentions weren't clear to me,
neither by your (IMO non-sensible) sample code nor by you wording.
That's why I had been asking for clarification.

And if I'm speaking about "unnecessary irritating obfuscations" I
was not saying that I cannot parse your code. Just that you used a
style unnecessarily that makes your point not clear. The same, BTW,
could be said for your foible to use && in unnecessary places (and
some more peculiarities you seem to like).

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2