Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!ncar!mephisto!gatech!galbp!dscatl!wa4mei!holos0!lbr From: lbr@holos0.uucp (Len Reed) Newsgroups: comp.lang.perl Subject: Re: Proposed enhancements to MS-DOS perl Message-ID: <1990Sep22.182316.5325@holos0.uucp> Date: 22 Sep 90 18:23:16 GMT References: <1990Sep20.013320.9162@holos0.uucp> Organization: Holos Software, Inc., Atlanta, GA Lines: 35 Eepeep: WHAT, Noname? In article roy%cybrspc@cs.umn.edu (Roy M. Silvernail) writes: >Please make [running Korn shell for subprocesses] optional, as I usually >run 4dos for a command interpreter. Yes, I've thought of those who use command.com (yech), MKS Korn shell, and even those who use other shells. I've been planning an environment variable scheme that should handle all possibilities. >Also, please consider hacking the startup code to correctly parse args >such as > >perl -e 'put a script here, complete with whitespace' foo.bar > >(where the single quotes would be correctly handled) Several persons have told me about -e problems. They don't even appear to work on the Korn shell, which seems weird since the ksh should take the stuff between single quotes and put it into a single argument for perl. (This assumes that the expansion doesn't blow exceed the niddling 128 byte command tail limit that will remain until perl.exe is fully MKS compatible.) Note that this should fall out for a Korn shell user: the MKS Korn shell should do all the messing with metacharacters and just pass the arguments to perl.exe. I won't promise to do argument expansion for the non-MKS user; I'll only promise that I won't make things worse than they are and that I'll leave a trail for the interested programmer to pick up. On the other hand, I may end up doing this as a side effect of having to handle the case where, even with the MKS kit intact, perl.exe gets run by a non-MKS command and thus has to invoke glob.exe. Stay tuned. -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr