On 6/26/09 21:21 Rick McGuire said:
> Chip,
>
> I think somebody must have hacked into your email, because it must
> have been someone else who stated:
>
> Two very compelling arguments. I concur with both.
>
> The last time this feature was discussed.
Ignoring your sarcasm, I do not deny that I did say that you made two very
compelling arguments, and that I concurred with them both. Unfortunately, one
argument turned out to be false, the other overreaching hubris.
As your second argument, you said:
> However, there's an even bigger reason to include the current
> directory in the search...we're already doing it that way in all of
> the existing releases.
That would have been a compelling argument had it been true, but as Mark just
discovered:
> So the bug is that it is found [under 4.0] on Windows. The bug is not that
> it
> should be found on Linux.
>
> And in fact if you run your example under 3.2.0 on Windows, progB is not
> found:
Since my concurrence was based on your false assertion that it would break
backwards compatibility, I respectfully request that I be released from my
agreement to it. And no, I do not care whether the 3.2 Windows behavior was
due
to a bug or intention; the behavior is now established in working code.
As for your first argument, you said:
> However, I prefer to think of these as the "Rexx" lookup rules
> rather than the "platform" lookup rules. In other words, it's better
> to have a standard set of Rexx rules that can be depended upon from
> platform to platform than to necessarily modify this for a given
> platform just to make it different. People complain the most about
> differences in behavior when they move programs between platforms.
Again, I originally took your last assertion at face value. People who buy
houses near an airport complain about airplane noise, but are they even a
measurable fraction of the number of people riding in those noisy airliners?
What would be interesting to know is how many ooRexx programmers are engaged in
porting programs between platforms, versus how many are simply trying to get an
application to work on a single platform. I have no numbers (and I seriously
doubt that any exist, so my WAG is as good as yours) but if you don't agree
that
there are at least an order of magnitude more single-platform ooRexx
programmers, you are just being petulant. My experience tells me that it is
more likely three orders.
As it so often does, the issue boils down to philosophy.
Rexx was designed to make it easier to write programs and to manipulate
external
applications on a specific operation system platform. (Mike, feel free to jump
in here if I'm wrong.) The external command lookup rules were those of CMS.
When Rexx was ported to MVS, the external command lookup rules were those of
TSO. The degree of cross-platform compatibility was limited to the language
itself, Bifs, and most of the APIs. No one would have thought that either the
CMS or TSO lookup rules were appropriate for the Amiga, Tandem, MSDOS, or any
of
the subsequent Rexx platforms.
That was the kernel of my original objection: because of operating system
design, filesystem organization, or a myriad other complicating factors, no
single command lookup algorithm could be appropriate for all platforms.
You talked me out of my objection by proposing "a single set of Rexx rules"
that
sounded like a good idea. However, on further reflection it appears that you
have fallen prey to the Esperanto Fallacy: the Old Testament allegory that all
was peaceful until the Babelization of the world. Therefore, the inference
went, if we all spoke a common language (Esperanto) we could all live in peace.
Post hoc ergo propter hoc.
The fallacy is based on at least three logical flaws:
1. Esperanto is no culture's native language, therefore not everyone in a
particular culture will understand it.
2. The majority of the members of a culture will not need to communicate with
someone from a different culture, so they won't need a second language.
3. Conflict derives from baser forces than lack of communication.
So which is the more important Rick, that the majority of ooRexx programmers
see
a behavior that is consistent with the platform they are using, or that the
(very) few programmers who are porting ooRexx apps from one platform to another
see an idiosyncratic but common behavior that matches neither?
On the assumption that we are attempting to expose Linux/UNIX/MacOS shell
script
programmers, Windows VB programmers, AppleScript programmers, et al. to the
power of ooRexx, one would think that we would want ooRexx to follow whatever
external command lookup rules those programmers are already familiar with. If
for no other reason than it makes it easy for them to re-write a bash script
(say) in ooRexx and have it behave exactly the same. This, I contend, is a far
more common occurrence than the porting of a working ooRexx app from one
platform to another.
Besides, programmers doing porting are more than likely familiar with both
platforms before undertaking such a project. They should already understand
the
differences and be prepared to compensate for them.
Therefore, I hereby rescind my concurrence with both of your compelling (but
flawed) arguments on the grounds of recently uncovered evidence.
My considered opinion is that ooRexx should follow the TSO/REXX model:
establish
a search order for those things which are ooRexx, and defer to the platform for
everything else. That is what programmers are going to expect, and violating
programmer expectation raises the "astonishment factor".
-Chip-
> On Fri, Jun 26, 2009 at 5:11 PM, Chip Davis<c...@aviatrexx.com> wrote:
>> David -
>>
>> I'm afraid your example does not demonstrate the mechanism. Try:
>>
>> [dash...@localhost ~]$ ad/prototype.rex
>>
>> and see if it finds the executable without the current directory being in the
>> PATH variable.
>>
>> In your example, the shell knows that '.' is a pseudo-directory entry found
>> in
>> every directory, which points to the inode of the directory it's in (a "here
>> pointer"). It's the same sort of directory entry as '..' which points to the
>> inode of the parent directory of the one it's in. This can be verified by
>> inspecting the output of 'ls -lai'.
>>
>> The shell knows that it can construct absolute paths from the '.' and '..'
>> tokens, and provides a few of its own like '~' and a few variants. These are
>> shortcuts for absolute paths, and the shell substitutes them into the
>> otherwise
>> relative path you specified on the command line.
>>
>> For example, if your current directory was '/home/dashley/foo/bin' and you
>> issued '../../ad/prototype.rex' the shell would have found it without
>> consulting
>> the PATH variable.
>>
>> The same thing would happen if you issued: '~/ad/prototype.rex' from your
>> username from any directory on the system. Or '~dashley/ad/prototype.rex'
>> from
>> any username anywhere on your system.
>>
>> Technically, all of the above are examples of specifying an absolute path,
>> despite the fact that some of them do not start with a slash.
>>
>> When the shell has enough information from the command line to generate an
>> absolute path, it does not refer to the PATH variable.
>>
>> I was going to describe that mechanism in my original post but I thought that
>> such shell shortcuts were already understood. My major point was that MS-DOS
>> unilaterally and automatically adds the current directory to the PATH search
>> list, doing so in the worst possible position for security, reliability,
>> etc.,
>> and leaving no way to un-include the current directory from the PATH. And
>> now
>> ooRexx is making the same mistake.
>>
>> -Chip-
>>
>> On 6/26/09 18:10 David Ashley said:
>>> Chip -
>>>
>>> That is not correct, at least not on Linux as the following shows.
>>>
>>> [dash...@localhost ~]$ echo $PATH
>>> /usr/lib/qt-3.3/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibm/c4eb/bin:/home/dashley/bin:/usr/kerberos/bin
>>> [dash...@localhost ~]$ pwd
>>> /home/dashley
>>> [dash...@localhost ~]$ ./ad/prototype.rex
>>> return type = int *
>>> function name = fname
>>> arg 1 type = int
>>> arg 1 name = arg1
>>> arg 2 type = char *
>>> arg 2 name = arg2
>>> arg 3 type = long *
>>> arg 3 name = arg3
>>> [dash...@localhost ~]$
>>>
>>> The /home/dashley subdir is not in the PATH but the program was found.
>>> Thus a relative path does not have to have its root path in the PATH.
>>>
>>> David Ashley
>>>
>>> Chip Davis wrote:
>>>> On 6/26/09 16:05 Mark Miesfeld said:
>>>>
>>>>> On Fri, Jun 26, 2009 at 8:49 AM, Rick McGuire<object.r...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>> So the bug is that it is found on Windows. The bug is not that it
>>>>>>> should be found on Linux.
>>>>>>>
>>>>> Well, I only called it a bug on Windows because his example fails on
>>>>> 3.2.0.
>>>>>
>>>> Not to be pedantic, but one could make the case that it _is_ a bug in
>>>> Window,
>>>> albeit a long-standing one.
>>>>
>>>> In Linux/UNIX, a relative-path command will not be found unless its
>>>> directory
>>>> was specified in the PATH variable. The current directory could be
>>>> specified in
>>>> the PATH with a dot or an extraneous delimiter (':') but is not required.
>>>>
>>>> If the current directory is not specified, it is not searched for a
>>>> relative-path command. This is useful when it was necessary to restrict
>>>> the
>>>> directories from which commands can be issued.
>>>>
>>>> There are many ways to get malware onto a naive user's current directory,
>>>> so it
>>>> is strongly recommended that if the current directory is in the user's
>>>> PATH, it
>>>> should be at the end, and thus the last directory searched.
>>>>
>>>> MS-DOS (a re-implementation of UNIX for the PC) not only automatically
>>>> included
>>>> the current directory in the PATH (hey, it's more convenient) but put it
>>>> at the
>>>> beginning (hey, it's marginally faster). Which made it trivially easy to
>>>> lure a
>>>> naive user to a directory, whereupon he issues 'dir' which invokes a local
>>>> executable that does bad things.
>>>>
>>>> The UNIX/Linux approach provides a mechanism to prevent picking up
>>>> executables
>>>> from the local directory. The Windows, and now ooRexx, approach do not.
>>>> More
>>>> importantly, there is no way to override the ooRexx search order if the
>>>> user has
>>>> need to.
>>>>
>>>> -Chip-
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
