Hey Josh,
Yup, all things considered, I will have to stay at the lowest common
denominator since it would be handy to also use on other flavors without
having to switch hasbang's. (When creating more AIX specific code, I'll
always default to ksh93. As you said, much less frustration. :) )
Alternately I could try to run with /usr/bin/ksh or /usr/bin/ksh93 like
this:
/usr/bin/ksh ./script.ksh
/usr/bin/ksh93 ./script.ksh
depending on the OS. But then I'm going to be managing dynamic server
lists. Can't selectively choose hashbang's. (Yet?)
The eval holds promise. Trying to see how it handles special chars ( ',
(, ), [, ], * etc.) that I would need to escape if I pass them in.
Thanks all. Appreciated!
Cheers, Tom
---------------------------------------------------------
On 10/15/2013 5:22 AM, Joshua Taylor wrote:
Not sure if this helps, but you might try passing ksh93 an array:
OPT1=xxx
OPT2=YYY
PARMS=( "-J $OPT1" "-g $OPT2" )
main.ksh ${PARMS[@]}
i didn't get to verify this very closely, but i'm also on AIX 7.1 and
they finally have a reasonably current version of ksh93. You can
forget their 88 implementation - pure frustration.
You may find that if you have to go between 7.1 systems and older
systems, you'll have to use the lowest common denominator (unless you
install AST ksh on the system) because IBM has ksh93 that is
*actually* from '93 in systems lower than 7.1.
take care,
josh
On Oct 14, 2013, at 6:05 PM, "Tom K." <[email protected]
<mailto:[email protected]>> wrote:
Hey David,
Thanks very much.
No luck with the -k option unfortunately. Tried a targeted approach
as you suggested. When that didn't work, tried it in a number of
places instead. ( Sorry, less then scientific, I know ). I hope -k
doesn't toggle and that I didn't make any typos. Not sure if that
plays a part but the two shells are on IBM AIX 7.1 systems. Either
way, same result as earlier:
/usr/bin/ksh (ksh88) Version M-11/16/88f
#
#
#
# ./main.ksh
NARG=|0|
UARG=|me|
GARG=|/folder/file|
JARG=|This is my Option|
NARG=|1|
UARG=|me|
GARG=|/folder/file|
JARG=|This is my Option|
NARG=|2|
UARG=|"me"|
GARG=||
JARG=|"This|
NARG=|3|
UARG=| "me" -J "This is my Option" -g "/folder/file"|
GARG=||
JARG=||
NARG=|3.1|
UARG=| "me" -J "This is my Option" -g "/folder/file"|
GARG=||
JARG=||
NARG=|3.2|
UARG=| "me" -J "This is my Option" -g "/folder/file"|
GARG=||
JARG=||
NARG=|4|
UARG=|"me"|
GARG=||
JARG=|"This|
( x=4 y=16 )
#
#
#
#
# cat script.ksh
#!/usr/bin/ksh93 -k
#!/usr/bin/ksh -k # To manually switch for testing.
while getopts n:u:g:J: option; do
case "${option}" in
n) NARG="$OPTARG"
;;
u) UARG=$OPTARG
;;
g) GARG="$OPTARG"
;;
J) JARG="$OPTARG"
;;
[?]) print >&2 "Good Luck!";
exit 1
;;
esac
done
print "NARG=|$NARG|";
print "UARG=|$UARG|";
print "GARG=|$GARG|";
print "JARG=|$JARG|";
print;
#
#
#
# cat main.ksh
#!/usr/bin/ksh93 -k
OPT1="This is my Option";
OPT2="/folder/file";
PARMS="-u \"me\" -J \"$OPT1\" -g \"$OPT2\"";
./script.ksh -n 0 -u me -J "$OPT1" -g "$OPT2";
eval ./script.ksh -n 1 "$PARMS";
./script.ksh -n 2 ${PARMS};
./script.ksh -n 3 "${PARMS}";
/usr/bin/ksh -k ./script.ksh -n 3.1 "${PARMS}";
/usr/bin/ksh93 -k ./script.ksh -n 3.2 "${PARMS}";
./script.ksh -n 4 $PARMS;
# Supported?
typeset -C comv;
comv.x=4;
comv.y=16;
print $comv;
#
#
#
#
I've looked up the -k on a Linux system I've happen to have had a
shell on and notice it was marked as (Obsolete) in JM 93t+ but not
yet on the IBM systems I'm using. This is good, in a backwards soft
of way, as they'll be some compatability using -k:
-k (Obsolete). All variable assignment arguments
are placed in the
environment for a command, not just those that
precede the command
name.
The Linux system has:
# echo ${.sh.version}
Version JM 93t+ 2010-06-21
#
I suppose could try to ldd the thing to see linking etc.
Cheers, Tom
---------------------------------------------------------
On 10/14/2013 10:36 AM, David Korn wrote:
The problem is that by default, name=value pairs are only recognized
when they preceed the command name. You can use the -k startup
options to allow name=value pairs any where on the command line.
Thus,
ksh -k ./script.ksh -n 3 "${PARMS}"
should also work. The ksh -k could be embedded in script.ksh using
#! on systems that support #!.
On Mon, Oct 14, 2013 at 10:10 AM, Tom K. <[email protected]
<mailto:[email protected]>> wrote:
Great. Thanks.
The eval worked. I'll try the compound option as well.
May need to run this with ksh88, so I might not be able to use
compound vars. (Apologies. Should have mentioned earlier.)
Cheers, Tom
---------------------------------------------------------
On 10/14/2013 6:48 AM, Danny Weldon wrote:
These both worked for me:
eval ./script.ksh -n 3 "${PARMS}";
eval ./script.ksh -n 4 $PARMS;
On 14 October 2013 13:25, Cedric Blancher
<[email protected]
<mailto:[email protected]>> wrote:
On 14 October 2013 04:59, Tom K. <[email protected]
<mailto:[email protected]>> wrote:
Hey Gents,
When trying to pass a variable of paramters to
another script, to reduce
amount of code:
OPT1="This is my Option";
OPT2="/folder/file";
PARMS="-u \"me\" -J \"$OPT1\" -g \"$OPT2\"";
then passing it in like this:
./script.ksh -n 1 "$PARMS";
I get this:
UARG=| "me" -J "This is my Option" -g "/folder/file"|
Or I get this:
UARG=|"me"|
when I try to pass it in this manner:
./script.ksh -n 2 ${PARMS};
Looks like it manages to grab a part of what's in
$PARMS but not the rest of
the string. Was curious about this behaviour and if
KSH had any way to make
this work? Full code is below. Tried a couple of
variations including '
but no luck. This is an older KSH93 version. I
don't have the option of
changing this version unfortunately.
# echo ${.sh.version}
Version M 93t+ 2009-05-01
Does read -C work in ksh93t+?
if it does then you could pass complex data via compound
variables,
i.e. print compound variable via print -C and read the
data into
another shell instance through read -C.
Ced
--
Cedric Blancher <[email protected]
<mailto:[email protected]>>
Institute Pasteur
_______________________________________________
ast-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.research.att.com/mailman/listinfo/ast-users
_______________________________________________
ast-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.research.att.com/mailman/listinfo/ast-users
_______________________________________________
ast-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.research.att.com/mailman/listinfo/ast-users
_______________________________________________
ast-users mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-users
