Unset readonly variable in bash

BashUnset

Bash Problem Overview

How do I unset a readonly variable in Bash?

$ readonly PI=3.14

$ unset PI
bash: PI: readonly variable

or is it not possible?

Bash Solutions

Solution 1 - Bash

Actually, you can unset a readonly variable. but I must warn that this is a hacky method. Adding this answer, only as information, not as a recommendation. Use it at your own risk. Tested on ubuntu 13.04, bash 4.2.45.

This method involves knowing a bit of bash source code & it's inherited from this answer.

$ readonly PI=3.14
$ unset PI
-bash: unset: PI: cannot unset: readonly variable
$ cat << EOF| sudo gdb
attach $$
call unbind_variable("PI")
detach
EOF
$ echo $PI

$

A oneliner answer is to use the batch mode and other commandline flags, as provided in F. Hauri's answer:

$ sudo gdb -ex 'call unbind_variable("PI")' --pid=$$ --batch

sudo may or may not be needed based on your kernel's ptrace_scope settings. Check the comments on vip9937's answer for more details.

Solution 2 - Bash

I tried the gdb hack above because I want to unset TMOUT (to disable auto-logout), but on the machine that has TMOUT set as read only, I'm not allowed to use sudo. But since I own the bash process, I don't need sudo. However, the syntax didn't quite work with the machine I'm on.

This did work, though (I put it in my .bashrc file):

# Disable the stupid auto-logout
unset TMOUT > /dev/null 2>&1
if [ $? -ne 0 ]; then
    gdb <<EOF > /dev/null 2>&1
 attach $$
 call unbind_variable("TMOUT")
 detach
 quit
EOF
fi

Solution 3 - Bash

Shortly: inspired by anishsane's answer

Edit 2021-11-10: Add (int) to cast unbind_variable result.

But with simplier syntax:

$ gdb -ex 'call (int) unbind_variable("PI")' --pid=$$ --batch

With some improvement, as a function:

My destroy function:

Or How to play with variable meta data. Note usage of rare bashisms: local -n VARIABLE=$1 and ${VARIABLE@a}...

