Cómo devolver un valor de cadena desde una función Bash

Me gustaría devolver una cadena de una función Bash.

Escribiré el ejemplo en Java para mostrar lo que me gustaría hacer:

public String getSomeString() {
  return "tadaa";
}

String variable = getSomeString();

El siguiente ejemplo funciona en bash, pero ¿hay una mejor manera de hacerlo?

function getSomeString {
   echo "tadaa"
}

VARIABLE=$(getSomeString)

No hay mejor manera que yo sepa. Bash solo conoce códigos de estado (enteros) y cadenas escritas en el stdout.

Puede hacer que la función tome una variable como el primer argumento y modifique la variable con la cadena que desea devolver.

#!/bin/bash
set -x
function pass_back_a_string() {
    eval "$1='foo bar rab oof'"
}

return_var=''
pass_back_a_string return_var
echo $return_var

Imprime "foo bar rab oof".

Editar : se agregaron citas en el lugar apropiado para permitir espacios en blanco en la cadena para abordar el comentario de @Luca Borrione.

Editar : Como demostración, vea el siguiente programa. Esta es una solución de uso general: incluso le permite recibir una cadena en una variable local.

#!/bin/bash
set -x
function pass_back_a_string() {
    eval "$1='foo bar rab oof'"
}

return_var=''
pass_back_a_string return_var
echo $return_var

function call_a_string_func() {
     local lvar=''
     pass_back_a_string lvar
     echo "lvar='$lvar' locally"
}

call_a_string_func
echo "lvar='$lvar' globally"

Esto imprime:

