Unix True 64 - Unexpected result from grep

Author

Unexpected result from grep

Dan

2004-01-23, 6:51 pm

Hello,

I can't seem to figure out why this isn't working. I'm running it on
Tru64 V5.1A with patch kit 5. I'm probably missing something obvious.
:-(

Here is my script:
/tmp # cat search
#!/usr/bin/ksh
set -x

typeset -r COMMAND='/sbin/grep'
typeset -r EXPRESSION="${1}"
typeset -r CHECK_FILE="${2}"
typeset RESULT=''

RESULT="$(${COMMAND} -E \'${EXPRESSION}\' ${CHECK_FILE} 2>/dev/null)"

print "RESULT: ${RESULT}"

Here is the test file:
/tmp # cat afile
rsh

Here is what happens when I run the script:
/tmp # search rsh afile
+ typeset -r COMMAND=/sbin/grep
+ typeset -r EXPRESSION=rsh
+ typeset -r CHECK_FILE=afile
+ typeset RESULT=
+ + /sbin/grep -E 'rsh' afile
+ 2> /dev/null
RESULT=
+ print RESULT:
RESULT:

Yet if I run the command at the command line, I get this:
/tmp # /sbin/grep -E 'rsh' afile
rsh

Thanks for your help!
Dan

Chris F.A. Johnson

2004-01-23, 6:51 pm

On Thu, 11 Dec 2003 at 16:13 GMT, Dan wrote:

quote:

> Hello,
>
> I can't seem to figure out why this isn't working. I'm running it on
> Tru64 V5.1A with patch kit 5. I'm probably missing something obvious.
> :-(
>
> Here is my script:
> /tmp # cat search
> #!/usr/bin/ksh
> set -x
>
> typeset -r COMMAND='/sbin/grep'

grep is in sbin???

quote:

> typeset -r EXPRESSION="${1}"
> typeset -r CHECK_FILE="${2}"
> typeset RESULT=''
>
> RESULT="$(${COMMAND} -E '${EXPRESSION}' ${CHECK_FILE} 2>/dev/null)"
>
> print "RESULT: ${RESULT}"
>
> Here is the test file:
> /tmp # cat afile
> rsh

Now try it with afile containing (literally):

'rsh'

quote:

> Here is what happens when I run the script:
> /tmp # search rsh afile
> + typeset -r COMMAND=/sbin/grep
> + typeset -r EXPRESSION=rsh
> + typeset -r CHECK_FILE=afile
> + typeset RESULT=
> + + /sbin/grep -E 'rsh' afile
> + 2> /dev/null
> RESULT=
> + print RESULT:
> RESULT:
>
> Yet if I run the command at the command line, I get this:
> /tmp # /sbin/grep -E 'rsh' afile
> rsh

But your script is:

/sbin/grep -E 'rsh' afile

It searched for rsh enclosed in single quotes.

What you want is:

RESULT=$(${COMMAND} -E "${EXPRESSION}" "${CHECK_FILE}" 2>/dev/null)

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

Jens Schweikhardt

2004-01-23, 6:51 pm

In comp.unix.shell Dan <daniel.j.botz@cummins.com> wrote:
# Hello,
#
# I can't seem to figure out why this isn't working. I'm running it on
# Tru64 V5.1A with patch kit 5. I'm probably missing something obvious.
# :-(
#
# Here is my script:
# /tmp # cat search
# #!/usr/bin/ksh
# set -x
#
# typeset -r COMMAND='/sbin/grep'
# typeset -r EXPRESSION="${1}"
# typeset -r CHECK_FILE="${2}"
# typeset RESULT=''
#
# RESULT="$(${COMMAND} -E '${EXPRESSION}' ${CHECK_FILE} 2>/dev/null)"

For EXPRESSION=foo, this will grep for 'foo', *including* the single
quotes. You need to eval the string to have the single quotes be
interpreted.

RESULT="$(eval ${COMMAND} -E '${EXPRESSION}' ${CHECK_FILE} 2>/dev/null)"

Should do the trick.

Regards,

Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

Stephane CHAZELAS

2004-01-23, 6:51 pm

2003-12-11, 08:13(-08), Dan:
[...]

quote:

> typeset -r COMMAND='/sbin/grep'

a command is either a simple command that can be represented as
a list of arguments, so with an *array* type variable, or a more
complex one, that needs to be a string to be evaluated though
the "eval" builtin. or a very very simple command that only
consists of one 0th arg, in which case you can use a string, but
you should rather name that variable PROG_PATH or even GREP_PATH
or GREP as it appears that you need a grep-like program.

quote:

> typeset -r EXPRESSION="${1}"
> typeset -r CHECK_FILE="${2}"
> typeset RESULT=''
>
> RESULT="$(${COMMAND} -E '${EXPRESSION}' ${CHECK_FILE} 2>/dev/null)"

Once a variable is left unquoted, word splitting and filename
generation is performed, that's not what you want. Moreover,
even if '$EXPRESSION' is a single word that expands to no
filename, that will seach for 'the-expression' (with the single
quotes), not the-expression.

set -A EGREP /sbin/grep -E
RESULT=$(
"${EGREP[@]}" -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
)

or

COMMAND='/sbin/grep -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null'
RESULT=$(eval "$COMMAND")

GREP=/sbin/grep
RESULT=$(
"$GREP" -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
)

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

Joseph Dionne

2004-01-23, 6:51 pm

I have noticed that the Tru64 version of ksh is not a true Korn shell.
Is the source code available. Has anyone else noticed any differences?

Stephane CHAZELAS wrote:

quote:

> 2003-12-11, 08:13(-08), Dan:
> [...]
>
>
>
> a command is either a simple command that can be represented as
> a list of arguments, so with an *array* type variable, or a more
> complex one, that needs to be a string to be evaluated though
> the "eval" builtin. or a very very simple command that only
> consists of one 0th arg, in which case you can use a string, but
> you should rather name that variable PROG_PATH or even GREP_PATH
> or GREP as it appears that you need a grep-like program.
>
>
>
>
> Once a variable is left unquoted, word splitting and filename
> generation is performed, that's not what you want. Moreover,
> even if '$EXPRESSION' is a single word that expands to no
> filename, that will seach for 'the-expression' (with the single
> quotes), not the-expression.
>
>
> set -A EGREP /sbin/grep -E
> RESULT=$(
> "${EGREP[@]}" -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
> )
>
> or
>
> COMMAND='/sbin/grep -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null'
> RESULT=$(eval "$COMMAND")
>
> GREP=/sbin/grep
> RESULT=$(
> "$GREP" -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
> )
>
>

Dan

2004-01-23, 6:51 pm

Joseph Dionne <jdionne@hotmail.com> wrote in message news:<DD2Cb.62750$%h4.33767@twister.tampabay.rr.com>...[QUOTE][color=darkred]
> I have noticed that the Tru64 version of ksh is not a true Korn shell.
> Is the source code available. Has anyone else noticed any differences?
>
> Stephane CHAZELAS wrote:

Thanks everyone for your help! The "eval" certainly does the trick.

Shortly after I posted the question, I figured it out by trial and
error. But with your responses, I now know the why.

Thanks again!!
Dan

Peter da Silva

2004-01-23, 6:51 pm

My biennial lament about excessive use of non-portable shell syntax:

In article <DD2Cb.62750$%h4.33767@twister.tampabay.rr.com>,
Joseph Dionne <no@emailplease.org> wrote:

quote:

> I have noticed that the Tru64 version of ksh is not a true Korn shell.

Doesn't matter if it is or not, {grep '$var' ..} is not going to produce
the intended result. It looks like the result of copying something from
a vaguely similar-looking script that was doing something completely
different, rather than actually working out what you need to do.

The whole script is excessively complex. Even assuming you want to
parameterise the grep command, this would do precisely the same thing:

COMMAND=/sbin/grep

RESULT="`"$COMMAND" -E "$1" "$2" 2>/dev/null`"

And it would work in any bourne-based shell, and unless typeset is
doing something particularly clever with the following line, it
avoids a potential security problem related to the re-evaluation of
the second argument.
[QUOTE][color=darkred]

As would any of following, of course, but they're not as portable:
[QUOTE][color=darkred]

Basically, when I get an installer or other script that starts with
something like

#!/bin/ksh

or

#!/bin/bash

I find it falls into one of these categories:

1. It actually needs some functionality that isn't available
in generic sh. - 1%

2. It is actually portable "sh" code and just needs the "#!"
line fixed. - 9%

3. It uses post-sh functionality, but doesn't actually need
it. - 90%

I wish people would pay attention to code portability in shell scripts.
It's not that hard, and it does pay off.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Dan Mercer

2004-01-23, 6:51 pm

"Peter da Silva" <peter@abbnm.com> wrote in message news:brvm26$ef0$1@jeeves.eng.abbnm.com...
: My biennial lament about excessive use of non-portable shell syntax:
:
: In article <DD2Cb.62750$%h4.33767@twister.tampabay.rr.com>,
: Joseph Dionne <no@emailplease.org> wrote:
: > I have noticed that the Tru64 version of ksh is not a true Korn shell.
:
: Doesn't matter if it is or not, {grep '$var' ..} is not going to produce
: the intended result. It looks like the result of copying something from
: a vaguely similar-looking script that was doing something completely
: different, rather than actually working out what you need to do.
:
: The whole script is excessively complex. Even assuming you want to
: parameterise the grep command, this would do precisely the same thing:
:
: COMMAND=/sbin/grep
:
: RESULT="`"$COMMAND" -E "$1" "$2" 2>/dev/null`"
:
: And it would work in any bourne-based shell, and unless typeset is
: doing something particularly clever with the following line, it
: avoids a potential security problem related to the re-evaluation of
: the second argument.
:
: > >>typeset -r CHECK_FILE="${2}"
:
: As would any of following, of course, but they're not as portable:
:
: > > RESULT=$(
: > > "${EGREP[@]}" -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
: > > )
: > >
: > > or
: > >
: > > COMMAND='/sbin/grep -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null'
: > > RESULT=$(eval "$COMMAND")
: > >
: > > GREP=/sbin/grep
: > > RESULT=$(
: > > "$GREP" -E -- "$EXPRESSION" "$CHECK_FILE" 2> /dev/null
: > > )
:
: Basically, when I get an installer or other script that starts with
: something like
:
: #!/bin/ksh
:
: or
:
: #!/bin/bash
:
: I find it falls into one of these categories:
:
: 1. It actually needs some functionality that isn't available
: in generic sh. - 1%
:
: 2. It is actually portable "sh" code and just needs the "#!"
: line fixed. - 9%
:
: 3. It uses post-sh functionality, but doesn't actually need
: it. - 90%
:
: I wish people would pay attention to code portability in shell scripts.
: It's not that hard, and it does pay off.

Portability using a minimal sh functionality pushes the burden of portability
from the shell to the OS. You then must rely the portability of shell
utilities like awk (which may actualy be old awk) or PERL (which may
not be installed or may be PERL 4) or sed or find (gnu find has some
significant incompatibilities with SysV find). Even the shell known as
"sh" may have some significant incompatibilities - it may be influenced
by the ENV variable (many "posix" shells), it may source ~/.shrc
(NCR SysVR3 sh) - it may or may not accept options to echo.

It is much easier to code for portable ksh - or, failing that, provide
your own shell like Oracle does with osh.

Even the location of sh is problematic - HP-UX puts it in /usr/bin
and symbolically links /usr/bin to /bin - but calls that a "transitional link"
indicating that users should prepare for a time when /bin does not
exist at all.

It's too bad the POSIX shell group did such a poor job - too much
infighting from people with vested interests. Personally, I would
have been perfectly happy had they just said : "We're going to use
zsh - get over it."

Dan Mercer
:
: --
: I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
: of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
: these things will be lost in time, like chalk-paintings in the rain. `-_-'
: Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Peter da Silva

2004-01-23, 6:51 pm

In article <0z_Eb.170955$Eq1.160079@twister.rdc-kc.rr.com>,
Dan Mercer <dmercer@mn.rr.com> wrote:

quote:

> Portability using a minimal sh functionality pushes the burden of portability
> from the shell to the OS.

That's one way of looking at it, I suppose. Really, though, that viewpoint
is confusing correlation and causation.

Just because you're running ksh or bash or zsh doesn't mean you're running
a new awk or that PERL is installed. Writing a script in a less portable
way, from the point of view of the shell, doesn't provide any guarantee
that all the program invocations in the script are going to work. And
writing it in a more portable way doesn't change the version of awk already
installed on the target system into gawk.

All you can say is that a system with a newer shell installed is more likely
to have newer versions of other programs, but if other parts of the code
are non-portable then all you're doing is hiding any deeper problems
and make it harder to isolate them when they do show up. And in the
meantime you're adding to system complexity by forcing people to install
multiple different shells.

As for using the "#!/bin/ksh" to discourage the use of older shells, you
can get the same results by putting that line there without actually using
a single ksh extension.

quote:

> It's too bad the POSIX shell group did such a poor job - too much
> infighting from people with vested interests. Personally, I would
> have been perfectly happy had they just said : "We're going to use
> zsh - get over it."

If they had done that then they would have condemned the POSIX shell to
complete instead of marginal irrelevance, since they would have been
even more widely ignored than they are now.

-rwxr-xr-x 2 bin bin 131072 Apr 12 1999 /usr/bin/sh
text data bss dec hex
114688 16384 4752 135824 21290

-rwxr-xr-x 2 bin bin 270336 Apr 12 1999 /usr/bin/ksh
text data bss dec hex
229376 40960 17968 288304 46630

-rwxr-xr-x 1 root system 917504 Nov 23 1999 /usr/local/bin/zsh
text data bss dec hex
598016 73728 48896 720640 aff00

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Dan Mercer

2004-01-23, 6:51 pm

"Peter da Silva" <peter@abbnm.com> wrote in message news:bs7msf$19vu$1@jeeves.eng.abbnm.com...
: In article <0z_Eb.170955$Eq1.160079@twister.rdc-kc.rr.com>,
: Dan Mercer <dmercer@mn.rr.com> wrote:
: > Portability using a minimal sh functionality pushes the burden of portability
: > from the shell to the OS.
:
: That's one way of looking at it, I suppose. Really, though, that viewpoint
: is confusing correlation and causation.
:
: Just because you're running ksh or bash or zsh doesn't mean you're running
: a new awk or that PERL is installed. Writing a script in a less portable
: way, from the point of view of the shell, doesn't provide any guarantee
: that all the program invocations in the script are going to work. And
: writing it in a more portable way doesn't change the version of awk already
: installed on the target system into gawk.

But it severely lessens the need to invoke awk or sed, etc. Because of
extended globbing, and the new parameter substitution forms, there is
no need to invoke awk for trivial purposes, as so often was done in the
past. The less you need external programs, the less you need to
worry about their portability.
:
: All you can say is that a system with a newer shell installed is more likely
: to have newer versions of other programs,

Not the point at all. I had many bourne shell scripts that relied on awk.
Because of problems with the vendor breaking awk, I switched to gawk.
But that meant I had to support gawk if I continued to use it on a long
term basis (which meant paperwork I won't go into). After the vendor
broke awk the third time, I decided to just pull it out of all the scripts.

I was shocked to find the scripts actually executed faster!

but if other parts of the code
: are non-portable then all you're doing is hiding any deeper problems
: and make it harder to isolate them when they do show up. And in the
: meantime you're adding to system complexity by forcing people to install
: multiple different shells.

Ksh is pretty standard. Only Linux installs wouldn't come standard,
but there, at least, you can install real ksh93.
:
: As for using the "#!/bin/ksh" to discourage the use of older shells, you
: can get the same results by putting that line there without actually using
: a single ksh extension.

Which then leaves you at the mercy of the OS. I find that those who argue
loudest for using the Bourne shell as a standard (ignoring the fact that there
are actually multiple incompatible sh's under that standard) often do so
because they don't know hoe powerful ksh is.
:
: > It's too bad the POSIX shell group did such a poor job - too much
: > infighting from people with vested interests. Personally, I would
: > have been perfectly happy had they just said : "We're going to use
: > zsh - get over it."
:
: If they had done that then they would have condemned the POSIX shell to
: complete instead of marginal irrelevance, since they would have been
: even more widely ignored than they are now.

No, all the major vendors would have adopted zsh.

:
: -rwxr-xr-x 2 bin bin 131072 Apr 12 1999 /usr/bin/sh
: text data bss dec hex
: 114688 16384 4752 135824 21290
:
: -rwxr-xr-x 2 bin bin 270336 Apr 12 1999 /usr/bin/ksh
: text data bss dec hex
: 229376 40960 17968 288304 46630
:
: -rwxr-xr-x 1 root system 917504 Nov 23 1999 /usr/local/bin/zsh
: text data bss dec hex
: 598016 73728 48896 720640 aff00

On my Linux system, zsh is smaller than bash and much smaller than ksh.
I notice you haven't addressed the problem of conflicting "sh" types -
in which not even echo works reliably.

Dan Mercer

:
: --
: I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
: of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
: these things will be lost in time, like chalk-paintings in the rain. `-_-'
: Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Peter da Silva

2004-01-23, 6:51 pm

In article <NFZFb.159619$Vu6.57918@twister.rdc-kc.rr.com>,
Dan Mercer <dmercer@mn.rr.com> wrote:

quote:

> But it severely lessens the need to invoke awk or sed, etc. Because of
> extended globbing, and the new parameter substitution forms, there is
> no need to invoke awk for trivial purposes, as so often was done in the
> past. The less you need external programs, the less you need to
> worry about their portability.

You just need to worry about whether the shell you're using is there or
not. Me, I'd worry about whether I should be using the shell at all.

Look, we didn't start out this side-thread with any multi-hundred-
line script that was longer than many compiled programs, but about
what comes down to about four lines of portable code that didn't use
any gawkisms.

I'm not talking about vast constructs that are pushing the envelope of
shell scripts. I'm talking about install scripts for programs, things
that typically distill down to a few dozen lines at the most, don't
stretch even the most ancient utilities, and seem to be written in
extended shell dialects purely out of habit. I'm talking, well, about
those habits.

If you really need more than sh, if you're going to make me install
another program to get your code to work, then I don't suppose ksh is
as big a deal as Perl.

Except that there's not three highly incompatible versions of PERL in
current use, and PERL is more likely to be there anyway.

I haven't addressed the pseudo-problem of "echo", and I'm not going to.
Nor do I think I'll get into one of those point-by- point cross-griping
exchanges, much as it tempts me.

I do wonder why you think POSIX should have picked zsh, though, since you
seem to prefer ksh and it sure seems like a better shell to me.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

John Doherty

2004-01-23, 6:51 pm

In article <NFZFb.159619$Vu6.57918@twister.rdc-kc.rr.com>, "Dan Mercer"
<dmercer@mn.rr.com> wrote:

quote:

> On my Linux system, zsh is smaller than bash and much smaller than ksh.

But is it statically linked? It seems to me that the system default
shell ought to be.

--

Dan Mercer

2004-01-23, 6:51 pm

"Peter da Silva" <peter@abbnm.com> wrote in message news:bsaafu$kl5$1@jeeves.eng.abbnm.com...
: In article <NFZFb.159619$Vu6.57918@twister.rdc-kc.rr.com>,
: Dan Mercer <dmercer@mn.rr.com> wrote:
: > But it severely lessens the need to invoke awk or sed, etc. Because of
: > extended globbing, and the new parameter substitution forms, there is
: > no need to invoke awk for trivial purposes, as so often was done in the
: > past. The less you need external programs, the less you need to
: > worry about their portability.
:
: You just need to worry about whether the shell you're using is there or
: not. Me, I'd worry about whether I should be using the shell at all.
:
: Look, we didn't start out this side-thread with any multi-hundred-
: line script that was longer than many compiled programs, but about
: what comes down to about four lines of portable code that didn't use
: any gawkisms.
:
: I'm not talking about vast constructs that are pushing the envelope of
: shell scripts. I'm talking about install scripts for programs, things
: that typically distill down to a few dozen lines at the most, don't
: stretch even the most ancient utilities, and seem to be written in
: extended shell dialects purely out of habit. I'm talking, well, about
: those habits.
:
: If you really need more than sh, if you're going to make me install
: another program to get your code to work, then I don't suppose ksh is
: as big a deal as Perl.
:
: Except that there's not three highly incompatible versions of PERL in
: current use, and PERL is more likely to be there anyway.

Well, pieces of it are. PERL is a step above a shell and a step below
writing a program. I've used systems where PERL wouldn't even
load in a timely fashion, others where PERL 4 was supplied.
Perl has also been described as having a "write-only" syntax.
Most people can puzzle out even a complicated shell script and also
have trouble with even a simple PERL script.

As for writing programs, the whole idea of portability means being
able to operate on different architectures. There are all sorts of
activities for which neither PERL nor a program is suitable -
starting and stopping programs at run time, system backups,
canned database queries, etc.

Dan mercer
:
: I haven't addressed the pseudo-problem of "echo", and I'm not going to.
: Nor do I think I'll get into one of those point-by- point cross-griping
: exchanges, much as it tempts me.
:
: I do wonder why you think POSIX should have picked zsh, though, since you
: seem to prefer ksh and it sure seems like a better shell to me.

Because AT&T is stupid and doesn't know how to make money. They create
things like UNIX and ksh then overburden them with restrictive licenses
that make them difficult to adapt universally. So, considering the combination
of functionality closer to ksh than pdksh and a less restrictive license, zsh
would have been preferable to the Babel of shells united only by a weak
standard that we have now.

:
: --
: I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
: of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
: these things will be lost in time, like chalk-paintings in the rain. `-_-'
: Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Stephane CHAZELAS

2004-01-23, 6:51 pm

2003-12-19, 20:11(+00), Peter da Silva:
[...]

quote:

> COMMAND=/sbin/grep
>
> RESULT="`"$COMMAND" -E "$1" "$2" 2>/dev/null`"
>
> And it would work in any bourne-based shell

No, not with the Bourne shell or ksh (except pdksh) to start
with, where you need:

RESULT="`\"$COMMAND\" -E \"$1\" \"$2\" 2>/dev/null`"

(which, according to the autoconf documentation wouldn't work
with some shells, but I don't know which ones they are refering
to << info -f autoconf -n 'Shell Substitutions' >>, "There is
just no portable way to use double-quoted strings inside
double-quoted back-quoted expressions").

or simply:
RESULT=`"$COMMAND" -E "$1" "$2" 2>/dev/null`

The outer quotes are not necessary here.

The `...` command substitution is a portability nightmare, use
$(...) instead if you only need POSIX portability (actually, if
you don't need compatibility to the Bourne shell, as every
other Bourne-like shell (including ash) supports it).

[...about shell portability...]

quote:

> It's not that hard, and it does pay off.

See info -f autoconf -n 'Portable Shell'
That's not that easy.

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

Peter da Silva

2004-01-23, 6:51 pm

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

quote:

> RESULT=`"$COMMAND" -E "$1" "$2" 2>/dev/null`

quote:

> The outer quotes are not necessary here.

Right you are, that's what I get for not testing what I was posting, and
depending on "I know this works, now let's make sure I'm doing it right"
instead of "I know this works, and... I think this is it".

quote:

> The `...` command substitution is a portability nightmare,

Anything that requires more than two levels of quoting is a problem, and a sign
that maybe you need to rethink doing this in the shell.

quote:

> See info -f autoconf -n 'Portable Shell'

Autoconf is one of those programs that's pushing the shell far beyond the
limits of sanity. Using autoconf is a sign that your program is getting to
be a bit of a portability challenge and it's time to consider rewriting that
code with all the #ifdefs and odd macros in system calls.

Like I said elsewhere... I'm not talking about what you need to do to make
multi-hundred-line masterpieces portable, just that 90% of all scripts don't
get anywhere near the bleeding edge and don't need anything more than /bin/sh.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Peter da Silva

2004-01-23, 6:51 pm

In article <c93Gb.186615$M02.98191@twister.rdc-kc.rr.com>,
Dan Mercer <dmercer@mn.rr.com> wrote:

quote:

> As for writing programs, the whole idea of portability means being
> able to operate on different architectures. There are all sorts of
> activities for which neither PERL nor a program is suitable -
> starting and stopping programs at run time, system backups,
> canned database queries, etc.

If you need a complex shell script - one that's complex enough that
portability is an issue - for that kind of thing, then the program you're
driving needs to have its command line interface redesigned.

quote:

> : I do wonder why you think POSIX should have picked zsh, though, since you
> : seem to prefer ksh and it sure seems like a better shell to me.

quote:

> Because AT&T is stupid and doesn't know how to make money. They create
> things like UNIX and ksh then overburden them with restrictive licenses
> that make them difficult to adapt universally.

Oh, you literally meant "pick zsh", the actual program...

The idea of a standards body doing that rather than specifying something
that only zsh happens to fit *right now*... um.

quote:

> zsh would have been preferable to the Babel of shells united only by a weak
> standard that we have now.

Zsh *is* a babel of shells all by itself. If you're going to pick something
like that you might as well just specify that a POSIX system include Perl5
and have done with it. Bad as that is, it's only *one* babel.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`