Temporarily declare a variable in Bash
up vote
1
down vote
favorite
To declare a variable in Bash, say in a Bash script-file (that doesn't include Bash function), I do for example x=y
and when I finish using it inside that script-file I do unset x
.
Is there a way (without using a function), to unset the variable after say 5 minutes, both in one line? A plausible approach might be x=y && echo "unset x" | at now + 5 minutes
.
In this particular case I run the script-file directly in the terminal by copy-pasting its content from GitHub to terminal. This falls under sourcing I assume".
Given I use GitHub an alternative might be executing a raw version of the script-file directly from GitHub as follows but I don't like that way because it can't be user-agnostic or repo-agnostic (of course):
wget -O - https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> | bash
bash variable at
add a comment |
up vote
1
down vote
favorite
To declare a variable in Bash, say in a Bash script-file (that doesn't include Bash function), I do for example x=y
and when I finish using it inside that script-file I do unset x
.
Is there a way (without using a function), to unset the variable after say 5 minutes, both in one line? A plausible approach might be x=y && echo "unset x" | at now + 5 minutes
.
In this particular case I run the script-file directly in the terminal by copy-pasting its content from GitHub to terminal. This falls under sourcing I assume".
Given I use GitHub an alternative might be executing a raw version of the script-file directly from GitHub as follows but I don't like that way because it can't be user-agnostic or repo-agnostic (of course):
wget -O - https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> | bash
bash variable at
1
You need to dounset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have$i
in my shell.
– Weijun Zhou
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
1
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
To declare a variable in Bash, say in a Bash script-file (that doesn't include Bash function), I do for example x=y
and when I finish using it inside that script-file I do unset x
.
Is there a way (without using a function), to unset the variable after say 5 minutes, both in one line? A plausible approach might be x=y && echo "unset x" | at now + 5 minutes
.
In this particular case I run the script-file directly in the terminal by copy-pasting its content from GitHub to terminal. This falls under sourcing I assume".
Given I use GitHub an alternative might be executing a raw version of the script-file directly from GitHub as follows but I don't like that way because it can't be user-agnostic or repo-agnostic (of course):
wget -O - https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> | bash
bash variable at
To declare a variable in Bash, say in a Bash script-file (that doesn't include Bash function), I do for example x=y
and when I finish using it inside that script-file I do unset x
.
Is there a way (without using a function), to unset the variable after say 5 minutes, both in one line? A plausible approach might be x=y && echo "unset x" | at now + 5 minutes
.
In this particular case I run the script-file directly in the terminal by copy-pasting its content from GitHub to terminal. This falls under sourcing I assume".
Given I use GitHub an alternative might be executing a raw version of the script-file directly from GitHub as follows but I don't like that way because it can't be user-agnostic or repo-agnostic (of course):
wget -O - https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> | bash
bash variable at
bash variable at
edited 13 hours ago
asked yesterday
JohnDoea
821132
821132
1
You need to dounset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have$i
in my shell.
– Weijun Zhou
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
1
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago
add a comment |
1
You need to dounset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have$i
in my shell.
– Weijun Zhou
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
1
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago
1
1
You need to do
unset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like ( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have $i
in my shell.– Weijun Zhou
yesterday
You need to do
unset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like ( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have $i
in my shell.– Weijun Zhou
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
1
1
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago
add a comment |
4 Answers
4
active
oldest
votes
up vote
6
down vote
accepted
You can't use at
jobs because they run in a different context, and can't affect the current shell.
But we can do something similar. This code will trigger an alarm signal, which we can catch and perform action on
#!/bin/bash
x=100
trap 'unset x' SIGALRM
mypid=$$
( /bin/sleep 3 ; kill -ALRM $mypid) &
for a in 1 2 3 4 5 6
do
echo Now x=$x
sleep 1
done
This example is only 3 seconds long to demonstrate the solution; you can pick your delay as you need.
In action:
Now x=100
Now x=100
Now x=100
Now x=
Now x=
Now x=
You can easily make it one line with ;
...
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean thefor
loop won't demonstrate the solution working. I'll edit the answer to make that clear.
– Stephen Harris
yesterday
add a comment |
up vote
6
down vote
Sure:
trap 'unset x; trap - USR1' USR1; { sleep 5m; kill -USR1 $$; } &
This sets a trap on the USR1 signal, then (cheating with a semicolon to put it on one line) groups together the sleep and kill commands into a background job. When that job completes, it will send the USR1 signal to the current shell, which will execute the trap. The trap unsets x
and then clears the trap.
No functions!
add a comment |
up vote
1
down vote
With your revised question, based around the command line and not a script, your simplest solution is to use a subshell to do your work.
eg
$ bash
$ x=100
$ echo $x
100
$ exit
$ echo $x
$
All the variables you set between running bash
and exit
ing that shell will be forgotten.
This is very close to how the wget ... | bash
part works as well, except you can cut'n'paste/type commands.
add a comment |
up vote
0
down vote
Actually the simplest way might be to just use a compound command with a variable declaration at the start.
If you declare a variable at the start of a command line, the variable is temporarily defined only for the scope of that command.
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y bash -c 'echo $x'
y
madumlao@lezard:~$ echo $x
foo
As you can see, the line with a variable declaration only sets the variable in the environment for that line only.
Note that the following will not work:
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y echo $x
madumlao@lezard:~$ echo $x
foo
The $x in the second line is parsed during command-line parsing, before the value is actually assigned, so it is unexpectedly blank!
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487683%2ftemporarily-declare-a-variable-in-bash%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
You can't use at
jobs because they run in a different context, and can't affect the current shell.
But we can do something similar. This code will trigger an alarm signal, which we can catch and perform action on
#!/bin/bash
x=100
trap 'unset x' SIGALRM
mypid=$$
( /bin/sleep 3 ; kill -ALRM $mypid) &
for a in 1 2 3 4 5 6
do
echo Now x=$x
sleep 1
done
This example is only 3 seconds long to demonstrate the solution; you can pick your delay as you need.
In action:
Now x=100
Now x=100
Now x=100
Now x=
Now x=
Now x=
You can easily make it one line with ;
...
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean thefor
loop won't demonstrate the solution working. I'll edit the answer to make that clear.
– Stephen Harris
yesterday
add a comment |
up vote
6
down vote
accepted
You can't use at
jobs because they run in a different context, and can't affect the current shell.
But we can do something similar. This code will trigger an alarm signal, which we can catch and perform action on
#!/bin/bash
x=100
trap 'unset x' SIGALRM
mypid=$$
( /bin/sleep 3 ; kill -ALRM $mypid) &
for a in 1 2 3 4 5 6
do
echo Now x=$x
sleep 1
done
This example is only 3 seconds long to demonstrate the solution; you can pick your delay as you need.
In action:
Now x=100
Now x=100
Now x=100
Now x=
Now x=
Now x=
You can easily make it one line with ;
...
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean thefor
loop won't demonstrate the solution working. I'll edit the answer to make that clear.
– Stephen Harris
yesterday
add a comment |
up vote
6
down vote
accepted
up vote
6
down vote
accepted
You can't use at
jobs because they run in a different context, and can't affect the current shell.
But we can do something similar. This code will trigger an alarm signal, which we can catch and perform action on
#!/bin/bash
x=100
trap 'unset x' SIGALRM
mypid=$$
( /bin/sleep 3 ; kill -ALRM $mypid) &
for a in 1 2 3 4 5 6
do
echo Now x=$x
sleep 1
done
This example is only 3 seconds long to demonstrate the solution; you can pick your delay as you need.
In action:
Now x=100
Now x=100
Now x=100
Now x=
Now x=
Now x=
You can easily make it one line with ;
...
You can't use at
jobs because they run in a different context, and can't affect the current shell.
But we can do something similar. This code will trigger an alarm signal, which we can catch and perform action on
#!/bin/bash
x=100
trap 'unset x' SIGALRM
mypid=$$
( /bin/sleep 3 ; kill -ALRM $mypid) &
for a in 1 2 3 4 5 6
do
echo Now x=$x
sleep 1
done
This example is only 3 seconds long to demonstrate the solution; you can pick your delay as you need.
In action:
Now x=100
Now x=100
Now x=100
Now x=
Now x=
Now x=
You can easily make it one line with ;
...
edited yesterday
answered yesterday
Stephen Harris
24k24477
24k24477
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean thefor
loop won't demonstrate the solution working. I'll edit the answer to make that clear.
– Stephen Harris
yesterday
add a comment |
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean thefor
loop won't demonstrate the solution working. I'll edit the answer to make that clear.
– Stephen Harris
yesterday
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
Wow - great minds think alike -- and within 30 seconds of each other! :)
– Jeff Schaller
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
@JeffSchaller I noticed that :-)
– Stephen Harris
yesterday
1
1
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean the
for
loop won't demonstrate the solution working. I'll edit the answer to make that clear.– Stephen Harris
yesterday
@JeffSchaller I rolled back your edit; I specifically put a 3 second pause in as an example; a 300 second (5minute) sleep would mean the
for
loop won't demonstrate the solution working. I'll edit the answer to make that clear.– Stephen Harris
yesterday
add a comment |
up vote
6
down vote
Sure:
trap 'unset x; trap - USR1' USR1; { sleep 5m; kill -USR1 $$; } &
This sets a trap on the USR1 signal, then (cheating with a semicolon to put it on one line) groups together the sleep and kill commands into a background job. When that job completes, it will send the USR1 signal to the current shell, which will execute the trap. The trap unsets x
and then clears the trap.
No functions!
add a comment |
up vote
6
down vote
Sure:
trap 'unset x; trap - USR1' USR1; { sleep 5m; kill -USR1 $$; } &
This sets a trap on the USR1 signal, then (cheating with a semicolon to put it on one line) groups together the sleep and kill commands into a background job. When that job completes, it will send the USR1 signal to the current shell, which will execute the trap. The trap unsets x
and then clears the trap.
No functions!
add a comment |
up vote
6
down vote
up vote
6
down vote
Sure:
trap 'unset x; trap - USR1' USR1; { sleep 5m; kill -USR1 $$; } &
This sets a trap on the USR1 signal, then (cheating with a semicolon to put it on one line) groups together the sleep and kill commands into a background job. When that job completes, it will send the USR1 signal to the current shell, which will execute the trap. The trap unsets x
and then clears the trap.
No functions!
Sure:
trap 'unset x; trap - USR1' USR1; { sleep 5m; kill -USR1 $$; } &
This sets a trap on the USR1 signal, then (cheating with a semicolon to put it on one line) groups together the sleep and kill commands into a background job. When that job completes, it will send the USR1 signal to the current shell, which will execute the trap. The trap unsets x
and then clears the trap.
No functions!
edited yesterday
answered yesterday
Jeff Schaller
37.8k1053122
37.8k1053122
add a comment |
add a comment |
up vote
1
down vote
With your revised question, based around the command line and not a script, your simplest solution is to use a subshell to do your work.
eg
$ bash
$ x=100
$ echo $x
100
$ exit
$ echo $x
$
All the variables you set between running bash
and exit
ing that shell will be forgotten.
This is very close to how the wget ... | bash
part works as well, except you can cut'n'paste/type commands.
add a comment |
up vote
1
down vote
With your revised question, based around the command line and not a script, your simplest solution is to use a subshell to do your work.
eg
$ bash
$ x=100
$ echo $x
100
$ exit
$ echo $x
$
All the variables you set between running bash
and exit
ing that shell will be forgotten.
This is very close to how the wget ... | bash
part works as well, except you can cut'n'paste/type commands.
add a comment |
up vote
1
down vote
up vote
1
down vote
With your revised question, based around the command line and not a script, your simplest solution is to use a subshell to do your work.
eg
$ bash
$ x=100
$ echo $x
100
$ exit
$ echo $x
$
All the variables you set between running bash
and exit
ing that shell will be forgotten.
This is very close to how the wget ... | bash
part works as well, except you can cut'n'paste/type commands.
With your revised question, based around the command line and not a script, your simplest solution is to use a subshell to do your work.
eg
$ bash
$ x=100
$ echo $x
100
$ exit
$ echo $x
$
All the variables you set between running bash
and exit
ing that shell will be forgotten.
This is very close to how the wget ... | bash
part works as well, except you can cut'n'paste/type commands.
answered 13 hours ago
Stephen Harris
24k24477
24k24477
add a comment |
add a comment |
up vote
0
down vote
Actually the simplest way might be to just use a compound command with a variable declaration at the start.
If you declare a variable at the start of a command line, the variable is temporarily defined only for the scope of that command.
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y bash -c 'echo $x'
y
madumlao@lezard:~$ echo $x
foo
As you can see, the line with a variable declaration only sets the variable in the environment for that line only.
Note that the following will not work:
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y echo $x
madumlao@lezard:~$ echo $x
foo
The $x in the second line is parsed during command-line parsing, before the value is actually assigned, so it is unexpectedly blank!
add a comment |
up vote
0
down vote
Actually the simplest way might be to just use a compound command with a variable declaration at the start.
If you declare a variable at the start of a command line, the variable is temporarily defined only for the scope of that command.
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y bash -c 'echo $x'
y
madumlao@lezard:~$ echo $x
foo
As you can see, the line with a variable declaration only sets the variable in the environment for that line only.
Note that the following will not work:
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y echo $x
madumlao@lezard:~$ echo $x
foo
The $x in the second line is parsed during command-line parsing, before the value is actually assigned, so it is unexpectedly blank!
add a comment |
up vote
0
down vote
up vote
0
down vote
Actually the simplest way might be to just use a compound command with a variable declaration at the start.
If you declare a variable at the start of a command line, the variable is temporarily defined only for the scope of that command.
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y bash -c 'echo $x'
y
madumlao@lezard:~$ echo $x
foo
As you can see, the line with a variable declaration only sets the variable in the environment for that line only.
Note that the following will not work:
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y echo $x
madumlao@lezard:~$ echo $x
foo
The $x in the second line is parsed during command-line parsing, before the value is actually assigned, so it is unexpectedly blank!
Actually the simplest way might be to just use a compound command with a variable declaration at the start.
If you declare a variable at the start of a command line, the variable is temporarily defined only for the scope of that command.
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y bash -c 'echo $x'
y
madumlao@lezard:~$ echo $x
foo
As you can see, the line with a variable declaration only sets the variable in the environment for that line only.
Note that the following will not work:
madumlao@lezard:~$ x=foo
madumlao@lezard:~$ x=y echo $x
madumlao@lezard:~$ echo $x
foo
The $x in the second line is parsed during command-line parsing, before the value is actually assigned, so it is unexpectedly blank!
answered 14 hours ago
madumlao
1,13166
1,13166
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487683%2ftemporarily-declare-a-variable-in-bash%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
You need to do
unset x
only if you are sourcing the script file. Otherwise the script runs in a subshell and does not affect your shell environment, so you don't need to unset it. I use parentheses to run one-liners with temporary variables on the command line all the time, like( for i in {1..20}; do dosomething; done)
, and after I execute this command I don't have$i
in my shell.– Weijun Zhou
yesterday
If you're trying to do that for "security" purposes (ie. that var holds a password), then keep in mind that unsetting a variable does not guarantee in any way that its content will be scrubbed from memory. Simply put, keeping sensitive data in plain text in shell variables is not something that should be done for 5 secs, 5 minutes or 5 hours.
– pizdelect
yesterday
1
@WeijunZhou I updated the question due to your comment.
– JohnDoea
15 hours ago