+ return_var=
+ pass_back_a_string return_var
+ eval 'return_var='\''foo bar rab oof'\'''
++ return_var='foo bar rab oof'
+ echo foo bar rab oof
foo bar rab oof
+ call_a_string_func
+ local lvar=
+ pass_back_a_string lvar
+ eval 'lvar='\''foo bar rab oof'\'''
++ lvar='foo bar rab oof'
+ echo 'lvar='\''foo bar rab oof'\'' locally'
lvar='foo bar rab oof' locally
+ echo 'lvar='\'''\'' globally'
lvar='' globally

Editar : demostrando que el valor de la variable original está disponible en la función, como fue criticado incorrectamente por @Xichen Li en un comentario.

#!/bin/bash
set -x
function pass_back_a_string() {
    eval "echo in pass_back_a_string, original $1 is \$$1"
    eval "$1='foo bar rab oof'"
}

return_var='original return_var'
pass_back_a_string return_var
echo $return_var

function call_a_string_func() {
     local lvar='original lvar'
     pass_back_a_string lvar
     echo "lvar='$lvar' locally"
}

call_a_string_func
echo "lvar='$lvar' globally"

Esto da salida:

+ return_var='original return_var'
+ pass_back_a_string return_var
+ eval 'echo in pass_back_a_string, original return_var is $return_var'
++ echo in pass_back_a_string, original return_var is original return_var
in pass_back_a_string, original return_var is original return_var
+ eval 'return_var='\''foo bar rab oof'\'''
++ return_var='foo bar rab oof'
+ echo foo bar rab oof
foo bar rab oof
+ call_a_string_func
+ local 'lvar=original lvar'
+ pass_back_a_string lvar
+ eval 'echo in pass_back_a_string, original lvar is $lvar'
++ echo in pass_back_a_string, original lvar is original lvar
in pass_back_a_string, original lvar is original lvar
+ eval 'lvar='\''foo bar rab oof'\'''
++ lvar='foo bar rab oof'
+ echo 'lvar='\''foo bar rab oof'\'' locally'
lvar='foo bar rab oof' locally
+ echo 'lvar='\'''\'' globally'
lvar='' globally

Todas las respuestas anteriores ignoran lo que se ha indicado en la página de manual de bash.

• Todas las variables declaradas dentro de una función se compartirán con el entorno de llamada.
• No se compartirán todas las variables declaradas locales.

Código de ejemplo

#!/bin/bash

f()
{
    echo function starts
    local WillNotExists="It still does!"
    DoesNotExists="It still does!"
    echo function ends
}

echo $DoesNotExists #Should print empty line
echo $WillNotExists #Should print empty line
f                   #Call the function
echo $DoesNotExists #Should print It still does!
echo $WillNotExists #Should print empty line

Y salida

$ sh -x ./x.sh
+ echo

+ echo

+ f
+ echo function starts 
function starts
+ local 'WillNotExists=It still does!'
+ DoesNotExists='It still does!'
+ echo function ends 
function ends
+ echo It still 'does!' 
It still does!
+ echo

¡También bajo pdksh y ksh este script hace lo mismo!

Bash, desde la versión 4.3, febrero de 2014 (?), Tiene soporte explícito para variables de referencia o referencias de nombre (namerefs), más allá de "eval", con el mismo rendimiento beneficioso y efecto indirecto, y que puede ser más claro en sus scripts y también más difícil para "olvidar 'evaluar' y corregir este error":

declare [-aAfFgilnrtux] [-p] [name[=value] ...]
typeset [-aAfFgilnrtux] [-p] [name[=value] ...]
  Declare variables and/or give them attributes
  ...
  -n Give each name the nameref attribute, making it a name reference
     to another variable.  That other variable is defined by the value
     of name.  All references and assignments to name, except for⋅
     changing the -n attribute itself, are performed on the variable
     referenced by name's value.  The -n attribute cannot be applied to
     array variables.
...
When used in a function, declare and typeset make each name local,
as with the local command, unless the -g option is supplied...

y también:

PARÁMETROS

A la variable se le puede asignar el atributo nameref utilizando la opción -n para los comandos locales declare o local (consulte las descripciones de declare y local a continuación) para crear un nameref o una referencia a otra variable. Esto permite que las variables sean manipuladas indirectamente. Cada vez que se hace referencia a la variable nameref o se le asigna, la operación se realiza realmente en la variable especificada por el valor de la variable nameref. Un nameref se usa comúnmente dentro de las funciones de shell para referirse a una variable cuyo nombre se pasa como argumento a⋅ la función. Por ejemplo, si se pasa un nombre de variable a una función de shell como primer argumento, ejecutar

      declare -n ref=$1

dentro de la función crea una variable nameref ref cuyo valor es el nombre de la variable pasado como primer argumento. Las referencias y asignaciones a ref se tratan como referencias y asignaciones a la variable cuyo nombre se pasó como $ 1. Si la variable de control en un bucle for tiene el atributo nameref, la lista de palabras puede ser una lista de variables de shell, y se establecerá una referencia de nombre para cada palabra en la lista, a su vez, cuando se ejecute el bucle. Las variables de matriz no pueden recibir el atributo -n. Sin embargo, las variables nameref pueden hacer referencia a variables de matriz y variables de matriz suscritas. Namerefs se puede ⋅ desarmar usando la opción -n para el desarmado incorporado. De lo contrario, si unset se ejecuta con el nombre de una variable nameref como argumento,

Por ejemplo ( EDIT 2 : (gracias, Ron), el espacio de nombres (prefijado) del nombre de la variable interna de la función, para minimizar los conflictos de variables externas, que finalmente deberían responder adecuadamente, el problema planteado en los comentarios de Karsten):

# $1 : string; your variable to contain the return value
function return_a_string () {
    declare -n ret=$1
    local MYLIB_return_a_string_message="The date is "
    MYLIB_return_a_string_message+=$(date)
    ret=$MYLIB_return_a_string_message
}

y probando este ejemplo:

$ return_a_string result; echo $result
The date is 20160817

Tenga en cuenta que el bash "declare" incorporado, cuando se usa en una función, hace que la variable declarada sea "local" por defecto, y "-n" también se puede usar con "local".

Prefiero distinguir las variables de "declaración importante" de las variables "locales aburridas", por lo que usar "declarar" y "local" de esta manera actúa como documentación.

EDITAR 1 - (Respuesta al comentario de Karsten a continuación) - No puedo agregar más comentarios a continuación, pero el comentario de Karsten me hizo pensar, así que hice la siguiente prueba que FUNCIONA BIEN, AFACIO - Karsten si lees esto, proporciona un conjunto exacto de pasos de prueba desde la línea de comando, que muestra el problema que usted supone que existe, porque estos pasos siguientes funcionan bien:

$ return_a_string ret; echo $ret
The date is 20170104

(Ejecuté esto justo ahora, después de pegar la función anterior en un término bash, como puede ver, el resultado funciona bien).

Al igual que bstpierre arriba, uso y recomiendo el uso de nombrar explícitamente variables de salida:

function some_func() # OUTVAR ARG1
{
   local _outvar=$1
   local _result # Use some naming convention to avoid OUTVARs to clash
   ... some processing ....
   eval $_outvar=\$_result # Instead of just =$_result
}

Tenga en cuenta el uso de citar los $. Esto evitará interpretar el contenido $resultcomo caracteres especiales de shell. He descubierto que este es un orden de magnitud más rápido que el result=$(some_func "arg1")idioma de capturar un eco. La diferencia de velocidad parece aún más notable usando bash en MSYS, donde la captura estándar de llamadas a funciones es casi catastrófica.

Está bien enviar variables locales ya que los locales se definen dinámicamente en bash:

function another_func() # ARG
{
   local result
   some_func result "$1"
   echo result is $result
}

También puede capturar la salida de la función:

#!/bin/bash
function getSomeString() {
     echo "tadaa!"
}

return_var=$(getSomeString)
echo $return_var
# Alternative syntax:
return_var=`getSomeString`
echo $return_var

Parece extraño, pero es mejor que usar variables globales en mi humilde opinión. Pasar parámetros funciona como de costumbre, solo colóquelos dentro de los corchetes o puntos de control.

La solución más directa y robusta es usar la sustitución de comandos, como escribieron otras personas:

assign()
{
    local x
    x="Test"
    echo "$x"
}

x=$(assign) # This assigns string "Test" to x

La desventaja es el rendimiento ya que esto requiere un proceso separado.

La otra técnica sugerida en este tema, es decir, pasar el nombre de una variable para asignar como argumento, tiene efectos secundarios, y no la recomendaría en su forma básica. El problema es que probablemente necesitará algunas variables en la función para calcular el valor de retorno, y puede suceder que el nombre de la variable destinada a almacenar el valor de retorno interfiera con una de ellas:

assign()
{
    local x
    x="Test"
    eval "$1=\$x"
}

assign y # This assigns string "Test" to y, as expected

assign x # This will NOT assign anything to x in this scope
         # because the name "x" is declared as local inside the function

Por supuesto, es posible que no declare las variables internas de la función como locales, pero realmente siempre debe hacerlo, de lo contrario, puede, por otro lado, sobrescribir accidentalmente una variable no relacionada del ámbito primario si hay una con el mismo nombre .

Una posible solución es una declaración explícita de la variable pasada como global:

assign()
{
    local x
    eval declare -g $1
    x="Test"
    eval "$1=\$x"
}

Si se pasa el nombre "x" como argumento, la segunda fila del cuerpo de la función sobrescribirá la declaración local anterior. Pero los nombres mismos pueden interferir, por lo que si tiene la intención de usar el valor previamente almacenado en la variable pasada antes de escribir el valor de retorno allí, tenga en cuenta que debe copiarlo en otra variable local desde el principio; De lo contrario, el resultado será impredecible. Además, esto solo funcionará en la versión más reciente de BASH, es decir, 4.2. Un código más portátil podría utilizar construcciones condicionales explícitas con el mismo efecto:

assign()
{
    if [[ $1 != x ]]; then
      local x
    fi
    x="Test"
    eval "$1=\$x"
}

Quizás la solución más elegante es simplemente reservar un nombre global para los valores de retorno de la función y usarlo de manera consistente en cada función que escriba.

Como se mencionó anteriormente, la forma "correcta" de devolver una cadena de una función es mediante la sustitución de comandos. En el caso de que la función también necesite salir a la consola (como se menciona anteriormente en @Mani), cree un fd temporal al comienzo de la función y redirija a la consola. Cierre el fd temporal antes de devolver su cadena.

#!/bin/bash
# file:  func_return_test.sh
returnString() {
    exec 3>&1 >/dev/tty
    local s=$1
    s=${s:="some default string"}
    echo "writing directly to console"
    exec 3>&-     
    echo "$s"
}

my_string=$(returnString "$*")
echo "my_string:  [$my_string]"

ejecutar script sin parámetros produce ...

# ./func_return_test.sh
writing directly to console
my_string:  [some default string]

espero que esto ayude a las personas

-Andy

Podría usar una variable global:

declare globalvar='some string'

string ()
{
  eval  "$1='some other string'"
} # ----------  end of function string  ----------

string globalvar

echo "'${globalvar}'"

Esto da

'some other string'

Para ilustrar mi comentario sobre la respuesta de Andy, con manipulación adicional del descriptor de archivo para evitar el uso de /dev/tty:

#!/bin/bash

exec 3>&1

returnString() {
    exec 4>&1 >&3
    local s=$1
    s=${s:="some default string"}
    echo "writing to stdout"
    echo "writing to stderr" >&2
    exec >&4-
    echo "$s"
}

my_string=$(returnString "$*")
echo "my_string:  [$my_string]"

Todavía desagradable, sin embargo.

La forma en que lo tiene es la única forma de hacerlo sin romper el alcance. Bash no tiene un concepto de tipos de retorno, solo códigos de salida y descriptores de archivo (stdin / out / err, etc.)

Abordar la cabeza de Vicky Ronnen , considerando el siguiente código:

function use_global
{
    eval "$1='changed using a global var'"
}

function capture_output
{
    echo "always changed"
}

function test_inside_a_func
{
    local _myvar='local starting value'
    echo "3. $_myvar"

    use_global '_myvar'
    echo "4. $_myvar"

    _myvar=$( capture_output )
    echo "5. $_myvar"
}

function only_difference
{
    local _myvar='local starting value'
    echo "7. $_myvar"

    local use_global '_myvar'
    echo "8. $_myvar"

    local _myvar=$( capture_output )
    echo "9. $_myvar"
}

declare myvar='global starting value'
echo "0. $myvar"

use_global 'myvar'
echo "1. $myvar"

myvar=$( capture_output )
echo "2. $myvar"

test_inside_a_func
echo "6. $_myvar" # this was local inside the above function

only_difference

daré

0. global starting value
1. changed using a global var
2. always changed
3. local starting value
4. changed using a global var
5. always changed
6. 
7. local starting value
8. local starting value
9. always changed

Tal vez el escenario normal es usar la sintaxis utilizada en la test_inside_a_funcfunción, por lo que puede usar ambos métodos en la mayoría de los casos, aunque capturar la salida es el método más seguro que siempre funciona en cualquier situación, imitando el valor de retorno de una función que puede encontrar en otros idiomas, como Vicky Ronnense señaló correctamente.

Las opciones se han enumerado todas, creo. Elegir uno puede reducirse a una cuestión del mejor estilo para su aplicación particular, y en ese sentido, quiero ofrecer un estilo particular que he encontrado útil. En bash, las variables y las funciones no están en el mismo espacio de nombres. Entonces, tratar la variable del mismo nombre como el valor de la función es una convención que encuentro minimiza los conflictos de nombres y mejora la legibilidad, si la aplico rigurosamente. Un ejemplo de la vida real:

UnGetChar=
function GetChar() {
    # assume failure
    GetChar=
    # if someone previously "ungot" a char
    if ! [ -z "$UnGetChar" ]; then
        GetChar="$UnGetChar"
        UnGetChar=
        return 0               # success
    # else, if not at EOF
    elif IFS= read -N1 GetChar ; then
        return 0           # success
    else
        return 1           # EOF
    fi
}

function UnGetChar(){
    UnGetChar="$1"
}

Y, un ejemplo del uso de tales funciones:

function GetToken() {
    # assume failure
    GetToken=
    # if at end of file
    if ! GetChar; then
        return 1              # EOF
    # if start of comment
    elif [[ "$GetChar" == "#" ]]; then
        while [[ "$GetChar" != $'\n' ]]; do
            GetToken+="$GetChar"
            GetChar
        done
        UnGetChar "$GetChar"
    # if start of quoted string
    elif [ "$GetChar" == '"' ]; then
# ... et cetera

Como puede ver, el estado de devolución está ahí para que lo use cuando lo necesite, o ignore si no lo necesita. La variable "devuelta" también se puede usar o ignorar, pero, por supuesto, solo después de invocar la función.

Por supuesto, esto es solo una convención. Usted es libre de no establecer el valor asociado antes de regresar (de ahí mi convención de anularlo siempre al comienzo de la función) o de pisotear su valor llamando a la función nuevamente (posiblemente indirectamente). Aún así, es una convención que encuentro muy útil si me encuentro haciendo un uso intensivo de las funciones bash.

A diferencia del sentimiento de que esta es una señal, uno debería, por ejemplo, "pasar a Perl", mi filosofía es que las convenciones siempre son importantes para manejar la complejidad de cualquier idioma.

Puede hacer echouna cadena, pero atraparla canalizando ( |) la función a otra cosa.

Puede hacerlo expr, aunque ShellCheck informa que este uso está en desuso.

El problema clave de cualquier esquema de 'variable de salida con nombre' donde la persona que llama puede pasar el nombre de la variable (ya sea usando evalo declare -n) es un alias involuntario, es decir, conflictos de nombres: desde el punto de vista de la encapsulación, es horrible no poder agregar o renombrar una variable local en una función sin verificar TODAS las llamadas de la función primero para asegurarse de que no quieran pasar el mismo nombre que el parámetro de salida. (O en la otra dirección, no quiero tener que leer la fuente de la función que estoy llamando solo para asegurarme de que el parámetro de salida que pretendo usar no sea un local en esa función).

La única forma REPLYde evitarlo es usar una única variable de salida dedicada como (como lo sugiere Evi1M4chine ) o una convención como la sugerida por Ron Burk .

Sin embargo, es posible que las funciones utilicen una variable de salida fija internamente y luego agreguen algo de azúcar por encima para ocultar este hecho a la persona que llama , como he hecho con la callfunción en el siguiente ejemplo. Considere esto como una prueba de concepto, pero los puntos clave son

• La función siempre asigna el valor de retorno a REPLY, y también puede devolver un código de salida como de costumbre
• Desde la perspectiva de la persona que llama, el valor de retorno puede asignarse a cualquier variable (local o global) incluida REPLY(ver el wrapperejemplo). El código de salida de la función se pasa a través, por lo que su uso en, por ejemplo una ifo whileo construcciones similares funciona como se espera.
• Sintácticamente, la llamada a la función sigue siendo una sola declaración simple.

La razón por la que esto funciona es porque la callfunción en sí no tiene locales y no utiliza otras variables que no sean REPLY, evitando posibles conflictos de nombres. En el punto donde se asigna el nombre de la variable de salida definida por el llamador, estamos efectivamente en el alcance del llamador (técnicamente en el alcance idéntico de la callfunción), en lugar del alcance de la función que se llama.

#!/bin/bash
function call() { # var=func [args ...]
  REPLY=; "${1#*=}" "${@:2}"; eval "${1%%=*}=\$REPLY; return $?"
}

function greet() {
  case "$1" in
    us) REPLY="hello";;
    nz) REPLY="kia ora";;
    *) return 123;;
  esac
}

function wrapper() {
  call REPLY=greet "$@"
}

function main() {
  local a b c d
  call a=greet us
  echo "a='$a' ($?)"
  call b=greet nz
  echo "b='$b' ($?)"
  call c=greet de
  echo "c='$c' ($?)"
  call d=wrapper us
  echo "d='$d' ($?)"
}
main

Salida:

a='hello' (0)
b='kia ora' (0)
c='' (123)
d='hello' (0)

patrón bash para devolver objetos de valor escalar y de matriz :

definición

url_parse() { # parse 'url' into: 'url_host', 'url_port', ...
   local "$@" # inject caller 'url' argument in local scope
   local url_host="..." url_path="..." # calculate 'url_*' components
   declare -p ${!url_*} # return only 'url_*' object fields to the caller
}

invocación

main() { # invoke url parser and inject 'url_*' results in local scope
   eval "$(url_parse url=http://host/path)" # parse 'url'
   echo "host=$url_host path=$url_path" # use 'url_*' components
}

En mis programas, por convención, esto es para lo que sirve la $REPLYvariable preexistente , que se readusa para ese propósito exacto.

function getSomeString {
  REPLY="tadaa"
}

getSomeString
echo $REPLY

Esto echoes

tadaa

Pero para evitar conflictos, cualquier otra variable global servirá.

declare result

function getSomeString {
  result="tadaa"
}

getSomeString
echo $result

Si eso no es suficiente, recomiendo la solución de Markarian451 .

agt@agtsoft:~/temp$ cat ./fc 
#!/bin/sh

fcall='function fcall { local res p=$1; shift; fname $*; eval "$p=$res"; }; fcall'

function f1 {
    res=$[($1+$2)*2];
}

function f2 {
    local a;
    eval ${fcall//fname/f1} a 2 3;
    echo f2:$a;
}

a=3;
f2;
echo after:a=$a, res=$res

agt@agtsoft:~/temp$ ./fc
f2:10
after:a=3, res=