开发者

Shell script uses arguments from first run when run a second time

开发者 https://www.devze.com 2023-01-04 22:38 出处:网络
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 select

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消