[SOLVED] function that tests variable and sets default value

Faki · 05-03-2023, 06:35 AM

I understand everything you have written and fully understand how local works. I could follow your demo example. Internally demo sets var as a completely different variable than the global one. The global one is not affected by the status of the local one.

I want to make this point though. Let us assume that I will be passing a variable to demo (either a global one or a local one defined in some other function), which I would like to change for use elsewhere (e.g. to call another function). My school of thought is that in such situations, the use of

Code:

local -n var="$1"

is superfluous, and one can actually use

Code:

typeset -n var="$1" ; var=something_else

The typeset expression works in the same way as changing the variable passed as $1 to be set to a new value something_else, with something_else being seen outside the function. Using local or typeset does not make any actual difference in the result.

sundialsvcs · 05-03-2023, 07:15 AM

Meh ...

If I'm gonna do something like that, then the first line of my script is gonna look something like this:

Code:

#!/usr/bin/perl

(Pick the language processor of your choice to put in the so-called "shebang" line.) And then, I'm gonna write the rest of the script in a real programming language. No one will ever know. The shell will silently invoke the stated language processor, hand the rest of the script to it, and off you go.

The only shell that was ever intended to embed a "real" programming language was Dr. Korn's ksh, which I have seen "in the field" only one time. Bash's scripting capabilities, such as they are, are very primitive. And so, I simply don't bother to do much with it. Thanks to the very elegant mechanism of "shebang," it simply isn't necessary.

Faki · 05-03-2023, 08:09 AM

I agree completely. The archaic nature of bash especially the necessity of specifying local declarations inside the function, rather than automatically defining all variables in functions with local context, makes everything much long-winded and frustrating.

Still, for things that I have in bash, I do try to follow good procedures nevertheless.

MadeInGermany · 05-03-2023, 08:54 AM

Even in perl you should declare a variable with the my keyword.
But then it is automatic. my means "as local as possible". (Local to the current module in the main code, local to the function in a function.)

--

Now I see what you mean:

Code:

demo(){
  local var1
  typeset var2
  var1=5
  var2=6
  echo "demo:  var1=$var1 var2=$var2"
}
 
var1=45
var2=46
echo "main: var1=$var1 var2=$var2"
demo
echo "main: var1=$var1 var2=$var2"
demo
echo "main: var1=$var1 var2=$var2"

Indeed, here the typeset is like local, I tested on bash version 5.
Was it changed?
I would not bet on it. Always use explicit local

pan64 · 05-03-2023, 09:32 AM

https://tldp.org/LDP/abs/html/localvar.html

Faki · 05-03-2023, 10:40 AM

My modus operandi was to use

Code:

typeset -n var="$1"

as an indication that changes to var has implications outside the function.

And only use local as an indicator has only (and only) local context with
no possibility of external effects outside of it.

Thus

Code:

typeset -n var="$1"  # var may change value to calling argument

whereas

Code:

local var="$1"  # var makes changes within the function and nowhere else

Thus I never use the -n declaration with local, but only with typeset.

@MadeInGermany

Would this make valid sense to you as described ? The rule removes some ambiguity on what might happen.

MadeInGermany · 05-03-2023, 10:56 AM

The link only explains what local in a function is.
Does not explain what happens if you'd use typeset or declare in a function.
Also the man page is unclear.

https://www.gnu.org/software/bash/ma...Functions.html

Quote:

Variables local to the function may be declared with the local builtin (local variables).

Nothing else mentioned.
But in the next paragraph:

Quote:

Consequently, a local variable at the current local scope is a variable declared using the local or declare builtins in the function that is currently executing.

And it is documented that declare and typeset are synonyms.
My conclusion is:
use local in a function, otherwise you walk on unsafe ground.

Faki · 05-03-2023, 11:08 AM

There might exist the capability of expanding the documentation regarding the aspects mentioned.

boughtonp · 05-03-2023, 11:14 AM

Quote:

Originally Posted by MadeInGermany

Also the man page is unclear.
...
My conclusion is:
use local in a function, otherwise you walk on poorly documented ground.

The manual is not unclear.

If you want to know what a built-in command does, go to the Index, select the relevant section (i.e. Index of Shell Builtin Commands) and select the name of the command, i.e. declare or typeset, then read the text provided...

Quote:

Originally Posted by https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#index-declare

declare
...
The -g option forces variables to be created or modified at the global scope, even when declare is executed in a shell function.
...
When used in a function, declare makes each name local, as with the local command, unless the -g option is used.

Quote:

Originally Posted by https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#index-typeset

typeset
typeset [-afFgrxilnrtux] [-p] [name[=value] …]
The typeset command is supplied for compatibility with the Korn shell. It is a synonym for the declare builtin command.

Faki · 05-03-2023, 11:41 AM

My suggestion was driven by your comment about walking on unsafe ground. Might there be need for more explanation for users to be able to decide what to use in given circumstances more clearly?

My focus has mainly been about using

Code:

typeset -n var="$1"

if you know that the variable defined for $1 will be change by the function. Otherwise I would always use local.

Strictly speaking

Code:

local -n var="$1"

ensures var is a local variable, but setting var to something else would change the value of the variable referenced by $1.

But the subsequent discussion mainly focused on just the local declaration, rather than the necessity of having a nameref variable via -n.

I do not know if it is just me, but -n seems to change the fundamental purpose of local because the capabilities of a reference variable goes further than the strict sense of the local declarion using just

Code:

local var="$1"

MadeInGermany · 05-03-2023, 12:08 PM

Certainly there was a change in bash.

https://linux.die.net/man/1/bash
(currently!) does not mention declare -g

Quote:

declare [-aAfFilrtux] [-p] [name[=value] ...]
typeset [-aAfFilrtux] [-p] [name[=value] ...]

and does not mention what declare defaults to (and I think it has been global).

But a newer man page mentions -g and says

Quote:

When used in a function, declare and
typeset make each name local, as with the local command,
unless the -g option is supplied.

Faki · 05-03-2023, 02:48 PM

Fundamentally, all this conforms with making all variables within function local as they should be.

boughtonp · 05-03-2023, 05:36 PM

Quote:

Originally Posted by MadeInGermany

Certainly there was a change in bash.

https://linux.die.net/man/1/bash

That page is from 2009 - two years before Bash 4.2 was released and added the global option, but did not change the default behaviour.

Quote:

and does not mention what declare defaults to (and I think it has been global).

Yes it does: "When used in a function, makes each name local, as with the local command."

Faki · 05-03-2023, 05:50 PM

But using the nameref option -n effectively changes the meaning of "local" to allow the variable to be modified and retain its value outside of the function. Thus, making the variable "global" within the script.

sundialsvcs · 05-03-2023, 08:02 PM

If I may be utterly frank, to me, things like typeset are basically "putting lipstick on a pig." These are "things that have been 'subsequently invented'" to try to press "bash scripting" into service, when "bash, itself" wisely offered #!shebang" as a much more elegant and simple solution to the underlying problem.

Frankly, it becomes tiring to walk into yet another situation that is "held together by bubblegum and Scotch® tape." The system "sort-of" works, but now it has to be changed and no one is confident to do it. Because it's a baffling amount of "shell scripting," and the guy (RIP ...) who just got hit by a bread truck is no longer here to maintain it.