From: Chip D. <ch...@av...> - 2009-06-27 23:28:46
|
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<ch...@av...> wrote: >> David - >> >> I'm afraid your example does not demonstrate the mechanism. Try: >> >> [dashley@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. >>> >>> [dashley@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 >>> [dashley@localhost ~]$ pwd >>> /home/dashley >>> [dashley@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 >>> [dashley@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<obj...@gm...> 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 >>>> Oor...@li... >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |