|
Home > Archive > Unix Shell > October 2005 > Ignoring trap command for a grep function
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Ignoring trap command for a grep function
|
|
| sharma.raghvendra@gmail.com 2005-07-13, 6:02 pm |
| Hi,
We have a trap statement for every non zero returning command/function.
Due to a recent change, we have to grep for some string in a fixed
file. There are functional actions associated for each of the
situations (when its found and not found).
However, when the grep command does not match any lines in the input
file, returns zero as its exit code. Unfortunately that is caught by
the trap.
We really really need to avoid the "grep" being "trapped" by trap
command.
Are their any possibilities ? We want to avoid changing the design
involving the use of trap in and around the trap statement.
All suggestions are appreciated.
regards
raghav..
| |
| Ed Morton 2005-07-13, 6:02 pm |
|
sharma.raghvendra@gmail.com wrote:
> Hi,
>
> We have a trap statement for every non zero returning command/function.
>
>
> Due to a recent change, we have to grep for some string in a fixed
> file. There are functional actions associated for each of the
> situations (when its found and not found).
>
> However, when the grep command does not match any lines in the input
> file, returns zero as its exit code.
No, it returns 1 as it's exit code if it doesn't match. grep returns
zero if it does match.
Unfortunately that is caught by
> the trap.
>
> We really really need to avoid the "grep" being "trapped" by trap
> command.
>
> Are their any possibilities ? We want to avoid changing the design
> involving the use of trap in and around the trap statement.
>
> All suggestions are appreciated.
You could use awk instead of grep so you can control the exit status. e.g.
$ cat t1
stuff
$ grep stuff t1
stuff
$ echo $?
0
$ grep garbage t1
$ echo $?
1
$ awk '/stuff/' t1
stuff
$ echo $?
0
$ awk '/garbage/' t1
$ echo $?
0
$ awk '/stuff/{code=1;print}END{exit code}' t1
stuff
$ echo $?
1
$ awk '/garbage/{code=1;print}END{exit code}' t1
$ echo $?
0
$ awk '/stuff/{code=1;print}END{exit !code}' t1
stuff
$ echo $?
0
$ awk '/garbage/{code=1;print}END{exit !code}' t1
$ echo $?
1
There may be better ways around your problem - you should post a small
sample script that exhibits the behavior with sample input and desired
output.
Ed.
| |
| Ed Morton 2005-07-13, 6:02 pm |
|
Ed Morton wrote:
<snip>
> You could use awk instead of grep so you can control the exit status. e.g.
Or, if you just want the exit status to be zero regardless of whether or
not your pattern matched, you could just use sed:
$ sed -n '/stuff/p' t1
stuff
$ echo $?
0
$ sed -n '/garbage/p' t1
$ echo $?
0
Ed.
| |
| Pascal Bourguignon 2005-07-13, 6:02 pm |
| Ed Morton <morton@lsupcaemnt.com> writes:
> sharma.raghvendra@gmail.com wrote:
>
> No, it returns 1 as it's exit code if it doesn't match. grep returns
> zero if it does match.
>
> Unfortunately that is caught by
>
> You could use awk instead of grep so you can control the exit status. e.g.
>
> $ cat t1
> stuff
> $ grep stuff t1
> stuff
> $ echo $?
> 0
> $ grep garbage t1
> $ echo $?
> 1
action_found () {
echo found
}
action_not_found () {
echo not found
}
$ grep -q -s stuff t1 && action_found || action_not_found
found
$ echo $?
0
$ grep -q -s garbage t1 && action_found || action_not_found
not found
$ echo $?
0
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
| |
| Chris F.A. Johnson 2005-07-13, 6:02 pm |
| On 2005-07-13, sharma.raghvendra@gmail.com wrote:
> Hi,
>
> We have a trap statement for every non zero returning command/function.
Don't.
> Due to a recent change, we have to grep for some string in a fixed
> file. There are functional actions associated for each of the
> situations (when its found and not found).
>
> However, when the grep command does not match any lines in the input
> file, returns zero as its exit code. Unfortunately that is caught by
> the trap.
>
> We really really need to avoid the "grep" being "trapped" by trap
> command.
Don't use trap; check the exit status of the command.
> Are their any possibilities ? We want to avoid changing the design
> involving the use of trap in and around the trap statement.
The design is inappropriate for your script; change it.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
========================================
==========================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
| |
| Henry Townsend 2005-07-13, 6:02 pm |
| Chris F.A. Johnson wrote:
> On 2005-07-13, sharma.raghvendra@gmail.com wrote:
>
>
>
> Don't.
I don't make a habit of disagreeing with CFAJ but must make an exception
in this case. Using a trap on ERR in shell programming turns it into an
exception-throwing language like Java[*]; you can catch the exceptions
(non-zero exit statuses) that you care about as special cases and all
others result in fatal errors. It's as robust a shell programming style
as I know. If using ksh or bash you can add useful data such as
trap 'echo Failed at $0:$LINENO >&2' ERR
>
>
> The design is inappropriate for your script; change it.
I always tell people to add a new shell builtin to their lexicon: "||:"
(without the quotes). Of course it's really two old builtins jammed
together to mean "ignore preceeding exit status". In other words
'>/dev/null' means "throw away stdout", '2>/dev/null' means "throw away
stderr", and '||:' means "throw away return code". So you take your grep
command, and any others for which you don't want to fail on failure, and
stick ||: on the end:
grep foobar /etc/motd ||:
[*] The merits of exceptions vs manual error checking can be and have
been debated in other places; I simply note that the exception style
cannot be said to be "wrong", though some may not be used to or prefer
it. I happen to think you can't write a large reliable shell script
without it.
--
Henry Townsend
| |
| Chris F.A. Johnson 2005-07-13, 8:53 pm |
| On 2005-07-13, Henry Townsend wrote:
> Chris F.A. Johnson wrote:
>
> I don't make a habit of disagreeing with CFAJ but must make an exception
> in this case. Using a trap on ERR in shell programming turns it into an
> exception-throwing language like Java[*]; you can catch the exceptions
> (non-zero exit statuses) that you care about as special cases and all
> others result in fatal errors.
That is something I rarely want to happen, especially not in
large, complicated scripts. For those few cases, I prefer a
function like die:
die()
{
result=$1
shift
[ $# -ge 1 ] && printf "%s\n" "$*" >&2
exit $result
}
...and I call it when a command fails:
some_command | die $? "You messed up"
> It's as robust a shell programming style as I know. If using ksh or
> bash you can add useful data such as
If you aren't using ksh or bash, trapping ERR may not work, since
it is not required by POSIX.
> trap 'echo Failed at $0:$LINENO >&2' ERR
>
> I always tell people to add a new shell builtin to their lexicon: "||:"
> (without the quotes). Of course it's really two old builtins jammed
> together to mean "ignore preceeding exit status". In other words
> '>/dev/null' means "throw away stdout", '2>/dev/null' means "throw away
> stderr", and '||:' means "throw away return code". So you take your grep
> command, and any others for which you don't want to fail on failure, and
> stick ||: on the end:
>
> grep foobar /etc/motd ||:
>
> [*] The merits of exceptions vs manual error checking can be and have
> been debated in other places; I simply note that the exception style
> cannot be said to be "wrong", though some may not be used to or prefer
> it.
Agreed.
> I happen to think you can't write a large reliable shell script
> without it.
I disagree. I do it all the time.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
========================================
==========================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
| |
| Henry Townsend 2005-07-14, 7:48 am |
| Chris F.A. Johnson wrote:
> On 2005-07-13, Henry Townsend wrote:
>
>
> If you aren't using ksh or bash, trapping ERR may not work, since
> it is not required by POSIX.
Of course, but where we came in was that the OP has an existing stable
script which has always done trap on ERR. So presumably he's using a
shell which supports it.
--
Henry Townsend
| |
| Stachu 'Dozzie' K. 2005-07-15, 7:52 am |
| Zawartość nagłówka ["Followup-To:" comp.unix.shell.]
On 13.07.2005, Pascal Bourguignon <pjb@informatimago.com> wrote:
> Ed Morton <morton@lsupcaemnt.com> writes:
>
>
> action_found () {
> echo found
> }
> action_not_found () {
> echo not found
> }
> $ grep -q -s stuff t1 && action_found || action_not_found
> found
> $ echo $?
> 0
> $ grep -q -s garbage t1 && action_found || action_not_found
> not found
> $ echo $?
> 0
You made a logical error. $? contains return status of command *most*
*recently* executed. In this case it is action_found or
action_not_found, both returning status of echo, which is 0. Try this:
$ grep -q -s stuff t1; echo $?
$ grep -q -s garbage t1; echo $?
--
Feel free to correct my English
Stanislaw Klekot
| |
| Pascal Bourguignon 2005-07-15, 6:05 pm |
| "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> writes:
>
> You made a logical error. $? contains return status of command *most*
> *recently* executed. In this case it is action_found or
> action_not_found, both returning status of echo, which is 0. Try this:
>
> $ grep -q -s stuff t1; echo $?
> $ grep -q -s garbage t1; echo $?
No. I wrote exactly what I meant, and I showed exactly what I meant.
That is, that you can write things such as the resulting status will
be 0, therefore no trap will catch us.
Try to prefix your or my commands with:
#!/bin/bash
set -e
trap 'echo Oops!' ERR
in a script and compare the results.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
| |
| Kenny McCormack 2005-10-25, 5:53 pm |
| In article <Zc2dnZZqfpP6A0jfRVn-2A@comcast.com>,
Henry Townsend <henry.townsend@not.here> wrote:
>Chris F.A. Johnson wrote:
>
>I don't make a habit of disagreeing with CFAJ but must make an exception
>in this case.
Don't be afraid to disagree with CFAJ. His comments, though technically
correct, are rarely useful. It's just like in (the joke newsgroup known,
somewhat comically, as) comp.lang.c. The topic is defined so narrowly and
absurdly that the answers, though technically correct, are useless.
Note, especially, his ridiculous assertion that using "trap ERR" is wrong
because it isn't POSIX and thus, not guaranteed to be present in every
(POSIX) shell. But the OP was already using it (in a large script in an
existing environment, neither of which were going to change)! So, that
complaint is obviously bogus.
| |
| Alan Balmer 2005-10-25, 5:53 pm |
| On Tue, 25 Oct 2005 15:41:10 GMT, gazelle@yin.interaccess.com (Kenny
McCormack) wrote:
>In article <Zc2dnZZqfpP6A0jfRVn-2A@comcast.com>,
>Henry Townsend <henry.townsend@not.here> wrote:
>
>Don't be afraid to disagree with CFAJ. His comments, though technically
>correct, are rarely useful. It's just like in (the joke newsgroup known,
>somewhat comically, as) comp.lang.c. The topic is defined so narrowly and
>absurdly that the answers, though technically correct, are useless.
<OT>
Poor Kenny. The people in comp.lang.c aren't amenable to redefining
the purpose of the newsgroup to suit him. One wonders why he continues
to hang around there ;-)
</OT>
>
>Note, especially, his ridiculous assertion that using "trap ERR" is wrong
>because it isn't POSIX and thus, not guaranteed to be present in every
>(POSIX) shell. But the OP was already using it (in a large script in an
>existing environment, neither of which were going to change)! So, that
>complaint is obviously bogus.
--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net
| |
| Kenny McCormack 2005-10-25, 5:53 pm |
| In article <lrtsl1husg76j3987ghi3ak94uo30dptuh@4ax.com>,
Alan Balmer <albalmer@att.net> wrote:
>On Tue, 25 Oct 2005 15:41:10 GMT, gazelle@yin.interaccess.com (Kenny
....
>Poor Kenny. The people in comp.lang.c aren't amenable to redefining
>the purpose of the newsgroup to suit him. One wonders why he continues
>to hang around there ;-)
I stick around, read, and post, for the same reasons I do in any other joke
newsgroup - because it is so much fun. I love watching the endless stream
of well-meaning newbies come in and get clobbered by the locals. It's
like clubbing seals, but I have to admit, it amuses me.
The locals also amuse me - I mean, talk about people who must be
independentaly wealthy (to waste so much time engaging in the activities
noted above)...
| |
| John Kelly 2005-10-26, 6:01 pm |
| On Tue, 25 Oct 2005 15:41:10 GMT, gazelle@yin.interaccess.com (Kenny
McCormack) wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
>Don't be afraid to disagree with CFAJ ... his ridiculous assertion that using
>"trap ERR" is wrong because it isn't POSIX
"Official" standards are nice to read, but bash 3.0+ "portability" is
good enough in many cases, and ever more so as Linux dominance grows.
If portability was my primary concern, I would switch to NetBSD and
write shell code for ash.
| |
| Chris F.A. Johnson 2005-10-27, 2:48 am |
| On 2005-10-26, John Kelly wrote:
> On Tue, 25 Oct 2005 15:41:10 GMT, gazelle@yin.interaccess.com (Kenny
> McCormack) wrote:
>
>
>
>
>
> "Official" standards are nice to read, but bash 3.0+ "portability" is
> good enough in many cases, and ever more so as Linux dominance grows.
Linux and other open-source operating systems are successful
because of adhering to open standards; the unnecessary use of
unportable code (and formats) is a typical Microsoft tactic to
prevent openness and migration. It's unbecoming to an open-source
advocate.
There is no reason to hope that "Linux dominance grows". A healthy
computing climate should welcome diversity, whether commercial
Unices or free. There are many installations that are many years
old and have no need to update. Why remove them unnecessarily from
your consideration?
> If portability was my primary concern, I would switch to NetBSD and
> write shell code for ash.
There's no need to go to NetBSD; you can write portable code, with
little or no loss of efficiency in most cases, in any *nix.
By writing non-portable code you are only limiting yourself.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
========================================
==========================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
| |
| Kenny McCormack 2005-10-28, 4:53 pm |
| In article <kpu533-iln.ln1@rogers.com>,
Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
....
> Linux and other open-source operating systems are successful
> because of adhering to open standards; the unnecessary use of
> unportable code (and formats) is a typical Microsoft tactic to
> prevent openness and migration.
Yeah, and look at how badly its worked out for them.
As a practical matter, it *is* good for us if Linux becomes "dominant".
| |
| Chris F.A. Johnson 2005-10-28, 4:53 pm |
| On 2005-10-27, Kenny McCormack wrote:
> In article <kpu533-iln.ln1@rogers.com>,
> Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> ...
>
> Yeah, and look at how badly its worked out for them.
Perhaps you look up to MS as a business model?
> As a practical matter, it *is* good for us if Linux becomes "dominant".
It will be good for us if open standards become dominant; then it
doesn't matter whether we use Linux or FreeBAS or OpenSolaris or
whatever.
--
Chris F.A. Johnson | Author:
<http://cfaj.freeshell.org> | Shell Scripting Recipes:
Any code in this post is released | A Problem-Solution Approach,
under the GNU General Public Licence | 2005, Apress
| |
| Kenny McCormack 2005-10-28, 4:53 pm |
| In article <on3733-7gh.ln1@rogers.com>,
Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>On 2005-10-27, Kenny McCormack wrote:
>
> Perhaps you look up to MS as a business model?
As a *business* model, yes. It is all but perfect.
(And, as a way to get people into a single fold and stay there)
On ethical, quality, and aesthetic grounds? No.
>
> It will be good for us if open standards become dominant; then it
> doesn't matter whether we use Linux or FreeBAS or OpenSolaris or
> whatever.
I disagree. Assuming that wide-spread acceptance is a/the goal,
(something I do not take as a given, but assume it for the time being),
then it is necessary for one to emerge from the crowd. Joe Normal won't
accept it otherwise.
Incidentally, check out comp.os.linux.announce. There's a new book out
from No-Starch about "Leaving MS behind" - basically, the book argues that
it is possible that Joe Normal may someday actually be able to do so.
I'm hopeful, but sceptical...
| |
| John Kelly 2005-10-28, 4:53 pm |
| On Wed, 26 Oct 2005 23:40:04 -0400, "Chris F.A. Johnson"
<cfajohnson@gmail.com> wrote:
> There are many installations that are many years old and have no need
> to update. Why remove them unnecessarily from your consideration?
Well I don't care much about legacy installations.
> By writing non-portable code you are only limiting yourself.
But I am considering using busybox and its implementation of ash for
one scenario where I would not install any other shell, not even bash.
If this scenario works out, I might have to eat my hat, and then
convert my shell code to run on busybox ash.
:-D
| |
| Chris F.A. Johnson 2005-10-28, 4:53 pm |
| On 2005-10-27, John Kelly wrote:
> On Wed, 26 Oct 2005 23:40:04 -0400, "Chris F.A. Johnson"
><cfajohnson@gmail.com> wrote:
>
>
> Well I don't care much about legacy installations.
You are limiting yourself unnecessarily.
>
> But I am considering using busybox and its implementation of ash for
> one scenario where I would not install any other shell, not even bash.
>
> If this scenario works out, I might have to eat my hat, and then
> convert my shell code to run on busybox ash.
If you had written portably in the first place, conversion would
not be necessary.
If you get into the habit of writing portable scripts, all you
have to do when you port to a POSIX shell is deal with those few
instances where shell-specific code was necessary.
--
Chris F.A. Johnson | Author:
<http://cfaj.freeshell.org> | Shell Scripting Recipes:
Any code in this post is released | A Problem-Solution Approach,
under the GNU General Public Licence | 2005, Apress
| |
| Dan Mercer 2005-10-28, 4:53 pm |
|
"Chris F.A. Johnson" <cfajohnson@gmail.com> wrote in message news:kpu533-iln.ln1@rogers.com...
: On 2005-10-26, John Kelly wrote:
: > On Tue, 25 Oct 2005 15:41:10 GMT, gazelle@yin.interaccess.com (Kenny
: > McCormack) wrote:
: >
: >>>>>We have a trap statement
: >
: >>>> Don't.
: >
: >>>I don't make a habit of disagreeing with CFAJ but must make an exception
: >>>in this case.
: >
: >>Don't be afraid to disagree with CFAJ ... his ridiculous assertion that using
: >>"trap ERR" is wrong because it isn't POSIX
: >
: > "Official" standards are nice to read, but bash 3.0+ "portability" is
: > good enough in many cases, and ever more so as Linux dominance grows.
:
: Linux and other open-source operating systems are successful
: because of adhering to open standards; the unnecessary use of
: unportable code (and formats) is a typical Microsoft tactic to
: prevent openness and migration. It's unbecoming to an open-source
: advocate.
:
: There is no reason to hope that "Linux dominance grows". A healthy
: computing climate should welcome diversity, whether commercial
: Unices or free. There are many installations that are many years
: old and have no need to update. Why remove them unnecessarily from
: your consideration?
:
: > If portability was my primary concern, I would switch to NetBSD and
: > write shell code for ash.
:
: There's no need to go to NetBSD; you can write portable code, with
: little or no loss of efficiency in most cases, in any *nix.
:
: By writing non-portable code you are only limiting yourself.
Yes - your code will never run on a PDP 11 (;-)
Dan Mercer
:
: --
: Chris F.A. Johnson <http://cfaj.freeshell.org>
: ========================================
==========================
: Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
: <http://www.torfree.net/~chris/books/cfaj/ssr.html>
| |
| John Kelly 2005-10-28, 4:53 pm |
| On Wed, 26 Oct 2005 23:40:04 -0400, "Chris F.A. Johnson"
<cfajohnson@gmail.com> wrote:
> the ... use of unportable code ... is ... unbecoming to an open-source
> advocate.
So I should conform my scripts to POSIX standards. OK. Got it.
> A healthy computing climate should welcome diversity
And then I should use the diverse features of bash not available in
other shells!
Conformity ... diversity ... conformity ... diversity ... This feels
like infinite recursion ... PLEEEZ HEEELLLPP MEEEEEE .....
OH WAIT! Maybe it's just a bad dream.
:-D
| |
| Sven Mascheck 2005-10-28, 4:53 pm |
| John Kelly wrote:
"Chris F.A. Johnson" wrote:
>
> And then I should use the diverse features of bash not available in
> other shells!
A misunderstanding (diversity in systems, not interfaces) :
You could chose from {linux, one of the free BSDs, a commercial linux, etc.}
due to
- hardware support,
- special OS features,
- the different development models,
and so on.
But nevertheless standard conforming applications ideally would run
on all systems without modifications: source which only has to be
recompiled and portable scripts (Shell, awk, perl, etc.)
Ontopic: Using a fancy shell _interactively_ is more than fine,
but why aiming at unportable _scripts_? (Except when special
features are needed, certainly).
Why superficially harden the possibility to port applications
to other Unix variants? This is what is already happening
with the various Windows flavours.
| |
| Sven Mascheck 2005-10-28, 4:53 pm |
| John Kelly wrote:
"Chris F.A. Johnson" wrote:
>
> And then I should use the diverse features of bash not available in
> other shells!
A misunderstanding (diversity in systems, not interfaces) :
You could chose from {linux, one of the free BSDs, a commercial unix, etc.}
due to
- hardware support,
- special OS features,
- the different development models,
and so on.
But nevertheless standard conforming applications ideally would run
on all systems without modifications: source which only has to be
recompiled and portable scripts (Shell, awk, perl, etc.)
Ontopic: Using a fancy shell _interactively_ is more than fine,
but why aiming at unportable _scripts_? (Except when special
features are needed, certainly).
Why superficially harden the possibility to port applications
to other Unix variants? This is what is already happening
with the various Windows flavours.
[typo-supersede]
| |
| joe@invalid.address 2005-10-28, 4:53 pm |
| Sven Mascheck <cus.p.mascheck@spamgourmet.com> writes:
> John Kelly wrote:
>
> "Chris F.A. Johnson" wrote:
>
> A misunderstanding (diversity in systems, not interfaces) :
>
> You could chose from {linux, one of the free BSDs, a commercial
> linux, etc.} due to
> - hardware support,
> - special OS features,
> - the different development models,
> and so on.
>
> But nevertheless standard conforming applications ideally would run
> on all systems without modifications: source which only has to be
> recompiled and portable scripts (Shell, awk, perl, etc.)
Well, here's a bit of POSIX code (modified from the OpenGroup man page
actually):
# repeat a command 100 times
x=100
while [ $x -gt 0 ]
do
x=$(($x-1))
done
Guess what happens when you run this "portable" code using /bin/sh on
a Solaris system?
$ cat test.sh
#!/bin/sh
# repeat a command 100 times
x=100
while [ $x -gt 0 ]
do
x=$(($x-1))
done
$ ./test.sh
../test.sh: syntax error at line 6: `x=$' unexpected
It seems to me that portability is a pretty slippery concept. If you
want a script to run on as many platforms as possible using #!/bin/sh
then you have to restrict yourself to only what the dumbest version of
sh you can encounter will understand. That pretty much puts POSIX out
the window.
I doubt that most people need that kind of portability though. Or want
it (the more portable you are the less efficient in most cases).
Joe
--
Gort, klatu barada nikto
| |
| Stephane Chazelas 2005-10-28, 4:53 pm |
| On 28 Oct 2005 10:08:10 -0500, joe@invalid.address wrote:
[...]
> Well, here's a bit of POSIX code (modified from the OpenGroup man page
> actually):
>
> # repeat a command 100 times
> x=100
> while [ $x -gt 0 ]
> do
> x=$(($x-1))
> done
>
> Guess what happens when you run this "portable" code using /bin/sh on
> a Solaris system?
>
> $ cat test.sh
> #!/bin/sh
> # repeat a command 100 times
> x=100
> while [ $x -gt 0 ]
> do
> x=$(($x-1))
> done
[...]
The first line of your script is not POSIX conformant. POSIX
says that if a script starts with "#!", the result is
unspecified.
# repeat a command 100 times
x=100
while [ "$x" -gt 0 ]
do
x=$(($x-1))
done
Will run OK on a Solaris system as long as it's called by a
POSIX conformant command/shell.
--
Stephane
| |
| joe@invalid.address 2005-10-28, 4:53 pm |
| Stephane Chazelas <stephane_chazelas@yahoo.fr> writes:
> On 28 Oct 2005 10:08:10 -0500, joe@invalid.address wrote:
> [...]
> [...]
>
> The first line of your script is not POSIX conformant. POSIX
> says that if a script starts with "#!", the result is
> unspecified.
Ahh, you're right, we have to arrange for our script to be called
differently on different platforms. I didn't think that was part of
what's being called portable though.
> # repeat a command 100 times
> x=100
> while [ "$x" -gt 0 ]
> do
> x=$(($x-1))
> done
>
> Will run OK on a Solaris system as long as it's called by a
> POSIX conformant command/shell.
Well, sure. If you write a PERL script, you have to call it with a
perl interpreter that understands the syntax of the script (right
version, correct modules installed, etc). That's portable enough for
most uses, but it's not what I thought we were talking about.
I thought we were talking about syntax, and being able to write a
script that would run on all (sic) systems. I don't think that's
realistic, or needed in many (most?) cases.
For example, my job requires me to write ksh88 scripts, period. We use
ksh88 as our standard scripting language because it's available on all
the platforms we work with, and we don't have to make special
arrangements to find the right shell to run them (ie, #!/bin/ksh works
on all of them).
I'm not trying to imply that more abstract discussions about
portability are to be avoided or anything like that. Nevertheless, I
question whether most peole really need that kind of thing. I don't
know.
Joe
--
Gort, klatu barada nikto
| |
| John Kelly 2005-10-28, 4:53 pm |
| On Fri, 28 Oct 2005 16:32:33 +0200 (CEST), Sven Mascheck
<cus.p.mascheck@spamgourmet.com> wrote:
>John Kelly wrote:
>"Chris F.A. Johnson" wrote:
[vbcol=seagreen]
[vbcol=seagreen]
>A misunderstanding (diversity in systems, not interfaces) :
So one kind of diversity is good, but another kind is bad. We are
happy to have a confusing proliferation of systems, but we want them
all to conform to the same interface.
Perhaps that makes sense to a madman, but to me it's double-talk.
| |
| Sven Mascheck 2005-10-28, 4:53 pm |
| joe@invalid.address wrote:
> Ahh, you're right, we have to arrange for our script to be called
> differently on different platforms. I didn't think that was part of
> what's being called portable though.
But you missed that there isn't one true "portability". You confuse:
- portable according to current POSIX.2/SingleUnixSpec
A script then should be able to run with every conforming shell.
One should know where to find appropriate shells on ones own system.
Rarely needed: If you even want to avoid this human step, you need
to run getconf in a script as portable as possible (POSIX mentions
how to run getconf here).
- system shell (/bin/sh) portability - that's something completely
different, because non POSIX-shells do exist certainly! 
To help here, that's why this group does exist, too.
BTW, "SVR2 Bourne Shell" portability is quite a good start then.
> For example, my job requires me to write ksh88 scripts, period.
That perfectly makes sense.
But sometimes, however, system shell (/bin/sh) portability is needed.
E.g. for installation scripts, which you don't want to have to modify
before installing software with them. That's what long parts of the
autoconf documentation do focus on.
And system shell portability usually tends to include toolchest
portability, which is even more complicated...
> Nevertheless, I question whether most peole really need that kind of
> thing. I don't know.
If a few of them need it hard, then this group and its archive
should be able to be a good help.
Or what purpose is so much more important in this group,
that the above should be supressed? Or: why do people
question portability issues _here_ if they don't need it
themselves?
| |
| Sven Mascheck 2005-10-28, 4:53 pm |
| John Kelly wrote:
> We are happy to have a confusing proliferation of systems,
^^^^^^^^^
> but we want them all to conform to the same interface.
confusing: If you have to solve a problem, you can get busy with the
options on the "market" (what system can solve my problems best?).
And AFAIK, it always turned out to be an advantage for the consumer
if there's not only one system (linux then would not exist).
Consistent interfaces in turn are for programmers(/admins) - if you
don't see the advantage, i can't explain. But then: why do numerous
commercial vendors, as well as Linux and *BSDs aim at the same
standards here?
> Perhaps that makes sense to a madman, but to me it's double-talk.
No need to get personally, i just wanted to help ;-)
| |
| joe@invalid.address 2005-10-28, 4:53 pm |
| Sven Mascheck <cus.p.mascheck@spamgourmet.com> writes:
> joe@invalid.address wrote:
>
>
> But you missed that there isn't one true "portability". You confuse:
Actually, I'm trying to say precisely that there isn't one true
"portability". I guess I'm not doing a very good job of it.
Joe
--
Gort, klatu barada nikto
| |
| John Kelly 2005-10-28, 4:53 pm |
| On Fri, 28 Oct 2005 19:38:16 +0200 (CEST), Sven Mascheck
<cus.q.mascheck@spamgourmet.com> wrote:
>John Kelly wrote:
[vbcol=seagreen]
>confusing: If you have to solve a problem, you can get busy with the
>options on the "market" (what system can solve my problems best?).
In the 1960s we solved problems in a market where 80 column punched
cards were the best "option." And since that time, mankind has only
digressed to a pitiful state of technologic confusion and madness.
Writing "portable" shell scripts is an exercise in futility, because
the problem of portability is an artificial one, created by greedy and
foolish men in the first place.
| |
| Chris F.A. Johnson 2005-10-28, 4:53 pm |
| On 2005-10-27, Dan Mercer wrote:
>
> "Chris F.A. Johnson" <cfajohnson@gmail.com> wrote in message news:kpu533-iln.ln1@rogers.com...
>:
>: By writing non-portable code you are only limiting yourself.
>
> Yes - your code will never run on a PDP 11 (;-)
It will if someone ports a POSIX shell to the PDP-11.
--
Chris F.A. Johnson | Author:
<http://cfaj.freeshell.org> | Shell Scripting Recipes:
Any code in this post is released | A Problem-Solution Approach,
under the GNU General Public Licence | 2005, Apress
| |
| Chris F.A. Johnson 2005-10-28, 4:53 pm |
| On 2005-10-28, John Kelly wrote:
> On Wed, 26 Oct 2005 23:40:04 -0400, "Chris F.A. Johnson"
><cfajohnson@gmail.com> wrote:
>
>
> So I should conform my scripts to POSIX standards. OK. Got it.
>
>
> And then I should use the diverse features of bash not available in
> other shells!
Only when they make a major difference to the efficiency of the
script.
There are very few instances where this is necessary. For example,
out of more than 100 scripts in my book, there are only 6 that
require bash; 95% of my scripts are portable to any POSIX shell.
--
Chris F.A. Johnson | Author:
<http://cfaj.freeshell.org> | Shell Scripting Recipes:
Any code in this post is released | A Problem-Solution Approach,
under the GNU General Public Licence | 2005, Apress
|
|
|
|
|