Path: utzoo!attcan!uunet!tiamat!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.lang.perl
Subject: Re: Proposed enhancements to MS-DOS perl
Message-ID: <1990Sep30.140246.24464@holos0.uucp>
Date: 30 Sep 90 14:02:46 GMT
References: <1990Sep20.013320.9162@holos0.uucp> <2764@jaytee.East.Sun.COM>
Organization: Holos Software, Inc., Atlanta, GA
Lines: 102
Eepeep: WHAT, Noname?


Tom, it sounds like you and I need to get together to come up with a single
DOS version that can serve as a standard for future work.  I'm sending you
e-mail.

In article <2764@jaytee.East.Sun.COM> tdinger@east.sun.com (Tom Dinger - Sun BOS SPA) writes:
>
>I have already done a bunch of the things you mentioned...
>
>>       c) Using a Unixism, like "/bin/rm".
>
>I have modified many (most?) of the scripts, that weren't hopelessly mired in
>**ix-isms.  For example, many of the io.* scripts did not seem easy to
>"translate."
>
>The ones that I have had problems with are:
	[list omitted]
>
>The rest of the scripts (renamed) run, and I believe almost all tests pass.

You must have been running your swapping version, since the scripts often
invoke sub-perls.
>
>>
>>2)   Minor bug corrections.  The program should pass as much of
>>     the test suite as possible under DOS.
>
>I have found and fixed a bunch of bugs:

I fixed these too, long ago.  I'm surprised that some of these made it out
at all, since they cause compilation to fail.
>
>
>
>First, the good news: I have a _drop-in replacement_ for the MSC lowest-level
>spawn functions, that will permit swapping to EMS, XMS or DISK...
>
>Now the bad news: currently... the code... belongs to my company,

I already had such code lying around, or I'd never have attempted this.
I too wrote it for a make program: Dennis Vadura's dmake.  Mine will use
XMS or DISK, but I usualy compile the XMS portion out and use a RAM disk.
Mine also already has the MKS argument passing built in.
>
>>
>>5)   Complete MKS compatibility (see below for a plug for MKS). 
>
>PLEASE make this optional (I noted in later postings that you intend to do so.)
>I do not use MKS, nor am I about to start; however, I would welcome a
>"reasonable" standard for supplying long command lines to applications, as
>long as it is backward-compatible with applications that know nothing
>about it (lots of them).

It is.  Both the extended argument list and the standard 128 byte command
tail are passed out.  Without this compatibilty, you wouldn't be able to
run non-MKS programs from their Korn shell, which would of course be
completely unacceptable.
>
>Other things I have done to perl [the audience gasps]:
>
>1. As many DOS-perl users will not be compiling perl for their own system,
>   and additionally because DOS users must contend with drive letters, I
>   have added to _all_ versions of perl (not just DOS) the ability to
>   use the PERLLIB environment variable as the path on which to find the
>   perl "library."

I agree.  But of course it's Larry's decision.
>4. I added use of the TMP environment variable for the perl -e option, to
>   create the temporary input script.  Rationale was the same as for
>   PERLLIB, plus it is a quasi-standard in the DOS world.

Of course.
>
>In the on-deck circle:
>
>1. Using a custom chdir() function for DOS, that will change the drive as well
>   as the path if a drive is present.  For example:
>
>	chdir("\\");	/* change to root of the current drive */
>	chdir("D:");	/* change to drive D, whatever the current directory*/
>	chdir("E:\\");	/* change to drive D, change it's current dir to root*/
>	etc.

Similar to the MKS Korn shells cd command, though *it* ignores any concept of
current directory in an alternate drive: the 2nd example above would put
you into D:'s root.  You know that even DOS 4.x will take forward slashes
in system calls?  It's only command.com (which I don't use) and certain
programs (LINK, WP) that insist on backslashes.
>
>3. [Just a thought] MSC provides enough information and hooks in the start-up
>   code to replace the ARGV processing -- we could produce a command-line
>   parser that would handle quoted arguments "smarter" and could glob, like
>   the command-line processing the DOS shell recently made available.

My version, even in an vanilla DOS environment, will glob wildcards and
handle double quoted arguments.  It falls short of a Unix shell, but
it works.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr