I am operating in a Kor开发者_StackOverflow社区n Shell, and attempting to run a simple chdb script I wrote. If run with no arguments, it prompts the user with a list of databases and waits for a selection. If called with a single numeric argument, it will automatically make the selection for the user.
Example:
> . chdb
Select the database sid from the following:
1) testdb1
2) testdb2
3) testdb3
Selection: 2 <-- user entered
Environment is now set up for testdb2.
>. chdb 2
Environment is now set up for testdb2.
>
My problem is that when I run the script with an argument as above, and then try to run it again with no arguments, it still uses the old arguments.
Example:
> . chdb 2
Environment is now set up for testdb2.
> . chdb
Environment is now set up for testdb2.
>
EDIT: I am using the dot because I am setting variables in the environment and do not want to invoke a child shell instance, otherwise the database setup won't work. I have a feeling this may be the source of my problem, but I am not sure how to work around it.
One other thing that might be worth mentioning is that calling my script with at least 1 argument will always work as intended. It never uses previously entered arguments unless it is invoked with no parameters.
Try: after input=$arg
, doing an unset arg
, or quote if [["$#" -ne "1"]]
If you're using a script with '.' to set environment variables, then any variables you declare in that script will automatically be global, and pass into the session of the invoking shell.
There are three approaches to isolate your variables and make them non-persistent:
1. Initialise Variables
If you're using a single variable to capture the user selection e.g. DBSELECTION, whether passed on the command line or entered in interactive mode, then you may wish to start your script by initialising that variable to an empty string;
DBSELECTION=""
if [ "$1ZZZ" != "ZZZ" ] ; then
DBSELECTION=$1
else
interactiveMode
fi
-- where "interactiveMode" is your defined process for getting the user selection. Your method or function names may vary, of course.
2. Unset Variables
If you're using temporary variables to register the user selection - like the one above, DBSELECTION, you may want to unset the variable at the end of your script;
DBSELECTION=""
if [ "$1ZZZ" != "ZZZ" ] ; then
DBSELECTION=$1
else
interactiveMode
fi
unset DBSELECTION
3. Define Local rather than Global Variables
If you're using temporary variables, it may be more advisable to define them locally (using typeset) instead of globally, so that they do not persist beyond the function within which they're defined.
typeset DBSELECTION=""
if [ "$1ZZZ" != "ZZZ" ] ; then
DBSELECTION=$1
else
interactiveMode
fi
In this way ksh will handle the variable for you, rather than explicitly unsetting it yourself.
Also - you are running the code 'sourced' which means all of the envrionment variables declared in the script are still there when you run it again.
Try
./chdb
instead of
. chdb
I figured out a way to handle this. I added set --
at the end of my script so that it unsets all of the arguments.
For anyone else having this same problem, set --
clears all of the arguments ($1, $2, $3 and so on). Use shift
to only remove the first one ($1), or shift num
to unset the first num
arguments. It follows that shift $#
will clear all arguments as well.
精彩评论