Unix questions - Question - reading command line parms inside a script.

Author

Question - reading command line parms inside a script.

Ken Andrews

2004-02-27, 11:34 am

I've been going through the FAQs and so far haven't found an answer for this
problem.

I'm trying to read a set of command line parms. The shells I have available
to me are SH, CSH, and KSH. The working environment is CSH. The command
line in question is:

reshape 90-94 -f=" Skip " 95-99 -f=" " 100-102 -f=" >>" 11-11 -f="< " 19-58

What I need to get from this is each of the parms exactly as written, i.e.,

90-94
-f=" Skip "
95-99
-f=" "
100-102
-f=" >>"
11-11
-f="< "
19-58

So far every attempt to check the $1, $2, $3... parms returns correct values
for the numeric ranges, but, of course, the quote characters have been
purged. I need a way for my script to get them exactly as written.

test script - reshape:

#! /bin/csh
echo "$*"
echo " "
echo "$1"
echo "$2"
echo "$3"
echo "$4"
echo " "
foreach Entry ( $* )
echo $Entry
end

Thanks for any suggestions you might have.

Ken Andrews

Barry Margolin

2004-02-27, 11:34 am

In article <tBJ%b.90650$Hy3.38640@edtnps89>,
"Ken Andrews" <gobble@degook.com> wrote:

> So far every attempt to check the $1, $2, $3... parms returns correct values
> for the numeric ranges, but, of course, the quote characters have been
> purged. I need a way for my script to get them exactly as written.

You can't. Quotes are processed by the shell, but they're transparent
to the application. There's no way to tell which of the following the
user entered:

"foo bar"
'foo bar'
foo\ bar
foo" "bar
"f""o""o"' bar'

All the program ever sees is the resulting token.

Why do you think you need this?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Stephane CHAZELAS

2004-02-27, 2:34 pm

2004-02-27, 15:44(+00), Ken Andrews:
[...]
> reshape 90-94 -f=" Skip " 95-99 -f=" " 100-102 -f=" >>" 11-11 -f="< " 19-58
>
> What I need to get from this is each of the parms exactly as written, i.e.,
[...]
> So far every attempt to check the $1, $2, $3... parms returns correct values
> for the numeric ranges, but, of course, the quote characters have been
> purged. I need a way for my script to get them exactly as written.
[...]

You could read the shell history file and do your parsing of the
last shell command line.

But why would you need to do such a thing?

--
Stéphane ["Stephane.Chazelas" at "free.fr"]

Barry Margolin

2004-02-27, 5:34 pm

In article <slrnc3v489.43.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <this.address@is.invalid> wrote:

> 2004-02-27, 15:44(+00), Ken Andrews:
> [...]
> [...]
> [...]
>
> You could read the shell history file and do your parsing of the
> last shell command line.

That depends on the user using a particular shell and having history
enabled. Some shells that have history don't write it to a file
continuously, only when you run a command that saves it.

And of course, what does the OP expect to happen if his program wasn't
invoked by a shell at all. It could have been run by another program
using exec().

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Ken Andrews

2004-03-01, 12:34 pm

"Barry Margolin" <barmar@alum.mit.edu> wrote
> "Ken Andrews" <gobble@degook.com> wrote:
>
values[color=darkred]
>
> You can't. Quotes are processed by the shell, but they're transparent
> to the application. There's no way to tell which of the following the
> user entered:
>
> "foo bar"
> 'foo bar'
> foo\ bar
> foo" "bar
> "f""o""o"' bar'
>
> All the program ever sees is the resulting token.
>
> Why do you think you need this?

We're in the process of switching languages (and associated support
programs). We need to build wrapper scripts to take in a set of parms (as
per the example I gave) and either pass them on to the original support
program or restructure the parms and pass them on to the new support
program.

Something along the lines of:

#! /bin/sh
if [ "$1" = "alpha" ] ; then
shift
reformat $*
else
(do some fiddlywork to convert the parms)
newform $a $b $c $d $e...
fi

The original example I gave was an actual example of command-line parms for
the reformat support program, indicating certain columns of data to extract
and certain string constants to install.

Ken Andrews

Chris F.A. Johnson

2004-03-01, 4:36 pm

