views:

60

answers:

3

Hi all,

I am operating in a Korn 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.

+1  A: 

Try: after input=$arg, doing an unset arg, or quote if [["$#" -ne "1"]]

maxwellb
Good suggestion, but neither of those things worked for me. However, I just realized that this problem only occurs if I invoke my script using a dot first (>. chdb 2). I had been using an alias, so forgot to mention it. I use 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. Is my problem a side-effect of this, and is there any way around it?
dpatch
A: 

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

jim mcnamara
From the post, "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."
dpatch
A: 

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.

dpatch

related questions