Functions in bourne shell: HP and the rest of the world
Corne Beerse
I have the next script:
#!/bin/sh
funct ( )
{
echo Funct params $*
}
# First echo
echo 'params:' $*
# Function call
funct f1 f2 f3 f4 f5 f6 f7
# Second echo
echo 'params again:' $*
# end of script.
The script is to be called with parameters, say: `script hi all`
My expectations is that the parameters echo-ed with the First echo
should be the same as echo-ed with the second echo.
On most systems I tested this, this expectation came true:
The systems: SunOS 4.x.x, Solaris 2.x, OSF.
Only on a HP-UX 9.x machine, the second echo echo-ed the parameters
of the function call!!!!!!!!! So all parameters to the script
where lost.
I reported this as a problem to HP The Netherlands (problem handle:
E3053498) and the answer was:
HP> It is no problem, it is no bug, it is designed this way! In the
HP> design of the bourne shell, it is not desinged that the parameters
HP> must be preserved so they must be disgarded.
HP> If you read the manual pages on the bourne shell (man sh-bourne on
HP> HP), nothing about this behavoure is specified. So the implementation
HP> is correct. In the Korn shell manual pages (man ksh) the (right)
HP> behavoure is specified.
My questions are:
- Is this true? Should parameters to functions overwrite the parameters to
to the shell or other functions? Is it designed this way?
- Is there a solution to this problem? I need to use the bourne shell
since that is the only one available on all our platforms.
I like to use functions but I need the parameters.
- Where can I see the design of the bourne shell? I just like to check
this.
- What is the case on HP-UX 10.x? I'm just wondering.
If anyone has answers to my questions or similar experiences, can you
please email it to me? mailto:bee...@ats.nld.alcatel.nl
Thanks in advance
Groetjes
Corne
--
My employer only sponsors the bandwidth, not my opinions
C.J.P. Beerse | Alcatel Telecom Nederland bv
mailto:bee...@ats.nld.alcatel.nl | Postbus 3292
tel:+31-70 3079108 fax:+31-70 3079 191 | NL-2280 GG Rijswijk
Mike Shapiro
Yes.
>- Is there a solution to this problem? I need to use the bourne shell
> since that is the only one available on all our platforms.
> I like to use functions but I need the parameters.
Yes:
Before function call, save parameters:
OLD_ARGV="$*"
After function call, restore parameters:
set -- $OLD_ARGV
>- Where can I see the design of the bourne shell? I just like to check
> this.
If you mean the source code, ftp yourself a copy of the UCB source.
>- What is the case on HP-UX 10.x? I'm just wondering.
Arguments are overwritten by the function call.
-Mike
PS-Don't cross-post this to comp.unix.internals.
--
Mike Shapiro Box 6198 Brown Univ. Providence RI 02912 m...@cs.brown.edu
Andrew Gierth
>Hallo allemaal
>
[script snipped]
>
>The script is to be called with parameters, say: `script hi all`
>My expectations is that the parameters echo-ed with the First echo
>should be the same as echo-ed with the second echo.
>On most systems I tested this, this expectation came true:
>The systems: SunOS 4.x.x, Solaris 2.x, OSF.
>Only on a HP-UX 9.x machine, the second echo echo-ed the parameters
>of the function call!!!!!!!!! So all parameters to the script
>where lost.
Your expected behaviour also occurs on SCO 3.2.4.2, SCO OpenServer 5,
and AIX 3.2.5.0 (that is, the parameters are preserved).
I have also tried it on HP-UX 9.04 with the same results as you report.
But this is what my manpages say on HP-UX 9.04:
Each time a function is executed in a shell script, any arguments
given to the function overwrite the values of the positional
parameters for the entire script. If the values of the positional
parameters must be preserved, they must be explicitly saved before
each function call.
This is in the WARNINGS section of the manpage. This warning does not
appear (obviously) on any of the other systems I've tried.
(Sorry, don't have HP-UX 10 installed yet.)
-- Andrew (and...@microlise.co.uk)
"How is this place run - is it an anarchy?"
"No, I wouldn't say so; it is not that well organised..."
Vladimir Stavitsky
was in Ultrix; i was 100% confident this is a bug - and i reported it to
DEC people 4 years !!! ago - and they admitted it is a bug; they even
assigned a bug fix number or something.
The surprizing thing, though, is that i always considered HP-UX as one
of the best implementatins around; Sun definitely does not have this
problem. I am quite confident nobody would consider this a feature :-)
Vlad
In article <316526...@ats.nld.alcatel.nl>, Corne Beerse <bee...@ats.nld.alcatel.nl> writes:
|> Hallo allemaal
|>
|> I have the next script:
|> #!/bin/sh
|>
|> funct ( )
|> {
|> echo Funct params $*
|> }
|>
|> # First echo
|> echo 'params:' $*
|>
|> # Function call
|> funct f1 f2 f3 f4 f5 f6 f7
|>
|> # Second echo
|> echo 'params again:' $*
|>
|> # end of script.
|>
|> The script is to be called with parameters, say: `script hi all`
|> My expectations is that the parameters echo-ed with the First echo
|> should be the same as echo-ed with the second echo.
|> On most systems I tested this, this expectation came true:
|> The systems: SunOS 4.x.x, Solaris 2.x, OSF.
|> Only on a HP-UX 9.x machine, the second echo echo-ed the parameters
|> of the function call!!!!!!!!! So all parameters to the script
|> where lost.
|>
|> I reported this as a problem to HP The Netherlands (problem handle:
|> E3053498) and the answer was:
|> HP> It is no problem, it is no bug, it is designed this way! In the
|> HP> design of the bourne shell, it is not desinged that the parameters
|> HP> must be preserved so they must be disgarded.
|> HP> If you read the manual pages on the bourne shell (man sh-bourne on
|> HP> HP), nothing about this behavoure is specified. So the implementation
|> HP> is correct. In the Korn shell manual pages (man ksh) the (right)
|> HP> behavoure is specified.
|>
|> My questions are:
|> - Is this true? Should parameters to functions overwrite the parameters to
|> to the shell or other functions? Is it designed this way?
|> - Is there a solution to this problem? I need to use the bourne shell
|> since that is the only one available on all our platforms.
|> I like to use functions but I need the parameters.
|> - Where can I see the design of the bourne shell? I just like to check
|> this.
|> - What is the case on HP-UX 10.x? I'm just wondering.
|>
|> If anyone has answers to my questions or similar experiences, can you
|> please email it to me? mailto:bee...@ats.nld.alcatel.nl
|>
|> Thanks in advance
|> Groetjes
|> Corne
|>
|> --
|> My employer only sponsors the bandwidth, not my opinions
|> C.J.P. Beerse | Alcatel Telecom Nederland bv
|> mailto:bee...@ats.nld.alcatel.nl | Postbus 3292
|> tel:+31-70 3079108 fax:+31-70 3079 191 | NL-2280 GG Rijswijk
--
--------------------------------------------------------------------------
... occurrences like this will be few and far between ...
vl...@dkbfpny.com Vlad Stavitsky vl...@lvalue.com
---------------------------------------------------------------------------
Chet Ramey
Corne Beerse <bee...@ats.nld.alcatel.nl> wrote:
>The script is to be called with parameters, say: `script hi all`
>My expectations is that the parameters echo-ed with the First echo
>should be the same as echo-ed with the second echo.
>On most systems I tested this, this expectation came true:
>The systems: SunOS 4.x.x, Solaris 2.x, OSF.
>Only on a HP-UX 9.x machine, the second echo echo-ed the parameters
>of the function call!!!!!!!!! So all parameters to the script
>where lost.
>
>I reported this as a problem to HP The Netherlands (problem handle:
>E3053498) and the answer was:
>HP> It is no problem, it is no bug, it is designed this way! In the
>HP> design of the bourne shell, it is not desinged that the parameters
>HP> must be preserved so they must be disgarded.
>HP> If you read the manual pages on the bourne shell (man sh-bourne on
>HP> HP), nothing about this behavoure is specified. So the implementation
>HP> is correct. In the Korn shell manual pages (man ksh) the (right)
>HP> behavoure is specified.
>
>My questions are:
>- Is this true? Should parameters to functions overwrite the parameters to
> to the shell or other functions? Is it designed this way?
Functions first appeared in the System V.2 /bin/sh. This version of
sh used a single array to hold positional parameters, and overwrote
the shell's positional parameters on a function call.
The System V.3 sh fixed this, adding `private' arguments for function
calls -- the shell's positional paramters were saved and restored
around function calls.
The HP /bin/sh is derived from the SVR2 sh, and uses only the single
array for positional parameters.
FWIW, Posix.2 specifies the SVR3 behavior. The HPUX /bin/posix/sh
should exhibit the behavior you desire.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, Case Western Reserve University Internet: ch...@po.CWRU.Edu
Neal P. Murphy
>I am very confused by this thread. My first encounter with this behaviour
>was in Ultrix; i was 100% confident this is a bug - and i reported it to
>DEC people 4 years !!! ago - and they admitted it is a bug; they even
>assigned a bug fix number or something.
>The surprizing thing, though, is that i always considered HP-UX as one
>of the best implementatins around; Sun definitely does not have this
>problem. I am quite confident nobody would consider this a feature :-)
Of course it's a feature: since one of the others following-up to this
thread remarked that this 'problem' is noted in the WARNINGS part of the
man page, it is documented and, therefore, a feature. [ :) for the humorously-
challenged.]
HP-UX may have a solid internal operation, but, IMEHO, its user interface
leaves a bit to be desired.
Fest3er
--
The Microsoft thirty bladed swiss army knife with corkscrew and magnifying lens
[is] inappropriate for all of my word processing needs.
- Stephanie Evans
Greg Rold
says...
>
>In article <316526...@ats.nld.alcatel.nl>,
>Corne Beerse <bee...@ats.nld.alcatel.nl> wrote:
>
>>The script is to be called with parameters, say: `script hi all`
>>My expectations is that the parameters echo-ed with the First echo
>>should be the same as echo-ed with the second echo.
>>On most systems I tested this, this expectation came true:
>>The systems: SunOS 4.x.x, Solaris 2.x, OSF.
>>Only on a HP-UX 9.x machine, the second echo echo-ed the parameters
>>of the function call!!!!!!!!! So all parameters to the script
>>where lost.
>>
>sh used a single array to hold positional parameters, and overwrote
>the shell's positional parameters on a function call.
>
>The System V.3 sh fixed this, adding `private' arguments for function
>calls -- the shell's positional paramters were saved and restored
>around function calls.
>
>The HP /bin/sh is derived from the SVR2 sh, and uses only the single
>array for positional parameters.
>
>FWIW, Posix.2 specifies the SVR3 behavior. The HPUX /bin/posix/sh
>should exhibit the behavior you desire.
>
>--
>``The lyf so short, the craft so long to lerne.'' - Chaucer
>
>Chet Ramey, Case Western Reserve University Internet:
ch...@po.CWRU.Edu
On HP-UX 10.01, the posix shell (/bin/sh) exhibits the 'correct'
behavior. That is the results are:
$ ./parms.sh hi all
params: hi all
Funct params f1 f2 f3 f4 f5 f6 f7
params again: hi all
$
The Bourne shell (/usr/old/bin/sh) still exhibits the 'incorrect'
behavior. Results are:
$ ./parms.sh hi all
params: hi all
Funct params f1 f2 f3 f4 f5 f6 f7
params again: f1 f2 f3 f4 f5 f6 f7
On HP-UX 9.04, the posix shell (/bin/posix/sh) also exhibits the
'correct' behavior.
$ ./parms.sh hi all
params: hi all
Funct params f1 f2 f3 f4 f5 f6 f7
params again: hi all
Just a reminder the posix shell is the default shell on HP-UX 10.X.
- Greg
--
Greg Rold
Schuller International
ro...@schuller.com
Ron McOuat
>vl...@dkbfp-dev3.UUCP (Vladimir Stavitsky) writes:
>Of course it's a feature: since one of the others following-up to this
>thread remarked that this 'problem' is noted in the WARNINGS part of the
>man page, it is documented and, therefore, a feature. [ :) for the humorously-
>challenged.]
>HP-UX may have a solid internal operation, but, IMEHO, its user interface
>leaves a bit to be desired.
If this is documented Bourne shell behaviour and you fix it, someone
else will complain after it is fixed.
You don't have to use the Bourne shell. The default shell is the
Posix shell so you have to go out of your way to get the Bourne shell
as your user shell.
HP invented most of the CDE X Windows session and control panel
features and contributed it to the XOpen initiative called COSE,
Spec1170, UNIX95. It was call VUE when it was on HPUX and OEMed by
IBM for AIX.
Guy Harris
>If this is documented Bourne shell behaviour and you fix it, someone
>else will complain after it is fixed.
And how many people complained when *AT&T* fixed it in SVR3? Or when
Sun went from an SVR2-based Bourne shell to an SVR3-based Bourne shell
in SunOS 4.0?
Or is the problem that AT&T didn't document it as Official Behavior, but
HP made the mistake of doing so and committing themselves to maintaining
that behavior?
Ralph Jennings
I hope no one minds my offering a fix for this?
Since this thread has gone on for a while now, I'll just
post a way that you don't have to worry about it anymore.
PARAMS=`for i in "$@"; do IFS="" echo "\"$i\""; done`
function pram1 pram2 param3
eval set "$PARAMS"
There, that should reset the pramaters to there initial
values. Now that you have a fix, please, quit complaining
to this newgroup, and complain to the maintainers of that
Bourne shell. They're the ones who deserve it.
I know it's a pain in the ass, but I don't maintain the
shell on that or any other system, complain to the
maintainers of the shell, and just use my work-around till
they fix it.
Hope this helps, Ralph (know...@oro.net)
--
Life is a sexually transferred disease with 100% mortality.
Dan Mercer
The Bourne shell is obsolescent. There really is no justification in
changing it, when the functionality you desire (and so much more)
is already in the posix shell.
--
Dan Mercer
Reply To: dame...@mmm.com
Opinions expressed herein are my own and may not represent those of my employer.
Doug Siebert
>The Bourne shell is obsolescent. There really is no justification in
>changing it, when the functionality you desire (and so much more)
>is already in the posix shell.
Especially since HP makes the posix shell the default "/bin/sh" (actually
/usr/bin/sh, but since /bin is a link to /usr/bin, /bin/sh still works) in
HP-UX 10.x, which has been shipping for over a year. Granted, there are
still a lot of HP-UX 9.x systems out there, surely many more than HP-UX 10.x
so far, but in a year most will be 10.x, and few people will care that HP's
obsolete bourne shell isn't the same as the "rest of the world's" obsolete
bourne shell.
--
Doug Siebert || "Usenet is essentially Letters to the Editor
University of Iowa || without the editor. Editors don't appreciate
dsie...@icaen.uiowa.edu || this, for some reason." -- Larry Wall
(c) 1996 Doug Siebert. Redistribution via the Microsoft Network is prohibited.
Ralph Jennings
> In article <4kt8j5$6...@hg.oro.net> you write:
> > PARAMS=`for i in "$@"; do IFS="" echo "\"$i\""; done`
> > function pram1 pram2 param3
> > eval set "$PARAMS"
> >
> > There, that should reset the pramaters to there initial
> > values. Now that you have a fix, please, quit complaining
>
> Haven't tried it, but looks to me like this would fail if any arguments
> contain double quotes, or perhaps also if any end in a backslash. I've
> never found a good way to preserve "$@" in a shell variable that works
> if it contains spaces, double-quotes, single-quotes, backslashes,
> newlines, or any other arbitrary characters.
>
> Greg
>
You're right, and I replied a little hastily too, this time the single
quotes didn't work, but I think I have fixed it, this works on my
Linux box (with "s, 's, \s, and \s ending the argument list).
PARAMS=`for i in "$@"; do echo -n "$i" | sed s/\'/\'\\\\\\\\\\\\\\'\'/g | \
sed 's/\(.*\)/'\''\1'\'' '/; done`
function pram1 param2 param3...
eval set "$PARAMS"
Don't ask me why you need all those 14 \s there, all I know is that works
for me. What it's supposed to do is translate ' to '\'' and that seems
to work, whereas s/\'/\'\\\\\'\'/g doesn't, though it seems it should work.
If anybody has a better way, mail me.
David DiGiacomo
>The Bourne shell is obsolescent. There really is no justification in
>changing it, when the functionality you desire (and so much more)
>is already in the posix shell.
The problem with this attitude is that there are zillions of Bourne shell
scripts out in the world, with "#! /bin/sh" interpreter lines, that rely on
>=SVR3 sh behavior. I'm glad HP finally fixed the problem in HP-UX 10.x
Doug Siebert
HP "fixed" the problem by making the POSIX shell /bin/sh (aka /usr/bin/sh)
They didn't waste effort fixing the old crappy bourne shell.
Frank Slootweg
> In article <4ku16q$f...@dawn.mmm.com>, Dan Mercer <dame...@mmm.com> wrote:
> >The Bourne shell is obsolescent. There really is no justification in
> >changing it, when the functionality you desire (and so much more)
> >is already in the posix shell.
>
> The problem with this attitude is that there are zillions of Bourne shell
> scripts out in the world, with "#! /bin/sh" interpreter lines, that rely on
> >=SVR3 sh behavior. I'm glad HP finally fixed the problem in HP-UX 10.x
HP did not *fix* the "problem", because, as other (non-HP) posters
have said/confirmed, nothing was broken. HP just made some changes,
which happen to "solve" the original posters problem on HP-UX 10.x.
With regard to your ""zillions of Bourne shell scripts", the problem
with these scripts is that they are broken! It is not a question of
whose shell is "better", but what behaviour on can *expect* from *any*
standard Bourne shell, i.e. "standard is better than better", "lowest
common denominator" and all that. As other posters have said/confirmed,
one can not *expect* a standard Bourne shell to save/restore the
positional parameters when a function is entered/exited. If a particular
Bourne shell does this, then one is "lucky". As other posters have said,
if one needs the positional parameters to be saved/restored, then one
should either do it oneselves, or use a different shell (Korn, POSIX).
To add insult to injury, Bourne shell scripts which have "#! /bin/sh"
or/and which use functions, and which should work for *any* Bourne
shell, are broken in two other areas, because both "#! interpreter" and
functions are *additions* which came out *after* the original Bourne
shell design! So if one wants to use *any* Bourne shell, one can't use
either of them. If one wants to use a *standard* Bourne shell (i.e.
SVID2/XPG[23] (No SVR? is not a standard, it is an implementation.)),
one can use functions, but can not expect the positional parameters to
be saved/restored.
If someone wants to blame someone, then go right ahead and blame Mr.
Bourne and/or the SVID. Blaming a particular implementation, which
confirms to documented standards, and which even has a "WARNINGS"
section which describes the issue, just demonstrates lack of insight.
On the other hand, it is quite possible to write portable scripts
which test which shell(s)/functionality is/are available and proceed
accordingly. In practice this requires skills/knowledge which not all
script-writers have.
Frank Slootweg, working, but not speaking, for my employer.
Ron Natalie
: To add insult to injury, Bourne shell scripts which have "#! /bin/sh"
: or/and which use functions, and which should work for *any* Bourne
: shell, are broken in two other areas, because both "#! interpreter" and
: functions are *additions* which came out *after* the original Bourne
: shell design! So if one wants to use *any* Bourne shell, one can't use
: either of them. If one wants to use a *standard* Bourne shell (i.e.
: SVID2/XPG[23] (No SVR? is not a standard, it is an implementation.)),
: one can use functions, but can not expect the positional parameters to
: be saved/restored.
More to the point #! has nothing whatsoever to do with the shell.
The only modification made to the Bourne shell was to treat this as
a comment. #! is really handled by the kernel (gak, what a kludge
but it is handy).
The rest of your points are well taken.
-Ron (The first person to put command line editing and job control in
the Bourne Shell)
John Haxby
> On the other hand, it is quite possible to write portable scripts
>which test which shell(s)/functionality is/are available and proceed
>accordingly. In practice this requires skills/knowledge which not all
>script-writers have.
The GNU "configure" scripts (usually generated by autoconf) are just such an
example. Great care is taken to use only those features that are known to work
in all Bourne shells. So functions are out, for a start (which neatly avoids
the problem of knowing whether positional parameters are preserved or not).
Actually, the point of the confugure scripts is to empirically determine which
features are available on a particular platform and then configure the software
to deal with those features. In this way, you could, for example, write
scripts that exploit the Korn shell and water them down for the Bourne shell if
necessary and, yet again, insert goop to handle bad positional parameter
handling (I believe Ultrix 3.1 suffered from this problem as well, for what
it's worth).
As Frank so rightly points out, there's no point in bitching about broken
shells, no amount of complaining is going to repair them, you have to live with
these problems until all instances of the nasti creatures have died from old
age. Either that or only support (in this case) HP/UX 10.* ... there's a price
that has to be paid, upfront, for portability.
--
John Haxby
These are my opinions, not my employer's.
Martin Ibert
: To add insult to injury, Bourne shell scripts which have "#! /bin/sh"
: or/and which use functions, and which should work for *any* Bourne
: shell, are broken in two other areas, because both "#! interpreter" and
: functions are *additions* which came out *after* the original Bourne
: shell design! So if one wants to use *any* Bourne shell, one can't use
: either of them. If one wants to use a *standard* Bourne shell (i.e.
: SVID2/XPG[23] (No SVR? is not a standard, it is an implementation.)),
: one can use functions, but can not expect the positional parameters to
: be saved/restored.
Saying this in other words: A shell script that relies on hash-bang
processing is obviously not intended to run on a plain old vanilla
system anyway, so it might as well rely on other non-POV features. A
system that understands hash-banging, but whose shell clobbers
positional parameters when calling a function, is a bit out of the
ordinary (if not really buggy), to say it mildly.
These HP/UX misfeature has us given grief before. I do admit that it
is in the manual page, so it is definitely not a bug, but it is a
serious shortcoming.
--
---------------------------------------------------------------------------
Dipl.-Inform. Martin Ibert, BB-DATA GmbH, Brunnenstraße 111, D-13355 Berlin
>> e-mail <m...@bb-data.de>, phone +49-30-245-56582, fax +49-30-245-56577 <<
---------------------------------------------------------------------------
>> Disclaimer: My views do not necessarily reflect those of my employer. <<
Gary Seubert
>
> David DiGiacomo (d...@adobe.com) wrote:
> >
> > The problem with this attitude is that there are zillions of Bourne shell
> > scripts out in the world, with "#! /bin/sh" interpreter lines, that rely on
> > >=SVR3 sh behavior. I'm glad HP finally fixed the problem in HP-UX 10.x
>
They (HP) may have "fixed" it in HP-UX 10.x but there's an interesting
side note.
Under 10.x, the binary residing in "/bin/sh" (correction - the
Transitional
Link named "/bin/sh" ;-) actually points to the POSIX shell! Thus,
if
someone has a script that absolutely requires the Bourne Shell, their
10.x script
should start with:
#!/usr/old/bin/sh
--
Gary Seubert - UNIX Class of '73 B.C. ('B'efore 'C'pio)
"The number of UNIX installations is now above 50, and many more are
expected." - UNIX Programmer's Manual - Fifth Edition - June, 1974
David DiGiacomo
>> >The Bourne shell is obsolescent. There really is no justification in
>> >changing it, when the functionality you desire (and so much more)
>> >is already in the posix shell.
>>
>> scripts out in the world, with "#! /bin/sh" interpreter lines, that rely on
>> >=SVR3 sh behavior. I'm glad HP finally fixed the problem in HP-UX 10.x
>
>have said/confirmed, nothing was broken. HP just made some changes,
>which happen to "solve" the original posters problem on HP-UX 10.x.
That doesn't make any sense to me. The SVR2 Bourne shell had the bug that
function parameters overwrote the positional parameters. Anyone writing
shell scripts would realize that this behavior made no sense, and in due
course USG fixed it in the SVR3 Bourne shell. USG fixed it because it was
broken (yes, I realize that's not always the way it works).
Most of the world, such as Sun, IBM, SGI, even OSF, moved forward and
adopted the SVR3 source base or at least the SVR3 behavior, and of course
people writing compatible shells did too since it makes so much more sense.
The majority of people writing Bourne shell scripts do so on systems with
this behavior. Claiming otherwise is just sticking your head in the sand.
HP made a mistake in prematurely standardizing on the SVR2 behavior
because by doing so they created a lot of needless extra work for users
and would-be users (and for me in particular), with no compensating
benefit (I have never personally encountered a shell script that depended
on the SVR2 behavior). Thanks a lot for wasting my time, HP.
> On the other hand, it is quite possible to write portable scripts
>which test which shell(s)/functionality is/are available and proceed
>accordingly. In practice this requires skills/knowledge which not all
>script-writers have.
I do that sometimes. Here is the code that I use, obviously I haven't
upgraded it for HP-UX 10.0:
# if sh does not support functions, use alternate shell
case $_FUNCSUPPORT_ in
y)
unset _FUNCSUPPORT_
;;
*)
_FUNCSUPPORT_=n
case ${ARCH=`arch`} in
sun*) _FUNCSUPPORT_=y ;;
hp*) _FUNCSUPPORT_=n ;; # in sh, function call wipes out $@
*) sh -c 'fred() { : ; }' >/dev/null 2>&1 && _FUNCSUPPORT_=y ;;
esac
case $_FUNCSUPPORT_ in
n)
case $ARCH in
decmips) sh=sh5 ;;
hppa) sh=/bin/posix/sh ;;
*) sh=ksh ;;
esac
_FUNCSUPPORT_=y export _FUNCSUPPORT_
exec $sh $0 ${1+"$@"}
;;
esac
;;
esac
Of course that's so ugly and slow I usually just tell people not to try to
run my scripts on HP-UX 9.x.
Frank Slootweg
> Frank Slootweg (fra...@neth.hp.com) wrote:
>
> : To add insult to injury, Bourne shell scripts which have "#! /bin/sh"
> : or/and which use functions, and which should work for *any* Bourne
> : shell, are broken in two other areas, because both "#! interpreter" and
> : functions are *additions* which came out *after* the original Bourne
> : shell design! So if one wants to use *any* Bourne shell, one can't use
> : either of them. If one wants to use a *standard* Bourne shell (i.e.
> : SVID2/XPG[23] (No SVR? is not a standard, it is an implementation.)),
> : one can use functions, but can not expect the positional parameters to
> : be saved/restored.
>
> The only modification made to the Bourne shell was to treat this as
> a comment. #! is really handled by the kernel (gak, what a kludge
> but it is handy).
Yes, that is what I meant. I.e. "#! interpreter" came out *after* the
original Bourne shell, but is not (neccessarily) implemented *in* the
shell. From an e-mail respondent, I understand that the behavior of any
script which begins with #!interpreter-path is implemenation-dependent
according to POSIX.2 (and XPG/4, of course). On HP-UX it is indeed
handled by "the kernel" and documented in exec(2).
> The rest of your points are well taken.
Thanks.
Frank Slootweg
HP did *not* "prematurely" standardize on the *SVR*2 behaviour. HP
*did*, but of course not "prematurely", conform to the *SVID*2. As I
said before, *SVID*? is a standard, *SVR*? is *not* a standard, it is an
implementation. That people's scripts fail because they can't tell the
difference between a standard and an implementation is hardly HP's
fault, is it?
It is all too easy to complain about these things, but, like other
posters have said, it is probably better to spend ones time on writing
truly portable scripts, then waste ones time trying to put the blame on
a particular vendors standard-conformant implementation.
As other posters have said, there are plenty alternatives. HP has had
Korn and POSIX shells longer than most other main UNIX vendors, and the
"problem" is not present in HP-UX 10.X and beyond.
Frank Slootweg
[deleted]
> They (HP) may have "fixed" it in HP-UX 10.x but there's an interesting
> side note.
> Under 10.x, the binary residing in "/bin/sh" (correction - the
> Transitional Link named "/bin/sh" ;-) actually points to the POSIX shell!
As far as I know, this particular link is *not* a Transition Link. A
Transition Link is a symbolic link with its sticky bit set ("T" in ll(1)
output). This particular link is a hard link between /bin/sh and
/usr/bin/sh. The content is, like sh(1) says, indeed the POSIX shell. I
do not know if this link is documented somewhere.
Doug Siebert
It isn't a hard link, and there is no /bin in HP-UX 10.x. /bin is a link
(without the sticky bit set, so not an official "transition link" that will
be removed in the future?) to /usr/bin.
I didn't know that HP was using the convention of turning on the sticky bit
on all links that are to be regarded as "transition links". That's kind of
nice though, makes it easier to know what links will go away when you remove
the transition links, without actually removing them and comparing the system
state before & after.
Frank Slootweg
> Gary Seubert (gary.s...@citicorp.com) wrote:
> [deleted]
> > They (HP) may have "fixed" it in HP-UX 10.x but there's an interesting
> > side note.
> > Under 10.x, the binary residing in "/bin/sh" (correction - the
> > Transitional Link named "/bin/sh" ;-) actually points to the POSIX shell!
>
> As far as I know, this particular link is *not* a Transition Link. A
> Transition Link is a symbolic link with its sticky bit set ("T" in ll(1)
> output). This particular link is a hard link between /bin/sh and
> /usr/bin/sh. The content is, like sh(1) says, indeed the POSIX shell. I
> do not know if this link is documented somewhere.
OOPS! An e-mail respondent (Thanks CT!) (indirectly) pointed out that
both Gary and I were "right"/"wrong".
The actual situation (I hope I'm not messing this up again! :-)) is
that /bin is a *symbolic* link to /usr/bin (but *not* a *Transition*
Link, i.e. no sticky/"T" bit).
Before my previous posting I did a
# ll -i /bin/sh /usr/bin/sh
604 -r-xr-xr-x 2 bin bin 405504 Jun 12 1995 /bin/sh
604 -r-xr-xr-x 2 bin bin 405504 Jun 12 1995 /usr/bin/sh
#
which I thought "proved" that /bin/sh is hard linked to /usr/bin/sh
(link count 2 and same inode number), however the /bin -> /usr/bin
symbolic link fooled me.
Also the e-mail respondent fell in a similar trap because he thought
that /usr/bin/sh is hard linked to /usr/bin/posix/sh, which is not true,
because /usr/bin/posix is a Transition Link back to /usr/bin.
So what is hard linked to what? There must be a hard link, because the
link count of /bin/sh, /usr/bin/sh and /usr/bin/posix is 2. Answer:
/usr/bin/sh is hard linked to /usr/bin/rsh:
# ll -i /usr/bin/rsh /usr/bin/sh
604 -r-xr-xr-x 2 bin bin 405504 Jun 12 1995 /usr/bin/rsh
604 -r-xr-xr-x 2 bin bin 405504 Jun 12 1995 /usr/bin/sh
#
In hindsight, I should have known/realized that.
Nice, isn't it, all this linking stuff? Now HP-UX is compatible with
"everything", including the SVR4 filesystem layout, but the needed
linking stuff is quite "messy"/hard_to_follow, so HP can just wait for
complaints about *that*! :-)
Gary Seubert
> ..stuff ..
> It isn't a hard link, and there is no /bin in HP-UX 10.x. /bin is a link
> (without the sticky bit set, so not an official "transition link" that will
> be removed in the future?) to /usr/bin.
>
> I didn't know that HP was using the convention of turning on the sticky bit
> on all links that are to be regarded as "transition links".
Actually, on my 10.01 systems, /bin IS indeed a Transitional Link to /usr/bin. This
can be confirmed by an "ls -ld" on /bin which shows mode:
lr-xr-xr-t 1 root sys ... /bin -> /usr/bin
and also by running '/opt/upgrade/bin/tllist' which lists "/bin -> /usr/bin" as the
very last entry!
Also, I believe although the sticky bit is, indeed set on all of these "Transitional
Link" thingies, a DataBase is actually used to store what is and/or is not a TL. SO
don't be misled into thinking that you can just create a "new" Transitional Link by
setting the sticky bit on a link - I think the DataBase rules!
Final (honest) note: The "TL" confusion has clouded-over the original observation I
made - namely, whether you call it "/bin/sh" or "/usr/bin/sh", the assumption had
always been that you were talking about the Bourne shell. My point is that "/bin/sh"
and/or "/usr/bin/sh" are NOW the POSIX shell! Thus, if you REALLY need to run the
Bourne shell, you have to call the ever-popular pathname of: "/usr/old/bin/sh".
Steve Bourne must be THRILLED with that! I suppose if anyone ever ported the original
(John Mashey) shell to HP-UX, it would be: "/usr/oldest/bin/sh" ? ;-)
Guy Harris
>The Bourne shell is obsolescent. There really is no justification in
>changing it,
AT&T already changed it, before the POSIX 1003.2 shell even existed. It
appears that HP just dragged their feet about upgrading to an
SVR3-or-later-based shell, unlike AT&T, who didn't hesitate to change
the shell's behavior, and unlike Sun, who just upgraded the shell to an
SVR3.1-based one in SunOS 4.0 (as the person who did said upgrade at
Sun, I'd probably have said "tough luck" to anybody who complained that
the behavior changed; as far as I know, nobody *did* complain, or at
least didn't do so loudly enough).
>when the functionality you desire (and so much more)
>is already in the posix shell.
If "you" is addressed to me, I already *have* the functionality in
question (although I don't use shell functions enough that it matters) -
I don't use HP-UX, I just use systems with shells whose Bourne shell
provides the functionality in question, as they use a more modern Bourne
shell than SVR2's.
There's a POSIX 1003.2 shell spec *now*, and UNIX systems are starting
to offer 1003.2-compliant shells, so *now* you can say "just use the
POSIX shell", but, as indicated, the behavior in question was changed by
AT&T before 1003.2 ever came out....
Guy Harris
> HP did not *fix* the "problem", because, as other (non-HP) posters
>have said/confirmed, nothing was broken.
Indeed?
Is it, in fact, the case that the behavior of the SVR2 Bourne shell in
this case was documented - not by HP, but by *AT&T*, you know, the folks
who originally *developed* that shell? If not, then if HP decided that
this behavior was The Way The Shell Was Supposed To Work, and not just a
consequence of the implementation, and documented it, they made an
error.
Frank Slootweg
I don't know, but it is a non-issue, because, as I have said several
times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
compliant. I don't care what Mr. Bourne intended, I don't care what AT&T
did or did not document in SVR?, I only care what the *standards* say,
and whether or not a particular shell, in this case HP's Bourne shell,
complies with them (which it does).
F. L. Charles Seeger III
|
| I don't know, but it is a non-issue, because, as I have said several
| times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
| compliant. I don't care what Mr. Bourne intended, I don't care what AT&T
| did or did not document in SVR?, I only care what the *standards* say,
| and whether or not a particular shell, in this case HP's Bourne shell,
| complies with them (which it does).
And, as a customer, my dollars will go to vendors that provide useful
software rather than those that hide their deficiencies behind one or
more of the many available standards from which there are to choose.
MOST Sincerely,
Chuck
--
Charles Seeger <see...@cis.ufl.edu>
F. L. Charles Seeger III
|
| And, as a customer, my dollars will go to vendors that provide useful
| software rather than those that hide their deficiencies behind one or
| more of the many available standards from which there are to choose.
|
| MOST Sincerely,
| Chuck
And, I should have added, I no longer work for the Univeristy of Florida,
not its Computer Science Department, nor do my opinions in any way reflect
on them or any one else... etc., etc.
--
Charles Seeger <see...@cis.ufl.edu>
Dan Mercer
: Guy Harris (g...@netapp.com) wrote:
: > Frank Slootweg <fra...@neth.hp.com> wrote:
: > > HP did not *fix* the "problem", because, as other (non-HP) posters
: > >have said/confirmed, nothing was broken.
: >
: > Indeed?
: >
: > Is it, in fact, the case that the behavior of the SVR2 Bourne shell in
: > this case was documented - not by HP, but by *AT&T*, you know, the folks
: > who originally *developed* that shell? If not, then if HP decided that
: > this behavior was The Way The Shell Was Supposed To Work, and not just a
: > consequence of the implementation, and documented it, they made an
: > error.
: I don't know, but it is a non-issue, because, as I have said several
: times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
: compliant. I don't care what Mr. Bourne intended, I don't care what AT&T
: did or did not document in SVR?, I only care what the *standards* say,
: and whether or not a particular shell, in this case HP's Bourne shell,
: complies with them (which it does).
Harris apparently doesn't understand the difference between an
enhancement and a bug fix. He just wants to pout, so let him.
Eric Hamilton
The following is my personal opinion, not an official HP position.
I do work for HP in the division that produces HP-UX.
I have never been responsible for the HP-UX shells, but I do have some
insight into how we approach HP-UX development, enhancements, and bug
fixes.
First I'd like to acknowledge the inconvenience that several of you have
experienced in using Bourne shell functions and positional parameters on
HP-UX. As noted, the behavior of using a single global argument list for
functions comes from the AT&T 5.2 code. This implementation artifact is not
particularly useful or desirable in itself-- AT&T changed it in 5.3, many
other vendors have used per-function parameter lists, & POSIX standardized on
per-function parameter lists. I'd also like to acknowledge that defacto
standards do count and that conforming to a formal standard but not solving
important customer problems is a bad thing. All other things being equal, it
would be good if all /bin/sh implementations behaved identically and
per-function parameter lists look better to me too. But I don't think all
other things are always equal.
I'd also like to ask everyone to consider the possibility that writing
strictly portable code is challenging, that there's been a long history of
confusing standards and implementations, and that even well-mannered support
engineers can get frustrated when customers want implementation-detail
portability across platforms without using available standards-based means of
achieving such portability. I'd also like to ask folks to consider the
possibility that the approach that annoys them in this case has also delivered
benefits that they care about in other cases or perhaps even in this one.
The final reason that I unlurked here was that thanks to Guy Harris we also
have an opportunity to examine aspects of two different development
philosophies and see both the strengths and weaknesses of HP-UX's chosen path.
I'm also interested in feedback regarding the choices we've made.
Guy Harris (g...@netapp.com) wrote:
: AT&T already changed it, before the POSIX 1003.2 shell even existed. It
: appears that HP just dragged their feet about upgrading to an
: SVR3-or-later-based shell, unlike AT&T, who didn't hesitate to change
: the shell's behavior, and unlike Sun, who just upgraded the shell to an
: SVR3.1-based one in SunOS 4.0
I don't know for sure, but I don't think foot dragging is really why HP didn't
switch to a 5.3 or later shell. I'd guess it was more likely a combination
of some of the following:
* concern about losing bug fixes done in HP-UX
* concern about the cost of reimplementing HP-UX added value pieces
such as NLS (was an issue early on).
* availability of a standard POSIX shell, either in the near future
prior to its actual shipping or already once it did ship.
* licensing issues (remember AT&T + Sun vs. OSF)
* compatibility concerns (more below)
If you were a customer who benefited from HP-UX added value or bug fixes, then
you might have been glad that we didn't switch to a 5.3 shell.
Guy continued:
: (as the person who did said upgrade at
: Sun, I'd probably have said "tough luck" to anybody who complained that
: the behavior changed; as far as I know, nobody *did* complain, or at
: least didn't do so loudly enough).
Here are the comments in our internal defect database from the unnamed HP
engineer who closed out the problem report in 1991 and decided not to change
the Bourne shell:
> .problem
>
> The Bourne shell does not preserve positional parameters across function
> calls whereas the Korn shell does.
>
> .labnotes
>
> This problem could be considered an enhancement. However, our lab is
> focusing on standardizing HP-UX commands and this type of request
> does not fall under standardization -- especially since the Korn shell
> currently supports, and the POSIX shell will support the functionality
> that this customer wants.
>
> Moreover, I feel that preserving arguments could break some scripts
> that depend on a function's side-effect of changing the pos'nl parms.
Whereas Guy was prepared to tell a customer "tough luck" for depending upon
such an implementation detail, the HP engineer chose not not to risk
compatibility at the cost of preserving what most might consider a bug. While
our record is far from perfect, I do think that HP has kept a strong focus on
maintaining customer compatibility across releases. One case where we do
break compatibility is when standards require it and even then we have often
chosen to preserve the old environment as well as offer the new standard one.
Had there not been ksh and POSIX shells in the picture and had the bug report
come in saying that SVR3 or SunOS had upgraded /bin/sh not to overwrite
positional parameters, I expect but cannot prove that we would have looked at
other systems, risked the incompatibility and fixed it.
We may have erred in this particular case-- perhaps we could have changed the
shell and nobody would have noticed, but it is awfully hard to know that in
advance. In order to be able to innovate better and offer new capabilities to
customers we may need to change the balance some, but that's where we're
coming from.
I'd be interested in hearing reasoned views on when folks think that we ought
to change/enhance things and when compatibility needs to prevail. And I
wonder whether that depends on whether you're a new customer coming to HP-UX
or an existing customer with an HP-UX installed base.
Finally, given a viable standards based workaround (/bin/posix/sh in 9.x,
/usr/bin/sh in 10.x, see also getconf(1)) my estimate of the likelihood of a
patch to 9.x is approximately nil.
Dan Mercer
: Frank Slootweg <fra...@neth.hp.com> wrote:
: |
: | times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
: | compliant. I don't care what Mr. Bourne intended, I don't care what AT&T
: | did or did not document in SVR?, I only care what the *standards* say,
: | and whether or not a particular shell, in this case HP's Bourne shell,
: | complies with them (which it does).
: And, as a customer, my dollars will go to vendors that provide useful
: software rather than those that hide their deficiencies behind one or
: more of the many available standards from which there are to choose.
: MOST Sincerely,
: Chuck
: --
: Charles Seeger <see...@cis.ufl.edu>
See, I told you all he wanted to do was pout.
Guy Harris
> I don't know, but it is a non-issue,
It may be a non-issue to *you*, but you're not the only person
participating in this thread, so it is *not* necessarily a non-issue in
this thread.
>because, as I have said several
>times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
>compliant.
>I don't care what Mr. Bourne intended, I don't care what AT&T
>did or did not document in SVR?, I only care what the *standards* say,
*You* may think that "well, the standard doesn't say we *can't* do this"
is an adequate response, but, as has been demonstrated in this thread,
at least some users of HP's Bourne shell care about more than just
standards conformance - the fact that the SVR2 shell handled variables
inside a shell function in a particular fashion caused at least one user
problems.
To give a couple of other examples of why "well, the standard doesn't
say we *can't* do this" isn't necessarily a sufficient response:
1) the NFS V2 spec says that file handles are "opaque", meaning
that the server can stuff anything it wants into them, and
the client shouldn't care - it shouldn't took inside the file
handle.
However, at least one NFS client uses a particular part of
the file handle to compute a hash value for that file handle
to speed up lookups of the client's internal per-file data
structures ("rnodes"), and does so in such a fashion that, if
a little-endian server puts out file handles with the "file
ID" part of the file handle (think "inumber") in the same
place in which it appears in, e.g., SunOS 4.x file handles,
and puts out the file handle simply by stuffing the bytes of
its internal file handle into the file handle on the wire,
the client will be likely to compute the same hash value for
most if not all files, causing the client's lookups of the
per-file data structures to be quite slow.
We *could* have argued that our little-endian file server
wasn't doing anything the standard said it couldn't do, but,
instead, we added an option to big-endianize that particular
word in the file handle, to let customers with that
particular vendor's NFS client run faster.
(NOTE: do *not* become confused by the big-endianization.
This is *not* XDRing; the file handle is specified in the NFS
standard as opaque, meaning that there is *NO* requirement
that any data inside it be put into big-endian form.)
2) the NFS V2 spec doesn't say that an attempt to create a
directory, if
1) that directory already exists
and
2) you wouldn't have had permission to create it if it
*didn't* exist
should return EEXIST rather than EACCES.
However, at least one vendor's implementation of "mkdir -p"
fails if said attempt returns EACCES.
We *could* have argued that our file server wasn't doing
anything the standard said it couldn't do, but, instead, we
changed the order in which its "create a directory" code
checks for the existence of a directory and for write
permission on the directory in which that directory would be
created.
dmin Frank Slootweg
> |
> | I don't know, but it is a non-issue, because, as I have said several
> | times in this thread, HP's Bourne shell is *SVID*2 (and XPG[23])
> | compliant. I don't care what Mr. Bourne intended, I don't care what AT&T
> | did or did not document in SVR?, I only care what the *standards* say,
> | complies with them (which it does).
>
> And, as a customer, my dollars will go to vendors that provide useful
> software rather than those that hide their deficiencies behind one or
> more of the many available standards from which there are to choose.
>
> MOST Sincerely,
> Chuck
It looks like you did not note the "I"-style of my postings, my
"Organization:" line(s), and my earlier
> Frank Slootweg, working, but not speaking, for my employer.
I can only recommend to re-read the responses in this thread,
especially those of other, non-HP, people. Then it will be clear that
there never has been a "deficiency" or/and "hiding" behind (a)
standard(s), that the "problem" has been "fixed" in HP-UX 10.x (which
has been out for well over a year), and that many, many years ago - and
probably before most other main UNIX vendors - HP has provided a shell
which did/does not have the problem.
Guy Harris
>Harris apparently doesn't understand the difference between an
>enhancement and a bug fix.
Sigh. Let me try to explain this *again*, and hope that *this* time,
those reading the explanation don't simply filter it through their
strong bias in favor of HP's sticking with an SVR2-vintage Bourne shell
even after the SVR3 Bourne shell came out and *BEFORE* the POSIX 1003.2
standard came out.
One could argue that there wasn't anything "wrong" with the HP-UX Bourne
shell, as it didn't exhibit a behavior *forbidden* by SVID2.
In fact, Mr. Slootweg *did* argue that.
However, somebody who developed a script on a system with an
SVR3-flavored shell, ran it successfully on other systems with
SVR3-flavored shells, and then found that it didn't work on an HP-UX
system might well consider there to be something "wrong" with the HP-UX
shell - i.e., even though it doesn't have a bug, it lacks a feature that
many other UNIXes do *not* lack, and that the script came to depend on.
In fact, Mr. DiGiacomo *did* have that problem.
As such, the mere fact that SVR3's Bourne shell *enhanced* the SVR2
Bourne shell in that regard, rather than *fixing a bug* in it, is
arguably true but irrelevant, at least to Mr. DiGiacomo, and quite
possibly to others as well.
> He just wants to pout,
There is not a single word of truth in the assertion in the clause
quoted here from your post.
Corne Beerse
As I started this discussion, let me continue it:
My first solution is easy but not verry usefull: I require
a SVR3 unix implementation. Now, can someone tell me
where HP says which SVR? is implemented in HP-UX 9?
My other solution is making it a multy script: every function
in its own script. Speed is no problem to me.
Groetjes
Corne
--
My employer only sponsors the bandwidth, not my opinions
C.J.P. Beerse | Alcatel Telecom Nederland bv
mailto:bee...@ats.nld.alcatel.nl | Postbus 3292
tel:+31-70 3079108 fax:+31-70 3079 191 | NL-2280 GG Rijswijk
Guy Harris
> I can only recommend to re-read the responses in this thread,
>especially those of other, non-HP, people. Then it will be clear that
>there never has been a "deficiency"
If you read the responses of some non-HP people, such as Dave DiGiacomo
and Martin Ibert, you will find that they appear to consider it a
deficiency that the HP-UX shell provided SVR2 rather than SVR3 behavior:
From: m...@bb-data.de (Martin Ibert)
Newsgroups: comp.unix.shell,comp.sys.hp.hpux,comp.sys.hp.apps,
comp.unix.internals
Subject: Re: Functions in bourne shell: HP and the rest of the world
Date: 18 Apr 1996 09:28:33 +0200
Organization: BB-DATA GmbH, Berlin, Germany
Message-ID: <kiaratm...@laforge.ppe.bb-data.de>
...
Saying this in other words: A shell script that relies on hash-bang
processing is obviously not intended to run on a plain old vanilla
system anyway, so it might as well rely on other non-POV features. A
system that understands hash-banging, but whose shell clobbers
positional parameters when calling a function, is a bit out of the
ordinary (if not really buggy), to say it mildly.
These HP/UX misfeature has us given grief before. I do admit that it
is in the manual page, so it is definitely not a bug, but it is a
serious shortcoming.
--
---------------------------------------------------------------------------
Dipl.-Inform. Martin Ibert, BB-DATA GmbH, Brunnenstraße 111, D-13355 Berlin
>> e-mail <m...@bb-data.de>, phone +49-30-245-56582, fax +49-30-245-56577 <<
---------------------------------------------------------------------------
>> Disclaimer: My views do not necessarily reflect those of my employer. <<
From: d...@adobe.com (David DiGiacomo)
Newsgroups: comp.unix.shell,comp.sys.hp.hpux,comp.sys.hp.apps,
comp.unix.internals
Subject: Re: Functions in bourne shell: HP and the rest of the world
Date: 18 Apr 1996 20:16:05 GMT
Organization: Adobe Systems Incorporated
Message-ID: <4l67u5$p...@enquirer.mv.us.adobe.com>
...
That doesn't make any sense to me. The SVR2 Bourne shell had the bug that
function parameters overwrote the positional parameters. Anyone writing
shell scripts would realize that this behavior made no sense, and in due
course USG fixed it in the SVR3 Bourne shell. USG fixed it because it was
broken (yes, I realize that's not always the way it works).
Most of the world, such as Sun, IBM, SGI, even OSF, moved forward and
adopted the SVR3 source base or at least the SVR3 behavior, and of course
people writing compatible shells did too since it makes so much more sense.
The majority of people writing Bourne shell scripts do so on systems with
this behavior. Claiming otherwise is just sticking your head in the sand.
HP made a mistake in prematurely standardizing on the SVR2 behavior
because by doing so they created a lot of needless extra work for users
and would-be users (and for me in particular), with no compensating
benefit (I have never personally encountered a shell script that depended
on the SVR2 behavior). Thanks a lot for wasting my time, HP.
...
One might as well try to argue that the lack of header files with
function prototypes, say, isn't a "deficiency", as SVID2 didn't require
a system to have that.
>and that many, many years ago - and
>probably before most other main UNIX vendors - HP has provided a shell
>which did/does not have the problem.
Sun provided, in SunOS 4.0, a shell that didn't have the problem, which
came out in 1986 or 1987 or so. AT&T provided one even before that, as
the shell in question in SunOS was basically just the SVR3.1 shell.
AIX 3.x, I suspect, had it from Day One, as I think it was based on
SVR3's shell.
Which "main UNIX vendors", then, provided such a shell only *after* HP
did?
Mike McNelly
: dmin Frank Slootweg <fra...@neth.hp.com> wrote:
: > I can only recommend to re-read the responses in this thread,
: >especially those of other, non-HP, people. Then it will be clear that
: >there never has been a "deficiency"
: If you read the responses of some non-HP people, such as Dave DiGiacomo
: and Martin Ibert, you will find that they appear to consider it a
: deficiency that the HP-UX shell provided SVR2 rather than SVR3 behavior:
: ...
Ah, but we'll never read any responses about existing shell scripts
which might have broken had HP silently hanged the behavior as you
suggest.
The crux of the matter is that HP maintained forward compatibility for
the shell scripts for existing customers. By doing so it made things
more difficult for customers who ported scripts from other environments
to HP machines. A tradeoff. The decision basis was to be loyal to our
existing customers. You can argue that the number of existing scripts
which would be broken by a change in behavior is "small" but that's very
difficult for a vendor to predict. Besides, "small" may not be "none"
and for those who would have tripped over the change it would have
probably been pretty nasty to debug.
The whole point is largely moot anyway now that the posix shell is out
there with the behavior you expect in the place you expect.
Speaking only for myself,
Mike McNelly
mi...@fc.hp.com
Dan Mercer
Bullshit! Mr. DiGiacomo presumed SVR3 Bourne shell behavior in the
absence of any indication that HP's /bin/sh was SVR3, which it is
not. You should only presume SVR3 in an OS that advertises itself
as SVR3. Using behavior that is not portable is the problem of the
coder, not the vendor. If HP-UX called itself HP-UX V R3 it would be
broken. I would suggest that there are a number of UNIX flavors on
which his script would fail.
Vendor resources are not infinite. HP had to make a decision based
on (amongst others) the following criteria:
- demand for the feature (virtually non-existent, I would posit).
- side effects (potential for damaging user's existing scripts -
mine, for instance). If it ain't broke, don't fix it.
- Bourne shell's obsolescence.
- Existing alternatives (bundled ksh and posix shells)
HP made a reasonable and supportable decision. That decision will not
change. Continuing to complain can only be interpreted as pouting.
F. L. Charles Seeger III
| > software rather than those that hide their deficiencies behind one or
| > more of the many available standards from which there are to choose.
|
| "Organization:" line(s), and my earlier
I noted it, but I did combine two points into one sentence, which may
have confused you, though some others have seem to have picked up on it
just fine.
First, the use of a rationale like "well, it was compliant with so-and-so
standard" in the face of it *obviously* being less useful to the users
*and* being at odds with common practice in the rest of the industry, is,
well, just silly. Substitute 'short-sighted' for 'silly', if you wish,
or perhaps 'corner cutting'. The whole point of having standards is to
make life easier for end users, though hopefully everyone else will benefit
as well. Standards are not defined merely for fun. Don't loose sight of
serving customer needs in the forest of standards.
Second, HP's decision not to fix/upgrade the Bourne shell that it was
shipping may have been made for other reasons. I can certainly speculate
as to what those reasons might have been, but ultimately customers can
only evaluate what the vendors ship. Weirdnesses like this make us
wonder about the vendors. For instance, NIS+ and ttymon make me wonder
about Sun.
As has been said by others, this is more or less ancient history. The
only important thing left is to learn from that history. IMHO, this
was a big mistake with HP/UX. This should have been a no-brainer, even
considering the terrible SVR3 licensing agreements. People inside HP
will have to dissect why and how it happened. I certainly am curious
about how such a bad decision could be made by a seemingly competent
(at least mostly) organization, but I never expect to see such an
analysis, of course. Coming along later and just calling this bug a
feature is transparent marketing-style spin-doctoring aimed at papering
over the fundamental, underlying problem. *Even* if the bug does pass
SVID2 muster. Standards should not be used as an excuse for poor
engineering judgement.
F. L. Charles Seeger III
Eric Hamilton <hami...@cup.hp.com> wrote:
|
| I don't know for sure, but I don't think foot dragging is really why HP didn't
| switch to a 5.3 or later shell.
| I'd guess it was more likely a combination
| of some of the following:
| * concern about losing bug fixes done in HP-UX
This shouldn't have been too much of a concern, if some reasonable version
control was used. Yes, it is significant work, but it should be a
tractable problem. HP did notify USG of these bugs with sample fixes,
right?
| * concern about the cost of reimplementing HP-UX added value pieces
| such as NLS (was an issue early on).
Hmm. Gives me second thoughts about the value of some of these features.
In fact, in reminds of a quote I collected off the net a few years ago:
There is nothing worse than a feature that is useless because it
acts [in] different ways on different platforms.
-- John F. Haugh II
In a multi-platform environment, those features often aren't very useful.
OTOH, in a predominantly HP-environment or as special function equipment,
they may, in fact, be useful.
| * availability of a standard POSIX shell, either in the near future
| prior to its actual shipping or already once it did ship.
I think the timing here is a bit off. Sun and the "enhanced" sh in, what,
1988? Back in the days of HP/UX 6.x. SVR3 is about 1986? When did HP
first ship the POSIX shell? Did HP not notice the change with the SVR3
sh until 1991?
| * licensing issues (remember AT&T + Sun vs. OSF)
Yes, who could forget all the FUD. I've always been uncertain about HP's
driving vision, though I understand HP will be working with SCO on porting
the AT&T code to 64 bit cpus.
| * compatibility concerns (more below)
If HP had adopted the SVR3 shell soon after its introduction, there
should have been few problems. Certainly, there would have been a net
reduction in user problems over the intervening years had the updated
behavior been adopted. Sometimes it's just better to bite the bullet.
Pay me now or pay me later.
| If you were a customer who benefited from HP-UX added value or bug fixes, then
| you might have been glad that we didn't switch to a 5.3 shell.
Sorry, not me nor anyone I know nor any sh programmer that I can imagine.
| Here are the comments in our internal defect database from the unnamed HP
| engineer who closed out the problem report in 1991 and decided not to change
| the Bourne shell:
|
| > The Bourne shell does not preserve positional parameters across function
| > calls whereas the Korn shell does.
| > This problem could be considered an enhancement. However, our lab is
Yes, it *could* be, but the earlier behavior *was* broken. Just ask
any sh programmer.
| > focusing on standardizing HP-UX commands and this type of request
| > does not fall under standardization -- especially since the Korn shell
| > currently supports, and the POSIX shell will support the functionality
| > that this customer wants.
This in 1991, not 1987-88. Why was there not an update much earlier?
| > Moreover, I feel that preserving arguments could break some scripts
| > that depend on a function's side-effect of changing the pos'nl parms.
Did a *single* *support* engineer make this call for HP???
Does HP take steps to keep their engineers up to date about trends and
de-facto standards in the industry, e.g. SVR3 and SVR4?
| While
| our record is far from perfect, I do think that HP has kept a strong focus on
| maintaining customer compatibility across releases.
But, that's not the point. The point of Unix, as far as being a portable
operating system, is that we users can have the same (or very similar)
working environment on hardware from different vendors. HP should be
concerned about customer compatibility across *platforms* as well as
across HP/UX releases. Of course, one can't track every feature of
every system, but that is hardly what we're talking about when we're
discussing function parameter passing in the Bourne shell. Unix is not a
single-vendor OS. Thinking that it is proprietary, while tempting, leads
to the road that MVS and VMS have taken and further invites the use of
MicroSoft systems on homogenized commodity hardware. It may be hard to
keep in mind while competing to sell RISC workstations against Sun, DEC
and IBM, but it is dangerous to forget or neglect the broader interests
of your customers.
| Had there not been ksh and POSIX shells in the picture and had the bug report
| come in saying that SVR3 or SunOS had upgraded /bin/sh not to overwrite
| positional parameters, I expect but cannot prove that we would have looked at
| other systems, risked the incompatibility and fixed it.
I'm really astonished. Are you saying that for the failure of one user to
include in one bug-report that competitors had upgraded their Bourne shells,
HP was unaware of this and, therefore, declined to update HP/UX? I had
always suspected a little stronger than average NIH complex at HP, but
this is incredible. <insert ostrich and asleep-at-the-wheel analogies>
| We may have erred in this particular case-- perhaps we could have changed the
| shell and nobody would have noticed, but it is awfully hard to know that in
| advance. In order to be able to innovate better and offer new capabilities to
| customers we may need to change the balance some, but that's where we're
| coming from.
Maybe keeping in closer touch with your existing and potential customers
is in order. Chrysler is claiming that much of the success or their new
mini-vans came from extensive customer contact and influence. It has
been my observation ithat much of this (in the industry, not with HP in
particular) involves upper or middle management types, not the people
that write sh scripts. Their perspectives do differ, BTW. 8-)
| I'd be interested in hearing reasoned views on when folks think that we ought
| to change/enhance things and when compatibility needs to prevail.
I hope I've done a little of that. I don't think there is any magic
formula that can be tweaked. Perhaps, there can be a philosophy, but
engineering judgement just can't be totally divorced from the process.
Therefore, you may be trouble if the decision makers are not steeped
in Unix. Apologies for anything overly inflamatory, but sometimes one
needs to be a little flamboyant to be noticed in the wilderness.
| And I
| wonder whether that depends on whether you're a new customer coming to HP-UX
| or an existing customer with an HP-UX installed base.
Yes, these perspectives might certainly differ. I applaud the concern for
the existing users, but actions so motivated might also be interpretted
as attempts at bottling them up in an OS incompatible with everything else.
That's the negative spin on having value-added features to distinguish
your OS from everyone else. We, as users, sometimes have to fight you,
as vendors, to keep things in line. Unfortunately, most of us do this by
just ignoring as much of the accumulated fluff as we can. Alas, there are
times this isn't possible.
| Finally, given a viable standards based workaround (/bin/posix/sh in 9.x,
| /usr/bin/sh in 10.x, see also getconf(1)) my estimate of the likelihood of a
| patch to 9.x is approximately nil.
No doubt. There's also a limit to how much windmill tilting I'll do.
Regards,
Dan Mercer
: dmin Frank Slootweg <fra...@neth.hp.com> wrote:
: > I can only recommend to re-read the responses in this thread,
: >especially those of other, non-HP, people. Then it will be clear that
: >there never has been a "deficiency"
: If you read the responses of some non-HP people, such as Dave DiGiacomo
: and Martin Ibert, you will find that they appear to consider it a
: deficiency that the HP-UX shell provided SVR2 rather than SVR3 behavior:
Ibert deleted.
: From: d...@adobe.com (David DiGiacomo)
: Newsgroups: comp.unix.shell,comp.sys.hp.hpux,comp.sys.hp.apps,
: comp.unix.internals
: Subject: Re: Functions in bourne shell: HP and the rest of the world
: Date: 18 Apr 1996 20:16:05 GMT
: Organization: Adobe Systems Incorporated
: Message-ID: <4l67u5$p...@enquirer.mv.us.adobe.com>
: ...
: That doesn't make any sense to me. The SVR2 Bourne shell had the bug that
: function parameters overwrote the positional parameters. Anyone writing
: shell scripts would realize that this behavior made no sense, and in due
: course USG fixed it in the SVR3 Bourne shell. USG fixed it because it was
: broken (yes, I realize that's not always the way it works).
First of all, it wasn't a BUG. A BUG occurs when something is
designed to exhibit one behavior and instead exhibits another. SVR2
Bourne shell positional parameter worked as designed. Second, it was
perfectly consistent with the design of functions, in that function
processing modified the current environment. Changing directories in
a function actually changes directories. Changing the contents of a
variable in a function changes it globally. In short, all stack
variables were global.
This was a behavior that many found annoying, and some, like I,
exploited. At SVR3, the behavior was changed so that calling a
function preserved some stack variables and not others. This was
inconsistent with the original design, but for most, a preferrable
behavior.
Guy Harris
>Ah, but we'll never read any responses about existing shell scripts
>which might have broken had HP silently hanged the behavior as you
>suggest.
Funny, when I was at Sun, I don't remember hearing about any such
scripts.
>You can argue that the number of existing scripts
>which would be broken by a change in behavior is "small" but that's very
>difficult for a vendor to predict.
We seem to have predicted correctly at Sun, and I suspect AT&T predicted
correctly when they made the original change.
Guy Harris
>This shouldn't have been too much of a concern, if some reasonable version
>control was used. Yes, it is significant work, but it should be a
>tractable problem.
It was certainly tractable at Sun, when *we* upgraded to the SVR3 shell.
>I think the timing here is a bit off. Sun and the "enhanced" sh in, what,
>1988?
1987, actually - as I remember, that's when SunOS 4.0 came out, with an
SVR3-derived Bourne shell.
>| > The Bourne shell does not preserve positional parameters across function
>| > calls whereas the Korn shell does.
>| > This problem could be considered an enhancement. However, our lab is
>
>Yes, it *could* be, but the earlier behavior *was* broken. Just ask
>any sh programmer.
And the claim that "The Bourne shell does not preserve positional
parameters across function calls" was, once SVR3 had come out, false,
anyway - different versions of the Bourne shell exhibit different
behaviors, and, in particular, the SVR3 Bourne shell *does* preserve
them.
Ron Natalie
: And the claim that "The Bourne shell does not preserve positional
: parameters across function calls" was, once SVR3 had come out, false,
: anyway - different versions of the Bourne shell exhibit different
: behaviors, and, in particular, the SVR3 Bourne shell *does* preserve
: them.
Whine, whine, whine. Two weeks of whining when all you have to do
to fix it is use the fixed shell that's also present on the system.
Heaven help you if you were on a DEC where they give you an old
32V Bourne Shell as /bin/sh (no shell funcs even).
Why don't you argue about something useful like why HP doesn't give
you the whole X distribution or better disk setup/bad block reassingment
utility?
Conrad E. Kimball
In article <4lm9t9$e...@fcnews.fc.hp.com>, mi...@fc.hp.com (Mike McNelly) writes:
|> Guy Harris (g...@netapp.com) wrote:
|> : dmin Frank Slootweg <fra...@neth.hp.com> wrote:
|> : > I can only recommend to re-read the responses in this thread,
|> : >especially those of other, non-HP, people. Then it will be clear that
|> : >there never has been a "deficiency"
|>
|> : If you read the responses of some non-HP people, such as Dave DiGiacomo
|> : and Martin Ibert, you will find that they appear to consider it a
|> : deficiency that the HP-UX shell provided SVR2 rather than SVR3 behavior:
|>
|>
|> Ah, but we'll never read any responses about existing shell scripts
|> which might have broken had HP silently hanged the behavior as you
|> suggest.
|>
|> the shell scripts for existing customers. By doing so it made things
|> more difficult for customers who ported scripts from other environments
|> to HP machines. A tradeoff. The decision basis was to be loyal to our
|> which would be broken by a change in behavior is "small" but that's very
|> and for those who would have tripped over the change it would have
|> probably been pretty nasty to debug.
|>
|> The whole point is largely moot anyway now that the posix shell is out
|> there with the behavior you expect in the place you expect.
Let me paraphrase your explanation... HP decided not to change existing
/bin/sh behavior over concern for the existing customer base.
Yet, with HP-UX 10, they do just that - change /bin/sh from Bourne to
Posix shell! (Which, while largely upward compatible, is not completely
so with respect to the Bourne shell - and I would argue, the differences
between Bourne and Posix shells are many times greater than the Bourne
shell "bug" we have been discussing!)
Now, HP, you can't have it both ways - either you are concerned over
the installed base, or you aren't.
(My put on things is that it is a BIG mistake to change /bin/sh to be
the POSIX shell - much better to have installed it as, say, /bin/psh.
Now I've got to worry about my numerous cross-platform #!/bin/sh
scripts that may or may not work on HP-UX 10.)
--
Conrad Kimball | Client Server Tech Svcs, Boeing Information & Support
c...@bcstec.ca.boeing.com | P.O. Box 24346, MS 7M-HC
(206) 865-6410 | Seattle, WA 98124-0346
Martin Ibert
In article <317DFD...@ats.nld.alcatel.nl> Corne Beerse <bee...@ats.nld.alcatel.nl> writes:
: I require
: where HP says which SVR? is implemented in HP-UX 9?
Since at the bottom of its heart, HP-UX 9 (and 10, for that matter) is
a BSD system that only has some System V paint on the surface, HP will
probably not say that their UNIX implements _any_ SVRx. It might
implement a partly compatible interface, but it certainly doesn't
implement any System V release.
Martin Ibert
In article <4lmbd8$l...@dawn.mmm.com> dame...@mmm.com (Dan Mercer) writes:
: Bullshit!
Watch it!
: Mr. DiGiacomo presumed SVR3 Bourne shell behavior in the
: absence of any indication that HP's /bin/sh was SVR3, which it is
: not. You should only presume SVR3 in an OS that advertises itself
: as SVR3. Using behavior that is not portable is the problem of the
: coder, not the vendor. If HP-UX called itself HP-UX V R3 it would be
: broken. I would suggest that there are a number of UNIX flavors on
: which his script would fail.
Which ones might that be? (Other than dinosaur-age versions that don't
have any significance in the marketplace.) I can only speak for our
development team, but HP-UX was the _first_ and _only_ system we ever
encountered this nasty, well, peculiarity. And we do support quite a
lot of today's UNIXes.
While we (and the others who have complaint) might not be a watertight
case against HP to sue for punitive damages, the Principle of Least
Astonishment was violated quite severely. And that is of great concern
to us customers in this fragmented market.
I'm not saying HP did anything illegal. But I am suggesting that HP
made a bad decision. I and others like me would be much happier with a
/bin/sh that behaves like all the other /bin/sh's out there rather
than like a /bin/sh from way back when I was still in elementary
school.
I'm not saying that HP fixed a bug when they finally changed the
behaviour of /bin/sh in HP-UX 10. But I do think that they made a good
decision that in the long run will make more people happy than sad.
Martin Ibert
In article <4loqf4$h...@topaz.sensor.com> r...@topaz.sensor.com (Ron Natalie) writes:
: Whine, whine, whine. Two weeks of whining when all you have to do
: to fix it is use the fixed shell that's also present on the system.
Okay, then please tell me how I do that. Of course, the shell script
must run under any UNIX that is a serious player in the marketplace,
and it must include a hash-bang so that it really runs under a bourny
shell. The hash-bang obviously cannot point to anything that is not
present on all systems.
So what do I do? I must use /bin/sh.
: Heaven help you if you were on a DEC where they give you an old
: 32V Bourne Shell as /bin/sh (no shell funcs even).
What DEC would that be? Is that anything we are likely to encounter at
a customer's site today?
Frank Slootweg
An "apology"/clarification:
===========================
After reading Eric Hamilton's well written response (Thanks, Eric!), I
realized that my responses did not acknowledge the real customer needs
(for having a shell which saves/restores the positional parameters when
a function is entered/exited them on exit), while at the same time they
(over)stressed the standards issue.
For me, the need was obvious, and hence I did not mention/acknowledge
it. In hindsight, I should have acknowledged the need, to prevent
misunderstandings (which, I think, occured). I am sorry about that.
Also I should have acknowledged that I understand that, for customers
coming from SVR3-based system, the HP-UX 9.x Bourne shell (/bin/sh) does
not have all the features they are used to, and as such may cause
portability problems. I am sorry about not acknowledging this either.
In my own defense: I (over)stressed, the standards issue, because I
firmly believe that in this case, there are good, viable, standard-
compliant solutions, which do not have any (major) disadvantage. I
agree with other posters, like Guy Harris, that standards, while very
important, are not an end in themselves, but I also firmly believe that
if there are standard-compliant solutions and solutions which are not
standard-compliant, the former should be used, unless the latter have
(an) significant advantage(s).
I hope this "cleared the air" somewhat (and did not make things worse
:-)). In my future responses, I will try to keep the above perspective
in mind, be more solution-oriented, and less in the "offense" or
"defense".
Best regards,
Frank Slootweg, (still) working, but (still) not speaking, for my employer.
Dan Mercer
Martin Ibert (m...@bb-data.de) wrote:
: : Bullshit!
: Watch it!
: : Mr. DiGiacomo presumed SVR3 Bourne shell behavior in the
: : absence of any indication that HP's /bin/sh was SVR3, which it is
: : not. You should only presume SVR3 in an OS that advertises itself
: : as SVR3. Using behavior that is not portable is the problem of the
: : coder, not the vendor. If HP-UX called itself HP-UX V R3 it would be
: : broken. I would suggest that there are a number of UNIX flavors on
: : which his script would fail.
: Which ones might that be? (Other than dinosaur-age versions that don't
: have any significance in the marketplace.) I can only speak for our
: development team, but HP-UX was the _first_ and _only_ system we ever
: encountered this nasty, well, peculiarity. And we do support quite a
: lot of today's UNIXes.
My memory may be vague, But I thought NCR SVR3 didn't implement the
change. HP is not SVR3, (IMHO, it is vastly superior), although
it may have implemented some SVR3 changes. Had they implemented that
change, they would have certainly broken some of my scripts that
exploit it.
: While we (and the others who have complaint) might not be a watertight
: case against HP to sue for punitive damages, the Principle of Least
: Astonishment was violated quite severely. And that is of great concern
: to us customers in this fragmented market.
As customers dealing in a fragmented market, the onus is on you to
to certainly check out the differences, particularly in the areas
where there has been the most divergence. Bourne shell
implementations certainly would rank high there. AWK implementations
would be another. Heck, even humble "tr" varies from system to
system (in NCR SVR3, both it and awk couldn't handle NUL's).
Caveat Emptor.
: I'm not saying HP did anything illegal. But I am suggesting that HP
: made a bad decision. I and others like me would be much happier with a
From your point of view. As HP has found out with HP-UX 10, major
changes produce major unhappiness, slow acceptance amongst existing
customer bases and ioncreased support costs in maintaining obsolescent
releases. My customer faces thousands of dollars in upgrade costs in
converting from 9 to 10 and has been dragging its feet. Upgrading our
OS's will drain time and money from application development.
: /bin/sh that behaves like all the other /bin/sh's out there rather
: than like a /bin/sh from way back when I was still in elementary
: school.
: I'm not saying that HP fixed a bug when they finally changed the
: behaviour of /bin/sh in HP-UX 10. But I do think that they made a good
: decision that in the long run will make more people happy than sad.
It is my understanding that HP abandoned /bin/sh in HP-UX 10, not
fixed it. It's obsolete.
: --
: ---------------------------------------------------------------------------
: Dipl.-Inform. Martin Ibert, BB-DATA GmbH, Brunnenstraße 111, D-13355 Berlin
: >> e-mail <m...@bb-data.de>, phone +49-30-245-56582, fax +49-30-245-56577 <<
: ---------------------------------------------------------------------------
: >> Disclaimer: My views do not necessarily reflect those of my employer. <<
--
Dan Mercer
Martin Ibert (m...@bb-data.de) wrote:
: : Whine, whine, whine. Two weeks of whining when all you have to do
: : to fix it is use the fixed shell that's also present on the system.
: Okay, then please tell me how I do that. Of course, the shell script
: must run under any UNIX that is a serious player in the marketplace,
: and it must include a hash-bang so that it really runs under a bourny
: shell. The hash-bang obviously cannot point to anything that is not
: present on all systems.
What would you do if all /bin/sh's were SVR2? You would write the
code differently, wouldn't you? I always process the args before
using any functions. Or, if the functions aren't doing global
actions (changing directories or setting global vars) I run them in a
subshell
( function; )
Or, I save the arglist:
sep=;args=;for i do args="${args}${sep}'${i}'";sep=" ";done
call function
eval set -- $args
: So what do I do? I must use /bin/sh.
: : Heaven help you if you were on a DEC where they give you an old
: : 32V Bourne Shell as /bin/sh (no shell funcs even).
: What DEC would that be? Is that anything we are likely to encounter at
: a customer's site today?
Frank Slootweg
Corne Beerse (bee...@ats.nld.alcatel.nl) wrote:
> Hallo allemaal
>
> As I started this discussion, let me continue it:
> a SVR3 unix implementation. Now, can someone tell me
> where HP says which SVR? is implemented in HP-UX 9?
HP-UX is not, at least not only/fully, a SVR?-based/derived system.
SVR? is an implementation, not a standard.
HP-UX confirms to a number of applicable standards. Because not all
standards cover all components, the standards conformance is normally
documented on a per-component basis. While there are other references,
for cases like yours, the HP-UX Reference manual is the main reference.
As the "INTRODUCTION" of the HP-UX Reference manual explains, the
standards conformance, if applicable, of a component is documented under
"STANDARDS CONFORMANCE" of the applicable manual page, in this case
sh-bourne(1) (sh(1) in the printed version). As I wrote earlier, the
HP-UX Bourne shell conforms to the SVID2 (System V Interface Definition
Issue 2), and XPG2/XPG3 (X/Open Portability Guide Issue 2/3).
All this might be interesting/informative, but does not really solve
your problem, so let me continue:
> My other solution is making it a multy script: every function
> in its own script. Speed is no problem to me.
That is a possibility, but I think it is not neccessary.
One of the most general approaches has been mentioned (on April 17) by
John Haxby (the GNU "configure" approach).
Another approache is to save/restore the positional parameters
yourself, as has been suggested by other posters and by me.
Yet another approach is to test for Korn/POSIX shell availability. I
think that approach has been suggested in this thread. I also suggested
that to you.
If you think that everyone's-but-HP's_9.X shell has the functionality
you need, then you could test for HP-UX and 9.X. If you select this
approach, then I advise to document it, because it is not fully
portable.
I hope this helps. If you need further clarification/help, then please
let this_audience/me know. While I am by no means an expert script
writer, I think I have a reasonable experience, and may have some
insight/tips which might not be obvious to others.
Ron Natalie
Martin Ibert (m...@bb-data.de) wrote:
: In article <4loqf4$h...@topaz.sensor.com> r...@topaz.sensor.com (Ron Natalie) writes:
: : Whine, whine, whine. Two weeks of whining when all you have to do
: : to fix it is use the fixed shell that's also present on the system.
: Okay, then please tell me how I do that. Of course, the shell script
: must run under any UNIX that is a serious player in the marketplace,
: and it must include a hash-bang so that it really runs under a bourny
: shell. The hash-bang obviously cannot point to anything that is not
: present on all systems.
: So what do I do? I must use /bin/sh.
: : Heaven help you if you were on a DEC where they give you an old
: : 32V Bourne Shell as /bin/sh (no shell funcs even).
: What DEC would that be? Is that anything we are likely to encounter at
: a customer's site today?
It was the last version of Ultrix.
Look I'm in the same boat. Either program your scripts to the least
common demoninator or configure them appropriate to the platform.
Are you telling me that you don't bother to even test your scripts
before you ship them to customers?
Frank Slootweg
Note: I will only answer the specific question. All/most other things
have be re-hashed several times, so there is no point in doing it
again. I can only conclude that we either (partly) disagree (which
is fine in forums like these), or do not quite understand
eachother.
Guy Harris (g...@netapp.com) wrote:
> dmin Frank Slootweg <fra...@neth.hp.com> wrote:
[deleted]
> >and that many, many years ago - and
> >probably before most other main UNIX vendors - HP has provided a shell
> >which did/does not have the problem.
>
> Sun provided, in SunOS 4.0, a shell that didn't have the problem, which
> came out in 1986 or 1987 or so. AT&T provided one even before that, as
> the shell in question in SunOS was basically just the SVR3.1 shell.
> AIX 3.x, I suspect, had it from Day One, as I think it was based on
> SVR3's shell.
>
> Which "main UNIX vendors", then, provided such a shell only *after* HP
> did?
I was (implicitly) referring to the Korn shell. HP implemented the
Korn shell long before Sun.
F. L. Charles Seeger III
In article <4lqnld$o...@topaz.sensor.com>,
Ron Natalie <r...@topaz.sensor.com> wrote:
|
| Look I'm in the same boat. Either program your scripts to the least
| common demoninator or configure them appropriate to the platform.
| Are you telling me that you don't bother to even test your scripts
| before you ship them to customers?
I don't ship my scripts to customers. I *am* the customer. What *I*
and I think others are complaining about is that HP was alone (or very
nearly so among major Unix vendors) in keeping the common denominator
void of such a useful feature as (useable) sh functions. This is part
of the battle of getting vendors to provide for customer needs. Maybe
it is whining in eyes of some, but until vendors become (nearly) perfect
it is a necessary evil. Please, no comments about complaining via the
sales or support channels. I know about those, too.
Cheers,
Eric Hamilton
OK, so how about using all this energy to solve folks' problems. How should
people code shell scripts in order to make them portable across UNIX systems
of interest? How do any of you currently do it?
If all the systems of interest did the following, it would seem to be easier:
* supported POSIX shell
* support #!
* had the same pathname for the POSIX shell
But I don't think all of these hold true. Do they work the same on enough
systems to be interesting (insert your list here)?
I suppose that you could modify this somewhat with a level of indirection:
* put your package including scripts in /opt/<yourpackage>
* put the ugly machine/OS dependent test code into a single script
that is used during installation.
* during installation create /opt/<yourpackage>/interpreter as a
symlink to the wherever the POSIX or Bourne shell that has the
features you have coded your other scripts to use.
* code scripts with #! /opt/<yourpackage>/interpreter
Another approach that is often employed when you want a script to work across
a ranger of systems and older OS versions is the "least common denominator"
approach with the Bourne shell (/bin/sh or perhaps /usr/bin/sh or /usr/sh5 on
ULTRIX). In this approach you'd limit your script to features that are
present on all systems and done the same or else you'd put in conditional code
based upon the machine/OS/version type. For example you'd need to be careful
with things such as:
* function parameters and positional parameters (/bin/sh on HP-UX 9.x)
* the test ([ ]) command for symlinks (-h on many or -l on SGI)
* using cp to copy a .a file (SunOS 4.x)
* whether du returns 512 or 1024 byte blocks
* mkdir -p (not always supported, sometimes not over NFS)
* pathnames which are different
* systems or filesystems with 14 character filename limits
Is it possible to write portable shell scripts that do interesting things?
Can these be invoked by users who are running other shells? Are there a few
things that if all vendors did we would make users' lives much easier? If
vendors changed things in future releases, how long would it be before users
could rely on new commonality?
How do folks do this today? How can we make this work for better for the UNIX
community?
F. L. Charles Seeger III
In article <4lrqli$e...@hpax.cup.hp.com>,
Eric Hamilton <hami...@cup.hp.com> wrote:
|
| OK, so how about using all this energy to solve folks' problems.
Great idea! Really.
| ...
| present on all systems and done the same or else you'd put in conditional code
| based upon the machine/OS/version type. For example you'd need to be careful
| with things such as:
| * function parameters and positional parameters (/bin/sh on HP-UX 9.x)
Ugh!! This is about the ugliest to deal with, and it complicates dealing
with many of the others, since a nice functional approach to abstracting
things is not (cleanly) available.
| * the test ([ ]) command for symlinks (-h on many or -l on SGI)
This has been only occasionally a problem, which can be dealt with as
a special, though ugly, case for SGI.
| * using cp to copy a .a file (SunOS 4.x)
Unless I have good reason not to, I always use "-p" with cp. Even though
I'm an admitted BSD bigot, this is one of SV features I prefer. However,
it is a relatively small problem, given that the ranlib executions are
usually buried in Makefiles. Of course, this can be customized in scripts
by defining a CP variable at the beginning. Adding the "-p" option to cp
is one of the common changes that I perform on makefiles, so that the
mtime stamp on the file reflects the build rather than the install time.
| * whether du returns 512 or 1024 byte blocks
A pain, but I don't see everyone agreeing on which to use. If the underlying
du supports the alternate report format, this can be dealt with via an alias
or shell function. FWIW, I prefer reports in term of 1kB size, rather than
512B disk blocks. IMHO, all du's should be able to report either format.
| * mkdir -p (not always supported, sometimes not over NFS)
I've written a mkdir sh function (!!!) for this.
| * pathnames which are different
Yes, a pain. Usually some kind of case statement for setting the PATH
and other environmental variables. Have to do this in my .{t,}cshrc, too.
| * systems or filesystems with 14 character filename limits
Egads! Send those back to the manufacturer!
That's below a reasonable lowest common denominator these days, IMHO.
Who is still shipping such systems?
| Is it possible to write portable shell scripts that do interesting things?
| Can these be invoked by users who are running other shells?
I haven't gone to the trouble myself, but studying the internals of Larry
Wall's Configure scripts would probably be instructive. There are follow-ons
to that, such as, but not restricted to, Gnu autoconf.
| Are there a few
| things that if all vendors did we would make users' lives much easier?
More than a few, but maybe it is best to maintain things like emacs and
perl separately from vendor releases. This is too deep a subject to get
into here, and presently I only have access to SunOS, Solaris and AIX.
However, if there is serious interest in exploring this further, I'm
willing to canvas some admins that I know. In fact, SAGE might be one
good place to explore this further. The next LISA conference is in
Chicago in September. Anyone want to take the lead and register a BOF
on this subject?
Personally, I haven't studied much about the POSIX and Unix-1170 (or
whatever it is) standards. That would have to be part of this process.
FWIW, my windmill-tilting list includes OS source code and GUI admin
interfaces. But, that's another thread.
| If
| vendors changed things in future releases, how long would it be before users
| could rely on new commonality?
Well, there is the time to get those future releases out plus the time for
them to stabilize plus the time for most sites to get most of their hosts
updated. Two years, maybe? There will still be a lot of older systems
around,
| How do folks do this today?
Things that are hard to configure in a sh script at runtime can sometimes
be dealt with by m4. This example defines an m4 macro for the hostname of
the host on which it runs unless overridden by an environmental variable:
define(FILE1, maketemp(/tmp/printcap1.XXXXX))
define(FILE2, maketemp(/tmp/printcap2.XXXXX))
syscmd(test -n "$PRINTCAP_HOSTNAME" && echo $PRINTCAP_HOSTNAME >> FILE1)
syscmd(/bin/hostname >> FILE1)
syscmd(head -1 FILE1 | tr -d "\012" >> FILE2)
define(HOSTNAME, include(FILE2))
syscmd(rm FILE1 FILE2)
...
ifelse(HOSTNAME, .... )
Similar things can be done with uname or other executables, I just happened
to find this example first, which is from an m4 printcap config file rather
than a sh script. Anyhow, scripts like this can be rdist'ed in their m4
form and installed with an invocation of m4.
But, it is sad when you're reduced to using hacks like this to make portable
shell scripts. Usually, one can get by with case statements and executing
or eval'ing constructed command strings. It's not rocket science, but
when you have to deal with lots of incompatibilities it gets ugly and
confusing in a hurry, especially if you don't have functions to help
organize the code. 8-)
| How can we make this work for better for the UNIX community?
Thanks for at least asking that question. It makes me feel better just
seeing it posed. Does anyone else like the SAGE/LISA-BOF suggestion?
How many participating or readin this thread plan to attend LISA-X?
(Man, ten years of LISA conferences already?)
Regards,
Frank Slootweg
Martin Ibert (m...@bb-data.de) wrote:
> In article <4loqf4$h...@topaz.sensor.com> r...@topaz.sensor.com (Ron Natalie) writes:
>
> : Whine, whine, whine. Two weeks of whining when all you have to do
> : to fix it is use the fixed shell that's also present on the system.
>
> Okay, then please tell me how I do that. Of course, the shell script
> must run under any UNIX that is a serious player in the marketplace,
> and it must include a hash-bang so that it really runs under a bourny
> shell. The hash-bang obviously cannot point to anything that is not
> present on all systems.
>
> So what do I do? I must use /bin/sh.
Perhaps I do not fully understand your problem/question, but if with
"a bourny shell" you mean a "Bourne or superset, i.e. Korn or POSIX",
shell", then you do *not* have to use hash-bang (#!) and hence do not
have to specify a pathname, which might point to a non-existant place:
On any system you should always be able to get a "bourny shell"
(of course assuming that one exists on the system) by *not* putting a
"#" in the first character of the script file.
The rules for the first character(s) of the script file are:
"#! interpreter" will try to invoke "interpreter".
"#" will (under most curcumstances) try to invoke a csh.
Anything else will try to invoke a Bourne or superset shell.
As far as I know, this is standard behaviour which any shell/system
should have. First there were no rules. Then the csh came with the "#"
rule. Then other interpreters came and the "#! interpreter" rule was
added, which was (of course) compatible with the "#" rule.
For people who are not aware of the history of the shells, this kind
of information is (probably) not obvious and (probably) not easy to
find, but it is documented: (For HP-UX, and probably for most other UNIX
systems) In the shell manual pages and in exec(2).
When not putting a "#" in the first character of the script file, it
is wise to document this in the script, because not many people are
aware of this and might inadvertantly change the first line. I.e. use
something like:
# Do not remove the space at the beginning of this line because ....
FYI, a non-# first character gives a POSIX shell on HP-UX 10.X and a
Bourne shell on pre-10.X HP-UX systems.
I hope this helps.
Charles Northrup
The KDK includes a series of libraries and header files. You
can write a C program that calls an initialization routine prior
to calling the standard KornShell initialization routine. Thus,
you can have full KornShell capability from within your program.
So you can design a front-end loader linked with the KDK libraries.
This can be sent to your customers along with the scripts. The
scripts call the loader to get the KDK shared libraries in memory.
You can then call your script to evaluate ksh93 syntax.
Replies by email.
Charles Northrup AT&T Bell Laboratories (non employee)
c...@research.att.com Software and Systems Research Center, RM 2B-126
908-582-6794 600 Mountain Avenue, Murray Hill, NJ 07974-2070