Hi
I would like to pass the value into dsjob command via unix script.
I am reading the values from a.txt file . a.txt file data looks like
year|design
2009|4 way
2010|2 way
2011|3 way
Inside unix script I have assgined the values as follow
//---------------------------------------------------------
reading for the file in loop
year=`echo $READ_LINE | cut -d "|" -f1`
design=`echo $READ_LINE | cut -d "|" -f2`
echo $year , $design
dsjob -run -mode NORMAL -warn 0 -param YEAR=$year -param DESGIN=$desgin -wait -jobstatus <projectname> file_Extract_test
//---------------------------------------------------------------------------
I am getting Invalid arguments: dsjob -run error.
But when I run the dsjob from command line and it works fine without issue but passing parameter is giving error even via command line too.
working one
---------------
dsjob -run -mode NORMAL -warn 0 -param YEAR=2009 -param DESGIN="$desgin4 way" -wait -jobstatus <projectname> file_Extract_test
Not working
------------------
echo $year , $design
dsjob -run -mode NORMAL -warn 0 -param YEAR=$year -param DESGIN=$desgin -wait -jobstatus <projectname> file_Extract_test
Is there is any format to send value like "4 way"?
Thanks
Man
Pass the value into dsjob command
Moderators: chulett, rschirm, roy
It is "DESIGN" I assume... are you doing it correctly and the typo is just in your post?-param DESGIN=$desgin
ps. Always best to explain what "not working" means and to include any errors you get rather than making us guess what they might be.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I doubt this. sincechulett wrote:That would turn the environment variable into a simple string.
Code: Select all
a=2
echo "$a"
please correct me if i am wrong
pandeeswaran
I just happened to have a linux prompt handy...
I just happened to have a linux prompt handy...
Pandeesh, here is a small dose of theory about why you are correct:
What happens on unix (linux, aix, etc) is the shell tokenizes your input and replaces $whatever with the env-value if available.
Quoted expressions are treated as a single token.
Suppose we have a simple shell script "foo.sh" like this:
-----
$ cat foo.sh
echo "Hi from foo, param1=<$1> param2=<$2> param3=<$3>"
$ chmod +x foo.sh
$ ./foo.sh
Hi from foo, param1=<> param2=<> param3=<>
-----
The following sends 3 parameters to foo (each param is 1 char long).
-----
$ ./foo.sh x y z
Hi from foo, param1=<x> param2=<y> param3=<z>
-----
This sends 1 parameter to foo (the param is 5 chars long, and it has embedded spaces).
-----
$ ./foo.sh "x y z"
Hi from foo, param1=<x y z> param2=<> param3=<>
-----
Now for an environment variable:
-----
$ bar=alpha
$ ./foo.sh $bar y z
Hi from foo, param1=<alpha> param2=<y> param3=<z>
-----
Double quotes still expand env vars...
-----
$ ./foo.sh "$bar y z"
Hi from foo, param1=<alpha y z> param2=<> param3=<>
-----
While single quotes do not...
-----
$ ./foo.sh '$bar y z'
Hi from foo, param1=<$bar y z> param2=<> param3=<>
-----
Lastly, consider string concatenation (which is handy if you want to do things like build file names):
-----
$ ./foo.sh $baryz
Hi from foo, param1="" param2="" param3=""
-----
Here param1 was empty because there is no env-var named $baryz.
To get at the actual value of just $bar, you can use curly braces:
-----
$ ./foo.sh ${bar}yz
Hi from foo, param1="alphayz" param2="" param3=""
-----
Google "unix shell quoting" for more: it can get complex, but understanding the above is enough to let you predict how things will behave.
A key point keep in mind is that all the env-var evaluation happens before the target command ever starts to run. All the command (for example, dsjob) will see is a list of 0 to many strings, each string represents an argument and the length of a string can be zero.
For this thread you can use double quotes to control the boundaries of those strings; outside of quotes they are white-space delimited.
This also applies to file wild cards.
Consider this:
$ ./foo.sh *.dat
Before running your program, the shell looks for files matching *.dat. If the shell finds any, *.dat is replaced with that list of file name(s). If the shell doesn't find any, *.dat is passed as-is (e.g. 5 chars) as the first argument string the command will see.
(be advised that windows follows different rules; if you're writing shell scripts or batch files or powershell it is worth studying up on how env-var and wildcard processing works)
Pandeesh, here is a small dose of theory about why you are correct:
What happens on unix (linux, aix, etc) is the shell tokenizes your input and replaces $whatever with the env-value if available.
Quoted expressions are treated as a single token.
Suppose we have a simple shell script "foo.sh" like this:
-----
$ cat foo.sh
echo "Hi from foo, param1=<$1> param2=<$2> param3=<$3>"
$ chmod +x foo.sh
$ ./foo.sh
Hi from foo, param1=<> param2=<> param3=<>
-----
The following sends 3 parameters to foo (each param is 1 char long).
-----
$ ./foo.sh x y z
Hi from foo, param1=<x> param2=<y> param3=<z>
-----
This sends 1 parameter to foo (the param is 5 chars long, and it has embedded spaces).
-----
$ ./foo.sh "x y z"
Hi from foo, param1=<x y z> param2=<> param3=<>
-----
Now for an environment variable:
-----
$ bar=alpha
$ ./foo.sh $bar y z
Hi from foo, param1=<alpha> param2=<y> param3=<z>
-----
Double quotes still expand env vars...
-----
$ ./foo.sh "$bar y z"
Hi from foo, param1=<alpha y z> param2=<> param3=<>
-----
While single quotes do not...
-----
$ ./foo.sh '$bar y z'
Hi from foo, param1=<$bar y z> param2=<> param3=<>
-----
Lastly, consider string concatenation (which is handy if you want to do things like build file names):
-----
$ ./foo.sh $baryz
Hi from foo, param1="" param2="" param3=""
-----
Here param1 was empty because there is no env-var named $baryz.
To get at the actual value of just $bar, you can use curly braces:
-----
$ ./foo.sh ${bar}yz
Hi from foo, param1="alphayz" param2="" param3=""
-----
Google "unix shell quoting" for more: it can get complex, but understanding the above is enough to let you predict how things will behave.
A key point keep in mind is that all the env-var evaluation happens before the target command ever starts to run. All the command (for example, dsjob) will see is a list of 0 to many strings, each string represents an argument and the length of a string can be zero.
For this thread you can use double quotes to control the boundaries of those strings; outside of quotes they are white-space delimited.
This also applies to file wild cards.
Consider this:
$ ./foo.sh *.dat
Before running your program, the shell looks for files matching *.dat. If the shell finds any, *.dat is replaced with that list of file name(s). If the shell doesn't find any, *.dat is passed as-is (e.g. 5 chars) as the first argument string the command will see.
(be advised that windows follows different rules; if you're writing shell scripts or batch files or powershell it is worth studying up on how env-var and wildcard processing works)
pandeesh wrote:I doubt this. sincechulett wrote:That would turn the environment variable into a simple string.returns 2 and not $a.Code: Select all
a=2 echo "$a"
please correct me if i am wrong