Re: "Too long" error due to command line

[email protected] (Nicholas Clark) Thu, 30 Dec 1999 16:37:46 +0000
Newsgroups perl.riscos
Message-ID <[email protected]>
On Thu, Dec 30, 1999 at 03:22:38PM +0100, Vincent Lefevre wrote:
> On 30 Dec, Nicholas Clark <[email protected]> wrote:
> 
> > Moving/symlinking either/both the perl script or the perl binary nearer to
> > $ will work around the problem for a bit by making the paths shorter.
> 
> I defined a *$Path variable, and used a pseudo-filing system.
> But the problem with this is that I can no longer drag'n-drop
> the filename to the taskwindow, otherwise the full pathname
> would be written.

Not sure what to do. Hopefully I've got the diagnosis of the cause correct.
If so I think that you're going to have to bodge it, and how you bodge it
will depend on exactly what/how your doing whatever your are doing.

> > I believe that RISC OS 4 raises the OSCLI limit from 255 to 1023 characters.
> 
> This is still ridiculous...

Regrettably so. As are some other features of RISC OS

[eg DDEUtils is designed to give multiple current directories to
multiple task windows, but in turn managed to create a new global
object - a single extended command line for the whole machine. D'oh]
 
> > If you're not calling your perl script from an obey file you might be best
> > to investigate the DDEUtils module and the extended command line that it
> > provides. perl (courtesy of UnixLib) will automatically read these, so all
> > you'd need to do is make the calling program set an extended command line.
> 
> There was no calling program. I typed the command from a taskwindow.
> But can LineEditor use this extended command line?

I think it comes with source code, so it would be possible to add
support if it doesn't currently have it. However, all it does is hook
into the OS_ReadLine vector, so if (as I suspect) it's being called by
the OS with a 255 limit (and a 255 buffer allocated by the OS) it's
not going to help by modifing LineEditor; you'd need to find/make an
alternative Taskwindow that allocates a big buffer, calls OS_ReadLine
(and thereby LineEditor) with the big buffer, and then circumvents the
OSCLI limit of 255 by using DDEUtils.

Not nice

Nick