destroy () { 
    declare -p $1 &>/dev/null || return -1 # Return if variable not exist
    local -n variable=$1
    local reslne result flags=${variable@a}
    [ -z "$flags" ] || [ "${flags//*r*}" ] && { 
        unset $1    # Don't run gdb if variable is not readonly.
        return $?
    }
    while read -r resline; do
        [ "$resline" ] && [ -z "${resline%%\$1 = *}" ] &&
            result=${resline##*1 = }
    done < <(
        exec gdb 2>&1 -ex 'call (int) unbind_variable("'$1'")' --pid=$$ --batch
    )
    return $result
}

You could copy this to a bash source file called destroy.bash, for sample...

Explanation:

> 1 destroy () { > 2 local -n variable=$1 > 3 declare -p $1 &>/dev/null || return -1 # Return if variable not exist > 4 local reslne result flags=${variable@a} > 5 [ -z "$flags" ] || [ "${flags//r}" ] && { > 6 unset $1 # Don't run gdb if variable is not readonly. > 7 return $? > 8 } > 9 while read resline; do > 10 [ "$resline" ] && [ -z "${resline%$1 = *}" ] && > 11 result=${resline##*1 = } > 12 done < <( > 13 gdb 2>&1 -ex 'call (int) unbind_variable("'$1'")' --pid=$$ --batch > 14 ) > 15 return $result > 16 }

  • line 2 create a local reference to submited variable.
  • line 3 prevent running on non existant variable
  • line 4 store parameter's attributes (meta) into $flags.
  • lines 5 to 8 will run unset instead of gdb if readonly flag not present
  • lines 9 to 12 while read ... result= ... done get return code of call (int) unbind_variable() in gdb output
  • line 13 gdb syntax with use of --pid and --ex (see gdb --help).
  • line 15 return $result of unbind_variable() command.
In use:
$ . destroy.bash

  • 1st with any regular (read-write) variable:

    $ declare PI=$(bc -l <<<'4*a(1)')
$ echo $PI
3.14159265358979323844
$ echo ${PI@a} # flags

$ declare -p PI
declare -- PI="3.14159265358979323844"
$ destroy PI
$ echo $?
0
$ declare -p PI
bash: declare: PI: not found

  • 2nd with read only variable:

    $ declare -r PI=$(bc -l <<<'4*a(1)')
$ declare -p PI
declare -r PI="3.14159265358979323844"
$ echo ${PI@a} # flags
r
$ unset PI
bash: unset: PI: cannot unset: readonly variable

$ destroy PI
$ echo $?
0
$ declare -p PI
bash: declare: PI: not found

  • 3rd with non existant variable:

    $ destroy PI
$ echo $?
255

Solution 4 - Bash

In zsh,

% typeset +r PI
% unset PI

(Yes, I know the question says bash. But when you Google for zsh, you also get a bunch of bash questions.)

Solution 5 - Bash

Using GDB is terribly slow, or may even be forbidden by system policy (ie can't attach to process.)

Try ctypes.sh instead. It works by using libffi to directly call bash's unbind_variable() instead, which is every bit as fast as using any other bash builtin:

$ readonly PI=3.14
$ unset PI
bash: unset: PI: cannot unset: readonly variable

$ source ctypes.sh
$ dlcall unbind_variable string:PI

$ declare -p PI
bash: declare: PI: not found

First you will need to install ctypes.sh:

$ git clone https://github.com/taviso/ctypes.sh.git
$ cd ctypes.sh
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

See https://github.com/taviso/ctypes.sh for a full description and docs.

For the curious, yes this lets you call any function within bash, or any function in any library linked to bash, or even any external dynamically-loaded library if you like. Bash is now every bit as dangerous as perl... ;-)

Solution 6 - Bash

According to the man page:

   unset [-fv] [name ...]
          ...   Read-only  variables  may  not  be
          unset. ...

If you have not yet exported the variable, you can use exec "$0" "$@" to restart your shell, of course you will lose all other un-exported variables as well. It seems if you start a new shell without exec, it loses its read-only property for that shell.

Solution 7 - Bash

Specifically wrt to the TMOUT variable. Another option if gdb is not available is to copy bash to your home directory and patch the TMOUT string in the binary to something else, for instance XMOUX. And then run this extra layer of shell and you will not be timed out.

Solution 8 - Bash

$ PI=3.17
$ export PI
$ readonly PI
$ echo $PI
3.17
$ PI=3.14
-bash: PI: readonly variable
$ echo $PI
3.17

What to do now?

$ exec $BASH
$ echo $PI
3.17
$ PI=3.14
$ echo $PI
3.14
$

A subshell can inherit the parent's variables, but won't inherit their protected status.

Solution 9 - Bash

readonly command makes it final and permanent until the shell process terminates. If you need to change a variable, don't mark it readonly.

Solution 10 - Bash

An alternative if gdb is unavailable: You can use the enable command to load a custom builtin that will let you unset the read-only attribute. The gist of the code that does it:

SETVARATTR (find_variable ("TMOUT"), att_readonly, 1);

Obviously, you'd replace TMOUT with the variable you care about.

If you don't want to turn that into a builtin yourself, I forked bash in GitHub and added a fully-written and ready-to-compile loadable builtin called readwrite. The commit is at https://github.com/josephcsible/bash/commit/bcec716f4ca958e9c55a976050947d2327bcc195. If you want to use it, get the Bash source with my commit, run ./configure && make && make loadables to build it, then enable -f examples/loadables/readwrite readwrite to add it to your running session, then readwrite TMOUT to use it.

Solution 11 - Bash

No, not in the current shell. If you wish to assign a new value to it, you will have to fork a new shell where it will have a new meaning and will not be considered as read only.

$ { ( readonly pi=3.14; echo $pi ); pi=400; echo $pi; unset pi; echo [$pi]; }
3.14
400
[]

Solution 12 - Bash

You can't, from manual page of unset:

>For each name, remove the corresponding variable or function. If no options are supplied, or the -v option is given, each name refers to a shell variable. Read-only variables may not be unset. If -f is specifed, each name refers to a shell function, and the function definition is removed. Each unset variable or function is removed from the environment passed to subsequent commands. If any of RANDOM, SECONDS, LINENO, HISTCMD, FUNCNAME, GROUPS, or DIRSTACK are unset, they lose their special properties, even if they are subsequently reset. The exit status is true unless a name is readonly.

Solution 13 - Bash

One other way to "unset" a read-only variable in Bash is to declare that variable read-only in a disposable context:

foo(){ declare -r PI=3.14; baz; }
bar(){ local PI=3.14; baz; }

baz(){ PI=3.1415927; echo PI=$PI; }

foo;

> bash: PI: readonly variable

bar;

> PI=3.1415927

While this is not "unsetting" within scope, which is probably the intent of the original author, this is definitely setting a variable read-only from the point of view of baz() and then later making it read-write from the point of view of baz(), you just need to write your script with some forethought.

Solution 14 - Bash

Another solution without GDB or an external binary, (in fact an emphasis on Graham Nicholls comment) would be the use of exec.

In my case there were an annoying read-only variable set in /etc/profile.d/xxx.

Quoting the bash manual: > "When bash is invoked as an interactive login shell [...] it first reads and executes commands from the file /etc/profile" [...] > > When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc [...]

The gist of my workaround was to put in my ~/.bash_profile:

if [ -n "$annoying_variable" ]
then exec env annoying_variable='' /bin/bash
# or: then exec env -i /bin/bash
fi

Warning: to avoid a recursion (which would lock you out if you can only access your account through SSH), one should ensure the "annoying variable" will not be automatically set by the bashrc or to set another variable on the check, for example:

if [ -n "$annoying_variable" ] && [ "${SHLVL:-1}" = 1 ]
then exec env annoying_variable='' SHLVL=$((SHLVL+1)) ${SHELL:-/bin/bash}
fi

Solution 15 - Bash

$ readonly PI=3.14

$ unset PI
bash: PI: readonly variable

$ gdb --batch-silent --pid=$$ --eval-command='call (int) unbind_variable("PI")'

$ [[ ! -v PI ]] && echo "PI is unset ✔️"
PI is unset ✔️

Notes:

  1. Tested with bash 5.0.17 and gdb 10.1.
  2. The -v varname test was added in bash 4.2. It is "True if the shell variable varname is set (has been assigned a value)." – bash reference manual
  3. Note the cast to int. Without that, the following error will result: 'unbind_variable' has unknown return type; cast the call to its declared return type. The bash source code shows that the return type of the unbind_variable function is int.
  4. This answer is essentially the same as an answer over at superuser.com. I added the cast to int to get past the unknown return type error.

Solution 16 - Bash

if nothing helps, you could go back in time, to a time where readonly vars were not yet implemented:

env ENV=$HOME/.profile /bin/sh

and in $HOME/.profile show some good will and say

export TMOUT=901

This gives you one extra second before you are logged out :-)

Categories
Recommended Bash Solutions

Previous Solution:

invalid_client in google oauth2

Google OauthGoogle Data-ApiOauth2 Playground

Next Solution:

unique_ptr to a derived class as an argument to a function that takes a unique_ptr to a base class

C++Visual Studio-2012C++11Unique Ptr

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionKokizzuView Question on Stackoverflow
Solution 1 - BashanishsaneView Answer on Stackoverflow
Solution 2 - Bashvip9937View Answer on Stackoverflow
Solution 3 - BashF. HauriView Answer on Stackoverflow
Solution 4 - BashRadon RosboroughView Answer on Stackoverflow
Solution 5 - BashWilView Answer on Stackoverflow
Solution 6 - BashKevinView Answer on Stackoverflow
Solution 7 - Bashuser1089933View Answer on Stackoverflow
Solution 8 - BashjezzaaaaView Answer on Stackoverflow
Solution 9 - BashAmitView Answer on Stackoverflow
Solution 10 - BashJoseph Sible-Reinstate MonicaView Answer on Stackoverflow
Solution 11 - Bashjaypal singhView Answer on Stackoverflow
Solution 12 - BashYu HaoView Answer on Stackoverflow
Solution 13 - BashWilView Answer on Stackoverflow
Solution 14 - BashbufhView Answer on Stackoverflow
Solution 15 - BashRobin A. MeadeView Answer on Stackoverflow
Solution 16 - BashSiegfriedView Answer on Stackoverflow