On Mon, 01 Mar 2004 at 16:39 GMT, Ken Andrews wrote:
> "Barry Margolin" <barmar@alum.mit.edu> wrote
> values
>
> We're in the process of switching languages (and associated support
> programs). We need to build wrapper scripts to take in a set of parms (as
> per the example I gave) and either pass them on to the original support
> program or restructure the parms and pass them on to the new support
> program.
>
> Something along the lines of:
>
> #! /bin/sh
> if [ "$1" = "alpha" ] ; then
> shift
> reformat $*

To preserve the original arguments use:

reformat "$@"

> else
> (do some fiddlywork to convert the parms)
> newform $a $b $c $d $e...

newform "$a" "$b" "$c" "$d" "$e" ....

> fi
>
> The original example I gave was an actual example of command-line parms for
> the reformat support program, indicating certain columns of data to extract
> and certain string constants to install.

--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
========================================
===========================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

Ken Andrews

2004-03-10, 2:34 pm

Chris F.A. Johnson wrote:
>On Mon, 01 Mar 2004 at 16:39 GMT, Ken Andrews wrote:
>
> To preserve the original arguments use:
>
>reformat "$@"
>
>
>newform "$a" "$b" "$c" "$d" "$e" ....

Thank you for the suggestions.

Script y.y:

#! /bin/sh
echo "* gives --> $*"
echo "@ gives --> $@"
a="$1"
b="$2"
c="$3"
d="$4"
echo " -->" "$a" "$b" "$c" "$d"

Command line:

y.y a b "C" -f="d"

Output:

* gives --> a b C -f=d
@ gives --> a b C -f=d
--> a b C -f=d

Apparently I'm doing something wrong, as I see no difference between any of
the 3 outputs, and all are wrong. This has been tested both running in an
SH and a CSH environment.

Chris F.A. Johnson

2004-03-10, 2:34 pm

On Wed, 10 Mar 2004 at 18:46 GMT, Ken Andrews wrote:
> Chris F.A. Johnson wrote:
>
> Thank you for the suggestions.
>
> Script y.y:
>
> #! /bin/sh
> echo "* gives --> $*"
> echo "@ gives --> $@"
> a="$1"
> b="$2"
> c="$3"
> d="$4"
> echo " -->" "$a" "$b" "$c" "$d"
>
> Command line:
>
> y.y a b "C" -f="d"
>
> Output:
>
> * gives --> a b C -f=d
> @ gives --> a b C -f=d
> --> a b C -f=d
>
> Apparently I'm doing something wrong, as I see no difference between any of
> the 3 outputs, and all are wrong. This has been tested both running in an
> SH and a CSH environment.

Put this in your script:

echo "Using \$*:"
for x in $*
do
echo "$x"
done
echo
echo "Using \"\$@\":"
for x in "$@"
do
echo "$x"
done

And call it with:

y.y a "b c" d "e f" g

--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
========================================
===========================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

Ken Andrews

2004-03-10, 2:34 pm

"Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote
> Put this in your script:
>
> echo "Using \$*:"
> for x in $*
> do
> echo "$x"
> done
> echo
> echo "Using \"\$@\":"
> for x in "$@"
> do
> echo "$x"
> done
>
>
> And call it with:
>
> y.y a "b c" d "e f" g

Output ($*)
a
b
c
d
e
f
g

Output ($@)
a
b c
d
e f
g

Yes, this groups the b/c and the e/f together, as expected. But the quote
marks are still gone. I need the quote marks. They're the entire thing
I've been after. Testing this with my test line of "y.y a b "C" -f="d" from
prior message gets:

Output ($*)
a
b
C
-f=d

Output ($@)
a
b
C
-f=d

The grouping isn't my problem. The missing quotes *inside* the script are.
Inside the script, I need the following parms (or any possible permutation,
sequence is variable):

1) a
2) b
3) "C"
4) -f="d"

The nearest solution I've found is using a line like:

y.y a b \"C\" -f=\"d\"

but it's a suboptimal result as it requires modifying several hundred
scripts. The objective is to use the original lines as written in the
scripts, and build a new script that intercepts the given command and
receives the command-line parms exactly as written.

William Park

2004-03-10, 4:35 pm

Ken Andrews <gobble@degook.com> wrote:
> Yes, this groups the b/c and the e/f together, as expected. But the quote
> marks are still gone. I need the quote marks. They're the entire thing
> I've been after.

> 1) a
> 2) b
> 3) "C"
> 4) -f="d"

Like others, I'm curious why you need quote marks. Your original
'reshape' never sees quote marks anyways. For example,
-f=" aa"
will be given to 'reshape' as
-f=<Space><Space>aa
where <Space> is the actual ASCII 0x20 (space) character.

--
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>
Linux solution for data processing and document management.

Chris F.A. Johnson

2004-03-10, 5:35 pm

On Wed, 10 Mar 2004 at 19:33 GMT, Ken Andrews wrote:
[snip]

> Inside the script, I need the following parms (or any possible
> permutation, sequence is variable):
>
> 1) a
> 2) b
> 3) "C"
> 4) -f="d"
>
> The nearest solution I've found is using a line like:
>
> y.y a b \"C\" -f=\"d\"
>
> but it's a suboptimal result as it requires modifying several hundred
> scripts. The objective is to use the original lines as written in the
> scripts, and build a new script that intercepts the given command and
> receives the command-line parms exactly as written.

Unless you quote the quotes, your program CANNOT see them. If you
have a program that expects to see them without having them
escaped, you need to fix that program, it's broken.

If you have scripts that expect to pass quotes without escaping
them, they are broken and need to be fixed.

--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
========================================
===========================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

Nick Landsberg

2004-03-10, 7:35 pm

Chris F.A. Johnson wrote:
> On Wed, 10 Mar 2004 at 19:33 GMT, Ken Andrews wrote:
> [snip]
>=20
>=20
>=20
>=20
> Unless you quote the quotes, your program CANNOT see them. If you
> have a program that expects to see them without having them
> escaped, you need to fix that program, it's broken.
>=20
> If you have scripts that expect to pass quotes without escaping
> them, they are broken and need to be fixed.
>=20
>=20

Correct on point one. The shell (whatever shell) uses
escapes to determine whether to interpret the argument
as a shell directive or an argument to pass to the
program. It strips off the escapes. An additional problem
is that there is usually more than one form of escape.

The following illustrates that:

MyMachine% cat xxx
echo $@

MyMachine% sh xxx a "<" b
a < b

MyMachine% sh xxx a \< b
a < b

so any scheme to preserve the escapes would have to
emulate the shell's escape processing and then
put the original argument strings back the way
they were.

As to the second point. I believe the original poster
has a need to somehow convert the scripts, thus needs
the original strings as written, rather than the
scripts being broken.

This may be possible in awk (altho I'm not sure) but
it almost seems like a c-program would have to be built
to do the complete job.

Nick L.

--
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

Chris F.A. Johnson

2004-03-10, 7:35 pm

On Thu, 11 Mar 2004 at 00:05 GMT, Nick Landsberg wrote:
> Chris F.A. Johnson wrote:
>
> Correct on point one. The shell (whatever shell) uses
> escapes to determine whether to interpret the argument
> as a shell directive or an argument to pass to the
> program. It strips off the escapes. An additional problem
> is that there is usually more than one form of escape.
>
> The following illustrates that:
>
> MyMachine% cat xxx
> echo $@
>
> MyMachine% sh xxx a "<" b
> a < b
>
> MyMachine% sh xxx a \< b
> a < b
>
> so any scheme to preserve the escapes would have to
> emulate the shell's escape processing and then
> put the original argument strings back the way
> they were.
>
> As to the second point. I believe the original poster
> has a need to somehow convert the scripts, thus needs
> the original strings as written, rather than the
> scripts being broken.

If he's converting scripts (i.e., reading the strings from a
file), then there's no need to do anything; the quotes will not be
stripped (unless he's using eval).

His problem is preserving them on the command line; that requires
escaping.

> This may be possible in awk (altho I'm not sure) but
> it almost seems like a c-program would have to be built
> to do the complete job.

Before we can diagnose the OP's problem any further, we need to
know more about what he's doing, and what the problem is exactly.

--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
========================================
===========================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

Nick Landsberg

2004-03-10, 7:36 pm

Chris F.A. Johnson wrote:

>=20
>=20
> Before we can diagnose the OP's problem any further, we need to
> know more about what he's doing, and what the problem is exactly.
>=20

Absolutely 100% correct.

--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

Ken Andrews

2004-03-11, 10:38 am

"Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote in message
> Before we can diagnose the OP's problem any further, we need to
> know more about what he's doing, and what the problem is exactly.

Given:

1) Program (executable) called REFORMAT.exe, which takes a file and a set
of parms and builds a new file from it. Example:

reformat source.txt target.txt 1-20 -f=" >" 40-43 -f="< 40-43" -p122eqabc
73-87 -f=" " 21

The above will take all records from source where position 122 = a, b, or c
and copy characters 1-20, 40-43, 73-87, and 21 into the target file, while
putting " >", "< 40-43 ", and a space in the positions between the
selections. The output lines would look like:

xxxxxxxxxxxxxxxxxxxx >xxxx< 40-43 xxxxxxxxxxxxxxx x

2) New version of REFORMAT (different company) coming online that uses a
different set of command parms, particulars unimportant.

3) Several hundred scripts have REFORMAT commands built into them, with
lines such as in (1).

4) I'm trying to build a script called REFORMAT which will intercept the
commands. My script version of REFORMAT will invoke a program that will
decide if the given set of commands can be restructured and if so will do so
and build a script to execute the new program. If it cannot, then it must
fire the old version of REFORMAT and pass it the exact command strings as
they were written in the invoking script.

Example:

Script alpha has the command line in (1) built into it.

Script alpha now invokes the script REFORMAT.

Script REFORMAT invokes program CHECK with the above command parms.

CHECK decides whether or not it can convert the parms. If it can, it builds
a temporary script using the converted parms. If it cannot, it builds a
temporary script using the exact passed parms.

Script REFORMAT executes the temporary script.

CHECK must build the temporary script which invokes the original
REFORMAT.exe using the exact parms above. It must receive and pass on

-f=" >"

It cannot receive or pass on

-f= >

If it passes the first, REFORMAT.exe will see one parm. If it passes the
second, REFORMAT.exe will see one parm -f= and a second parm >.

Right now CHECK is seeing -f= >, which it's interpreting as 2 parms. This
gets very bad if it passes "< 40-43 " as 2 parms, as it will put in
replacement data rather than text.

Possibly I'm approaching this problem the wrong way (interception script
with rebuilder program). If there's another way of doing it, I'd be very
happy to know.

Ken Andrews

2004-03-11, 3:35 pm

"Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote

> If the line containing the quotes is being read from a file, the
> shell will not strip the quotes.

Lines are not being read from a file; they're being executed in a script.

> You must be doing something to strip them. What is it?

Doing nothing to strip them; recipient script is not receiving them and thus
cannot pass them on to CHECK.

> Are you forgetting to quote the variables that you pass to CHECK?
> In which case it is not stripping the quotes, but reading the
> argument as multiple words instead of one.

The problem is occurring well before CHECK gets into the picture, at the
interface point between script ALPHA and script REFORMAT; REFORMAT is not
receiving *exactly* what ALPHA is sending.

> Show the code that is giving you problems (both the calling and
> receiving end).

Originally:

Script alpha:

#! /bin/sh
(does various things to prep file)
reformat source.txt target.txt 1-20 -f=" >" 40-43 -f="< 40-43" -p122eqabc
73-87 -f=" " 21

REFORMAT at this point is not a script; it is an executable program. It
reads in the above line and does it's thing, building the target file as per
prior description.

I don't have the source for REFORMAT so do not know how it's getting the
command-line parms or what they look like when they arrive. It's
unimportant, anyway. My job is to simply see that it gets the parms as
written.

Now:

Script alpha (exact same script):

#! /bin/sh
(does various things to prep file)
reformat source.txt target.txt 1-20 -f=" >" 40-43 -f="< 40-43" -p122eqabc
73-87 -f=" " 21

Script reformat (in place of executable reformat):

#! /bin/sh
IAm=`basename $0`
ID=`myptsid`
case "$DBCVer" in
"plc87")
# check builds a script using old or new reformat.
sunNAS check $IAm sun $ID $*
# We fire the script that check built.
/tpm10/sun/wrk/${IAm}script$ID.sh
;;
"dbc8" | "dbc11" | "dbc12")
/tpm10/swc/$DBCVer/dbc check $IAm dbc $ID $*
/tpm10/swc/wrk/${IAm}script$ID.sh
;;
"$DBCVer")
echo "$IAm - No idea what >$DBCVer< means."
exit 0
;;
esac

Script sunNAS:

#! /bin/sh
CliINI="/tpm10/sun/sunbelt/plc/client0036.ini"
Mem="10000000"
.. /tpm10/sun/sunbelt/plc/plb.cfg
plb -Q -i $CliINI -m$Mem $1 "d" $*

CHECK runs and builds a temporary script, either with new form or old form.
Temporary script is then fired in turn to perform new REFORMAT or old
REFORMAT.

