Как я могу отменить экспорт переменной без потери ее значения?

Допустим, я экспортировал переменную:

foo=bar
export foo

Теперь я хотел бы отменить экспорт. То есть, если я это сделаю, sh -c 'echo "$foo"'я не должен получить bar. fooвообще не должен появляться в sh -cроссийской среде. sh -cэто просто пример, простой способ показать наличие переменной. Командой может быть что угодно - это может быть что-то, на чье поведение влияет просто наличие переменной в ее окружении.

Я могу:

1. unset переменная, и потерять ее
2. Удалите его, используя envдля каждой команды:env -u foo sh -c 'echo "$foo"'
   • нецелесообразно, если вы хотите продолжить использовать текущую оболочку на некоторое время.

В идеале я хотел бы сохранить значение переменной, но не показывать его вообще в дочернем процессе, даже в виде пустой переменной.

Я думаю, я мог бы сделать:

otherfoo="$foo"; unset foo; foo="$otherfoo"; unset otherfoo

Это может растоптать otherfoo, если оно уже существует.

Это единственный способ? Есть ли стандартные способы?

Там нет стандартного способа.

Вы можете избежать использования временной переменной с помощью функции. Следующая функция заботится о том, чтобы неустановленные переменные оставались неустановленными, а пустые переменные оставались пустыми. Однако он не поддерживает функции, присутствующие в некоторых оболочках, такие как переменные только для чтения или типизированные переменные.

unexport () {
  while [ "$#" -ne 0 ]; do
    eval "set -- \"\${$1}\" \"\${$1+set}\" \"\$@\""
    if [ -n "$2" ]; then
      unset "$3"
      eval "$3=\$1"
    fi
    shift; shift; shift
  done
}
unexport foo bar

В ksh, bash и zsh вы можете удалить переменную с помощью typeset +x foo. Это сохраняет специальные свойства, такие как типы, поэтому предпочтительно использовать его. Я думаю, что все оболочки, которые имеют typesetвстроенные, имеют typeset +x.

case $(LC_ALL=C type typeset 2>&1) in
  typeset\ *\ builtin) unexport () { typeset +x -- "$@"; };;
  *) unexport () { … };; # code above
esac

EDIT: Для bashтолько, как указано в комментариях:

-nВариант exportудаляет exportсвойство из каждого имени. (См help export.)

Поэтому для bash, команда , которую вы хотите есть:export -n foo

Я написал аналогичную функцию POSIX, но это не рискует выполнить произвольный код:

unexport()
    while case ${1##[0-9]*} in                   ### rule out leading numerics
          (*[!_[:alnum:]]*|"")                   ### filter out bad|empty names
          set "" ${1+"bad name: '$1'"}           ### prep bad name error
          return ${2+${1:?"$2"}}                 ### fail w/ above err or return 
          esac
    do    eval  set '"$'"{$1+$1}"'" "$'"$1"'" "$'@\" ###  $1 = (  $1+ ? $1 : "" )
          eval  "${1:+unset $1;$1=\$2;} shift 3"     ### $$1 = ( $1:+ ? $2 : -- )
    done

Он также будет обрабатывать столько аргументов, сколько вы пожелаете предоставить. Если аргумент является допустимым именем, которое в противном случае уже не задано, оно игнорируется. Если аргумент является неправильным именем, он записывает в stderr и останавливается соответствующим образом, хотя любое действительное имя, предшествующее недопустимому в его командной строке, все равно будет обработано.

Я думал о другом способе. Мне это нравится намного лучше.

unexport()
        while   unset OPTARG; OPTIND=1           ### always work w/ $1
                case  ${1##[0-9]*}    in         ### same old same old
                (*[!_[:alnum:]]*|"")             ### goodname && $# > 0 || break
                    ${1+"getopts"} : "$1"        ### $# ? getopts : ":"
                    return                       ### getopts errored or ":" didnt
                esac
        do      eval   getopts :s: '"$1" -"${'"$1+s}-\$$1\""
                eval   unset  "$1;  ${OPTARG+$1=\${OPTARG}#-}"
                shift
        done

Хорошо, оба из них используют много тех же самых методов. В основном, если оболочка var не установлена, ссылка на нее не будет расширяться с +расширением параметра. Но если он установлен - независимо от его значения - расширение параметра, подобное: ${parameter+word}будет расширяться до word-, а не до значения переменной. И так переменные оболочки самопроверка и подстановка на успех.

Они также могут потерпеть неудачу . В верхней функции, если найдено плохое имя, я вхожу $1в ноль $2и оставляю $1ноль, потому что следующее, что я делаю, это либо returnуспех, если все аргументы были обработаны и цикл заканчивается, либо, если аргумент был недействительным, оболочка будет разверните объект, $2в $1:?котором будет уничтожена сценарий оболочки и верните прерывание интерактивному при записи wordв stderr.

Во втором getoptsделает задания. И это не будет назначать плохое имя - скорее напишите, это напишет стандартное сообщение об ошибке в stderr. Более того, он сохраняет значение аргумента в том $OPTARG случае, если аргумент был именем переменной набора в первую очередь. Таким образом, после выполнения getoptsвсе, что необходимо, это расширение evalнабора OPTARGв соответствующее назначение.