OT: broken/useless ansi - console driver??

[Bob Stockler]

Ken Brody wrote (on Mon, Oct 24, 2005 at 07:36:21PM -0400):

| Quoting Bob Stockler (Mon, 24 Oct 2005 17:33:32 -0400):
| [...]
| > | Now, if only system() would run /bin/sh rather than the incompatible
| > | /u95/bin/sh instead.  (Regardless of the SHELL setting.)
| >
| > Why?  What's incompatible about it?  It's the latest version of
| > the REAL KornShell (ksh93) and is (mostly) backwards commpatible
| > with the Bourne shell when doing what the Bourne shell would do.
| 
| "echo -n" isn't supported, as it is in /bin/sh.  I'm sure there are
| other minor differences like this as well.  This is probably because
| /u95/bin/sh is really the Korn shell.  (Though it may behave differently
| when run as "sh" rather than "ksh".  I haven't tested that.)

In SCO OSR6 /bin/sh is the Bourne shell. /bin/ksh the KornShell
(ksh88), /u95/bin/sh and /u95/bin/ksh are identical (ksh93).

Some versions of bash respect the -n and some don't.  A test at
the top of shell scripts meant to run on different platforms can
determine whether to assign either "echo" or "/bin/echo" to the
variable ECHO and use it throughout the script, or use "\c" which
works in all cases.

But I don't see this as filePro's problem, but the responsibility
of the shell programmer to know how to write shell scripts for
a specific platform, or to write generalized scripts that will run
on any platform under any shell.

As to variables in a [...] test, they should alsways be quoted,
because different shells, as well as different versions of
individual shells, handle unquoted ones differently.

And anyone familiar with filePro and shell scripts knows to trap
the INT and QUIT signals in the shell scripts to protect them
from those signals when issued from within filePro.

Bob

| In a shell script, something like
| 
|     if [ $foo = bar ]
| 
| when foo is null will continue execution of the script, failing just the
| above test, whereas /bin/sh will abort the entire script.  (True, one
| can argue that the above line is "broken" because of the lack of quotes,
| but it's a change in behavior nonetheless.
| 
| Create a script "/tmp/foo" as:
| 
|     if [ = bar ]
|     then
|         echo true
|     else
|         echo false
|     fi
|     echo The script has continued after the if.
| 
| Run it with "/bin/sh -c /tmp/foo" and "/u95/bin/sh -c /tmp/foo" and see
| the difference.
| 
| The biggest change, however, is a script which executes a filePro program
| (or any other program, I'm sure) on something other than the last line of
| the script will cause the shell to exit upon receiving SIGINT, despite the
| filePro program still running.
| 
| For example, if you have a menu script containing:
| 
|     ... some code ...
|     $PFPROG/fp/dclerk filename -blah -blah -blah
|     ... some more code ...
| 
| and you go press DEL/Ctrl-C at some point in dclerk, you will be returned
| to the menu while dclerk is still running.
| 
| A simple demonstration.  Compare:
| 
|     /bin/sh -c "/appl/fp/dclerk ; echo"
| and
|     /u95/bin/sh -c "/appl/fp/dclerk ; echo"
| 
| Go into update mode on a record and press DEL/Ctrl-C.  A command prompt
| will be displayed, along with the "DEL"/"Ctrl-C" prompt from dclerk if
| running /u95/bin/sh, but will work as expected from /bin/sh.
| 
| I have verified that you can eliminate filePro from the equation via:
| 
|     /u95/bin/sh -c "vi ; echo"
| 
| Press DEL/Ctrl-C upon entering vi and watch the fun begin.  Compare
| that to:
| 
|     /bin/sh -c "vi ; echo"
| 
| --
| KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
| http://www.hvcomputer.com
| http://www.fileProPlus.com

-- 
Bob Stockler  +-+  bob at trebor.iglou.com  +-+  http://members.iglou.com/trebor
Author: MENU EDIT II - The BEST Creator/Editor/Manager for filePro User Menus.
Fully functional (time-limited) demos available by email request (specify OS).