The problem is that script REFORMAT is not receiving *exactly* what's on the
command line in script ALPHA. Instead it's receiving parms with the quotes
removed. It thus cannot pass on correctly-quoted parms to CHECK (via script
sunNAS).

alpha sends: source.txt target.txt 1-20 -f=" >" 40-43 -f="<
40-43" -p122eqabc 73-87 -f=" " 21
reformat gets: source.txt target.txt 1-20 -f= > 40-43 -f=< 40-43 -p122eqabc
73-87 -f= 21

The fact that script REFORMAT's received parm 6 is -f=<(space)40-43(space)
is immaterial. It's missing the quotes at character positions 4 and 12.

sunNAS can be removed, obviously, by hardcoding it's contents into script
REFORMAT, but this doesn't correct the problem that script REFORMAT is not
getting exactly what was passed in the first place.

The objective is to not modify script alpha in any way, as there are several
hundred "alphas".

Nick Landsberg

2004-03-11, 5:35 pm

Ken Andrews wrote:
> "Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote in message
>=20
>=20
>=20
> Given:
>=20
> 1) Program (executable) called REFORMAT.exe, which takes a file and =
a set
> of parms and builds a new file from it. Example:
>=20
> reformat source.txt target.txt 1-20 -f=3D" >" 40-43 -f=3D"< 40-43" -p12=
2eqabc
> 73-87 -f=3D" " 21
>=20
> The above will take all records from source where position 122 =3D a, b=
, or c
> and copy characters 1-20, 40-43, 73-87, and 21 into the target file, wh=
ile
> putting " >", "< 40-43 ", and a space in the positions between the
> selections. The output lines would look like:
>=20
> xxxxxxxxxxxxxxxxxxxx >xxxx< 40-43 xxxxxxxxxxxxxxx x

Ah ... OK ... now I think I understand.

Note that the quoting above is there to prevent the shell
from interpreting the special characters < and > and also
to prevent it from taking the space as an argument separator.
The comman line you noted above is functionally equivalent to:

reformat "source.txt" "target.txt" "1-20" "-f=3D >" "40-43" "-f=3D< 40-43=
"=20
"-p122eqabc" "73-87" "-f=3D " "21"

(although no one would type it in this way!)

The following script:

for arg in "$@"
do
echo \"$arg\"
done

has the following output when run against your original command line:

"source.txt"
"target.txt"
"1-20"
"-f=3D >"
"40-43"
"-f=3D< 40-43"
"-p122eqabc"
"73-87"
"-f=3D "
"21"

Is this what you wanted?

HTH

>=20
> 2) New version of REFORMAT (different company) coming online that uses =
a
> different set of command parms, particulars unimportant.
>=20
> 3) Several hundred scripts have REFORMAT commands built into them, with=

> lines such as in (1).
>=20
> 4) I'm trying to build a script called REFORMAT which will intercept th=
e
> commands. My script version of REFORMAT will invoke a program that wil=
l
> decide if the given set of commands can be restructured and if so will =
do so
> and build a script to execute the new program. If it cannot, then it m=
ust
> fire the old version of REFORMAT and pass it the exact command strings =
as
> they were written in the invoking script.
>=20
> Example:
>=20
> Script alpha has the command line in (1) built into it.
>=20
> Script alpha now invokes the script REFORMAT.
>=20
> Script REFORMAT invokes program CHECK with the above command parms.
>=20
> CHECK decides whether or not it can convert the parms. If it can, it b=
uilds
> a temporary script using the converted parms. If it cannot, it builds =
a
> temporary script using the exact passed parms.
>=20
> Script REFORMAT executes the temporary script.
>=20
> CHECK must build the temporary script which invokes the original
> REFORMAT.exe using the exact parms above. It must receive and pass on
>=20
> -f=3D" >"
>=20
> It cannot receive or pass on
>=20
> -f=3D >
>=20
> If it passes the first, REFORMAT.exe will see one parm. If it passes t=
he
> second, REFORMAT.exe will see one parm -f=3D and a second parm >.
>=20
> Right now CHECK is seeing -f=3D >, which it's interpreting as 2 parms. =
This
> gets very bad if it passes "< 40-43 " as 2 parms, as it will put in
> replacement data rather than text.
>=20
>=20
> Possibly I'm approaching this problem the wrong way (interception scrip=
t
> with rebuilder program). If there's another way of doing it, I'd be ve=
ry
> happy to know.
>=20
>=20

