Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= Newsgroups: comp.arch.embedded,comp.lang.forth Subject: Re: Mecrisp on the TI Stellaris Launchpad Date: Sat, 18 Apr 2015 00:25:28 +0200 Lines: 55 Message-ID: References: <51cc1808-8727-4694-b94a-ee9d08209da4@googlegroups.com> <87618vyb8d.fsf@jester.gateway.pace.com> <2015Apr17.164257@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.dfncis.de /GxlJKlnSlAzh2GBrq5ncQrd+9vOx4GEXyv8e6YmuYpnUY4FYM/sjDmKTf Cancel-Lock: sha1:8W3D0ODC7mP1UbLZySwJNzedZ1w= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <2015Apr17.164257@mips.complang.tuwien.ac.at> Xref: csiph.com comp.arch.embedded:20683 comp.lang.forth:38304 Am 17.04.2015 um 16:42 schrieb Anton Ertl: > Blajrs Jrolrsen writes: >> On 2015-04-17, rickman wrote: >>> Yes, I figured that out. It seems the current working directory is not >>> considered under Linux for finding executables... really!? Yes, really. > I think it has something to do with more usage of Unix/Linux by > non-programmers (to such an extent that they don't even write their > own shell scripts). I don't think that argument works. There have been platforms where a very large fraction of users never wrote a program of their own. The biggest of those has to be Microsoft Windows, closely followed by MacOS. But Unix never was anywhere near the top of that category. I'm not aware of any system that encouraged users to write their own programs more strongly than Unix did: the whole "toolkit" paradigm almost forced _users_ to become programmers, at least at the shell script level. And how many other systems did come with a bona-fide HLL compiler right there in the box? > In the old times, we had "." first in the PATH. If I am working on a > new version of Gforth, and am in the build directory of Gforth, then > saying "gforth" gives me the development version, not the installed > version. And that was baskk-ackward. If only because it's a whole lot easier to and type the "./" prefix for the exceptional case of wanting something else than the normal instance of a command, than it would be to figure out where the "official" one might be, and type the full path to there every time you want to be sure you get that. The distinction between "gforth" and "./gforth" is way easier to handle than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" and "gforth". > That disadvantage was worked around by removing the "." from the front > and putting it on the back of the PATH. That workaround would be half-assed at best, because it relies on the obviously flawed assumption that user will never mis-type commands. But because they do, it's relatively easy for an attacker to pre-load their traps with lots of mis-typed versions of, 'ls', 'cd', etc. One other rather important aspect is that the way Unix does it actually leaves you a _choice_ how you want this handled: _you_ define your $PATH setting, so you can put '.' in there exactly where you want or need it, or not at all. On Microsoft platforms, you have no control over it: the system forces an implied '.' to the front of your PATH, whether you want it or not.