--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

Nick Landsberg

2004-03-11, 5:35 pm

Ken Andrews wrote:

> "Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote
>=20
>=20
>=20
>=20
> Lines are not being read from a file; they're being executed in a scrip=
t.
>=20
>=20
>=20
>=20
> Doing nothing to strip them; recipient script is not receiving them and=
thus
> cannot pass them on to CHECK.
>=20
>=20
>=20
>=20
> The problem is occurring well before CHECK gets into the picture, at th=
e
> interface point between script ALPHA and script REFORMAT; REFORMAT is n=
ot
> receiving *exactly* what ALPHA is sending.
>=20
>=20
>=20
>=20
> Originally:
>=20
> Script alpha:
>=20
> #! /bin/sh
> (does various things to prep file)
> reformat source.txt target.txt 1-20 -f=3D" >" 40-43 -f=3D"< 40-43" -p12=
2eqabc
> 73-87 -f=3D" " 21
>=20
> REFORMAT at this point is not a script; it is an executable program. I=
t
> reads in the above line and does it's thing, building the target file a=
s per
> prior description.
>=20
> I don't have the source for REFORMAT so do not know how it's getting th=
e
> command-line parms or what they look like when they arrive. It's
> unimportant, anyway. My job is to simply see that it gets the parms as=

> written.
>=20
>=20
>=20
> Now:
>=20
> Script alpha (exact same script):
>=20
> #! /bin/sh
> (does various things to prep file)
> reformat source.txt target.txt 1-20 -f=3D" >" 40-43 -f=3D"< 40-43" -p12=
2eqabc
> 73-87 -f=3D" " 21
>=20
>=20
> Script reformat (in place of executable reformat):
>=20
> #! /bin/sh
> IAm=3D`basename $0`
> ID=3D`myptsid`
> case "$DBCVer" in
> "plc87")
> # check builds a script using old or new reformat.
> sunNAS check $IAm sun $ID $*

See previous posting. Use "$@" rather than $* and you
should be OK. Note the "'s around "$@"

From the man page:

$@ Expands to the positional parameters, starting from one. When
the expansion occurs within double quotes, each parameter=

expands to a separate word. That is, "$@" is equivalent to "$1"=

"$2" ...

> # We fire the script that check built.
> /tpm10/sun/wrk/${IAm}script$ID.sh
> ;;
> "dbc8" | "dbc11" | "dbc12")
> /tpm10/swc/$DBCVer/dbc check $IAm dbc $ID $*

Ditto.

> /tpm10/swc/wrk/${IAm}script$ID.sh
> ;;
> "$DBCVer")
> echo "$IAm - No idea what >$DBCVer< means."
> exit 0
> ;;
> esac
>=20
>=20
> Script sunNAS:
>=20
> #! /bin/sh
> CliINI=3D"/tpm10/sun/sunbelt/plc/client0036.ini"
> Mem=3D"10000000"
> . /tpm10/sun/sunbelt/plc/plb.cfg
> plb -Q -i $CliINI -m$Mem $1 "d" $*
>=20
>=20
> CHECK runs and builds a temporary script, either with new form or old f=
orm.
> Temporary script is then fired in turn to perform new REFORMAT or old
> REFORMAT.
>=20
> The problem is that script REFORMAT is not receiving *exactly* what's o=
n the
> command line in script ALPHA. Instead it's receiving parms with the qu=
otes
> removed. It thus cannot pass on correctly-quoted parms to CHECK (via s=
cript
> sunNAS).
>=20
> alpha sends: source.txt target.txt 1-20 -f=3D" >" 40-43 -f=3D"<
> 40-43" -p122eqabc 73-87 -f=3D" " 21
> reformat gets: source.txt target.txt 1-20 -f=3D > 40-43 -f=3D< 40-43 -=
p122eqabc
> 73-87 -f=3D 21
>=20
> The fact that script REFORMAT's received parm 6 is -f=3D<(space)40-43(s=
pace)
> is immaterial. It's missing the quotes at character positions 4 and 12=
=2E
>=20
> sunNAS can be removed, obviously, by hardcoding it's contents into scri=
pt
> REFORMAT, but this doesn't correct the problem that script REFORMAT is =
not
> getting exactly what was passed in the first place.
>=20
> The objective is to not modify script alpha in any way, as there are se=
veral
> hundred "alphas".
>=20
>=20

--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

William Park

2004-03-11, 5:35 pm

Ken Andrews <gobble@degook.com> wrote:
> Script alpha (exact same script):
>
> #! /bin/sh
> (does various things to prep file)
> reformat source.txt target.txt 1-20 -f=" >" 40-43 -f="< 40-43" -p122eqabc
> 73-87 -f=" " 21
>
>
> Script reformat (in place of executable reformat):
>
> #! /bin/sh
> IAm=`basename $0`
> ID=`myptsid`
> case "$DBCVer" in
> "plc87")
> # check builds a script using old or new reformat.
> sunNAS check $IAm sun $ID $*
> # We fire the script that check built.
> /tpm10/sun/wrk/${IAm}script$ID.sh
> ;;
> "dbc8" | "dbc11" | "dbc12")
> /tpm10/swc/$DBCVer/dbc check $IAm dbc $ID $*
> /tpm10/swc/wrk/${IAm}script$ID.sh
> ;;
> "$DBCVer")
> echo "$IAm - No idea what >$DBCVer< means."
> exit 0
> ;;
> esac
>
>
> Script sunNAS:
>
> #! /bin/sh
> CliINI="/tpm10/sun/sunbelt/plc/client0036.ini"
> Mem="10000000"
> . /tpm10/sun/sunbelt/plc/plb.cfg
> plb -Q -i $CliINI -m$Mem $1 "d" $*

> alpha sends: source.txt target.txt 1-20 -f=" >" 40-43 -f="<
> 40-43" -p122eqabc 73-87 -f=" " 21
> reformat gets: source.txt target.txt 1-20 -f= > 40-43 -f=< 40-43 -p122eqabc
> 73-87 -f= 21
>
> The fact that script REFORMAT's received parm 6 is -f=<(space)40-43(space)
> is immaterial. It's missing the quotes at character positions 4 and 12.

We keep telling you the answer, and you keep ignoring it. You're
trying to fix problem that doesn't exist. Shell works like this:
- 'alpha' script has quotes in it, ie.
reformat ... -f=" >" ...
- shell removes the quotes, invokes 'reformat', and passes the
arguments intact. That is, quotes are removed, but parameter
contents do not change.
- 'reformat' receives arguments like
... -f= > ...
where '-f= >' is a single parameter.

Whether you're running original way or intercepting via new script,
nothing (I mean, nothing) sees the original quotes. If that's not a
problem for the original way, then it's not a problem for your new
script.

Hint:
- $* is same as $@
- "$*" is not same as "$@"
- Use "$@" instead of $* your scripts.

Ref:
- man bash
- man ksh

--
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>
Linux solution for data processing and document management.

John Savage

2004-03-13, 7:34 pm

"Ken Andrews" <gobble@degook.com> writes:
>Script REFORMAT executes the temporary script.
>
>CHECK must build the temporary script which invokes the original
>REFORMAT.exe using the exact parms above. It must receive and pass on
>
>-f=" >"
>
>It cannot receive or pass on
>
>-f= >
>
>If it passes the first, REFORMAT.exe will see one parm. If it passes the
>second, REFORMAT.exe will see one parm -f= and a second parm >.

So, would it suffice to either (i) have script REFORMAT blindly surround
all -f parameters with quote marks when it writes the temporary script, or
(ii) have script REFORMAT enclose the -f parameter within quotes but only
where it detects that that parameter includes a space?

e.g., in bash make use of ${i##-f}

case $i in -f*" "*) echo -f\"${i##-f}\" ;; esac
--
John Savage (news address invalid; keep news replies in newsgroup)

Nick Landsberg

2004-03-13, 7:34 pm

John Savage wrote:

> "Ken Andrews" <gobble@degook.com> writes:
>
>
>
> So, would it suffice to either (i) have script REFORMAT blindly surround
> all -f parameters with quote marks when it writes the temporary script, or
> (ii) have script REFORMAT enclose the -f parameter within quotes but only
> where it detects that that parameter includes a space?
>
> e.g., in bash make use of ${i##-f}
>
> case $i in -f*" "*) echo -f\"${i##-f}\" ;; esac

(iii) Use of "$@" (with the quotes included
around the $@) will preserve the paramaters
as they were originally.

Therefore the CHECK script need only call

REFORMAT "$@"

without mucking around parsing the parameters.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch